Aprili 27 kwenye mkutano huo , kama sehemu ya sehemu ya "DevOps", ripoti ya "Kuongeza kiotomatiki na usimamizi wa rasilimali katika Kubernetes" ilitolewa. Inazungumza kuhusu jinsi unavyoweza kutumia K8 ili kuhakikisha upatikanaji wa juu wa programu zako na kuhakikisha utendakazi wa kilele.
Kwa jadi, tunafurahi kuwasilisha (Dakika 44, taarifa zaidi kuliko makala) na muhtasari kuu katika fomu ya maandishi. Nenda!
Wacha tuchambue mada ya ripoti neno kwa neno na tuanze kutoka mwisho.
Mabernet
Wacha tuseme tuna vyombo vya Docker kwenye mwenyeji wetu. Kwa ajili ya nini? Ili kuhakikisha kurudia na kutengwa, ambayo kwa upande inaruhusu kupelekwa rahisi na nzuri, CI / CD. Tuna magari mengi ya aina hiyo yenye makontena.
Kubernetes hutoa nini katika kesi hii?
- Tunaacha kufikiria juu ya mashine hizi na kuanza kufanya kazi na "wingu" nguzo ya vyombo au maganda (makundi ya vyombo).
- Zaidi ya hayo, hatufikiri hata juu ya maganda ya mtu binafsi, lakini kusimamia zaidiΠΎmakundi makubwa zaidi. Vile primitives ya hali ya juu kuruhusu sisi kusema kwamba kuna template kwa ajili ya kuendesha mzigo fulani wa kazi, na hapa ni idadi inayotakiwa ya matukio ya kuendesha. Ikiwa baadaye tutabadilisha kiolezo, matukio yote yatabadilika.
- Pamoja na API ya kutangaza Badala ya kutekeleza mfuatano wa amri mahususi, tunaelezea "muundo wa ulimwengu" (katika YAML), ambao umeundwa na Kubernetes. Na tena: wakati maelezo yanabadilika, maonyesho yake halisi pia yatabadilika.
Usimamizi wa rasilimali
CPU
Wacha tuendeshe nginx, php-fpm na mysql kwenye seva. Huduma hizi kwa kweli zitakuwa na michakato zaidi inayoendelea, ambayo kila moja inahitaji rasilimali za kompyuta:
(nambari kwenye slaidi ni "kasuku", hitaji la kufikirika la kila mchakato wa nguvu ya kompyuta)
Ili iwe rahisi kufanya kazi na hili, ni mantiki kuchanganya michakato katika vikundi (kwa mfano, michakato yote ya nginx katika kikundi kimoja "nginx"). Njia rahisi na dhahiri ya kufanya hivyo ni kuweka kila kikundi kwenye chombo:
Ili kuendelea, unahitaji kukumbuka kontena ni nini (katika Linux). Muonekano wao uliwezekana kwa shukrani kwa vipengele vitatu muhimu kwenye kernel, vilivyotekelezwa muda mrefu uliopita: , ΠΈ . Na maendeleo zaidi yaliwezeshwa na teknolojia zingine (pamoja na "ganda" rahisi kama Docker):
Katika muktadha wa ripoti, tunavutiwa tu vikundi, kwa sababu vikundi vya udhibiti ni sehemu ya utendakazi wa vyombo (Docker, n.k.) vinavyotekeleza usimamizi wa rasilimali. Taratibu zilizojumuishwa katika vikundi, kama tulivyotaka, ni vikundi vya udhibiti.
Wacha turudi kwa mahitaji ya CPU kwa michakato hii, na sasa kwa vikundi vya michakato:
(Narudia kwamba nambari zote ni kielelezo dhahania cha hitaji la rasilimali)
Wakati huo huo, CPU yenyewe ina rasilimali fulani ya mwisho (kwa mfano hii ni 1000), ambayo kila mtu anaweza kukosa (jumla ya mahitaji ya vikundi vyote ni 150+850+460=1460). Nini kitatokea katika kesi hii?
Kokwa huanza kusambaza rasilimali na kuifanya "haki", ikitoa kiasi sawa cha rasilimali kwa kila kikundi. Lakini katika kesi ya kwanza, kuna zaidi yao kuliko inahitajika (333> 150), kwa hivyo ziada (333-150=183) inabaki kwenye hifadhi, ambayo pia inasambazwa sawa kati ya vyombo vingine viwili:
Matokeo yake: chombo cha kwanza kilikuwa na rasilimali za kutosha, pili - hakuwa na rasilimali za kutosha, ya tatu - hakuwa na rasilimali za kutosha. Haya ni matokeo ya vitendo mpangaji "mwaminifu" katika Linux - . Uendeshaji wake unaweza kubadilishwa kwa kutumia mgawo uzani kila moja ya vyombo. Kwa mfano, kama hii:
Wacha tuangalie kesi ya ukosefu wa rasilimali kwenye kontena la pili (php-fpm). Rasilimali zote za kontena zinasambazwa kwa usawa kati ya michakato. Kama matokeo, mchakato mkuu hufanya kazi vizuri, lakini wafanyikazi wote hupungua, wakipokea chini ya nusu ya kile wanachohitaji:
Hivi ndivyo kipanga ratiba cha CFS kinavyofanya kazi. Tutaita zaidi uzani ambao tunagawa kwa vyombo maombi. Kwa nini hii ni hivyo - tazama zaidi.
Wacha tuangalie hali nzima kutoka upande mwingine. Kama unavyojua, barabara zote zinaelekea Roma, na kwa upande wa kompyuta, kwa CPU. CPU moja, kazi nyingi - unahitaji taa ya trafiki. Njia rahisi zaidi ya kusimamia rasilimali ni "mwanga wa trafiki": walitoa mchakato mmoja muda wa upatikanaji wa kudumu kwa CPU, kisha ijayo, nk.
Njia hii inaitwa quotas ngumu (kizuizi kigumu). Wacha tuikumbuke kama mipaka. Walakini, ikiwa unasambaza mipaka kwa vyombo vyote, shida inatokea: mysql ilikuwa ikiendesha kando ya barabara na wakati fulani hitaji lake la CPU kumalizika, lakini michakato mingine yote inalazimika kungojea hadi CPU. bila kazi.
Wacha turudi kwenye kinu cha Linux na mwingiliano wake na CPU - picha ya jumla ni kama ifuatavyo.
cgroup ina mipangilio miwili - kimsingi hizi ni "twist" mbili rahisi ambazo hukuruhusu kuamua:
- uzito wa chombo (maombi) ni hisa;
- asilimia ya jumla ya muda wa CPU wa kufanyia kazi kazi za kontena (vikomo) ni upendeleo.
Jinsi ya kupima CPU?
Kuna njia tofauti:
- Je, ni karoti, hakuna mtu anajua - unahitaji kujadili kila wakati.
- Nia wazi zaidi, lakini jamaa: 50% ya seva iliyo na cores 4 na cores 20 ni vitu tofauti kabisa.
- Unaweza kutumia zile zilizotajwa tayari uzani, ambayo Linux inajua, lakini pia ni jamaa.
- Chaguo la kutosha zaidi ni kupima rasilimali za kompyuta sekunde. Wale. katika sekunde za muda wa processor kuhusiana na sekunde za muda halisi: sekunde 1 ya muda wa processor ilitolewa kwa sekunde 1 halisi - hii ni msingi mmoja wa CPU.
Ili kurahisisha kuongea, walianza kupima moja kwa moja ndani kokwa, ikimaanisha nao wakati sawa wa CPU kuhusiana na ule halisi. Kwa kuwa Linux inaelewa uzani, lakini sio wakati/cores nyingi za CPU, utaratibu ulihitajika kutafsiri kutoka moja hadi nyingine.
Hebu fikiria mfano rahisi na seva iliyo na cores 3 za CPU, ambapo pods tatu zitapewa uzito (500, 1000 na 1500) ambazo zinabadilishwa kwa urahisi kwa sehemu zinazofanana za cores zilizotengwa kwao (0,5, 1 na 1,5).
Ikiwa unachukua seva ya pili, ambapo kutakuwa na cores mara mbili (6), na kuweka pods sawa huko, usambazaji wa cores unaweza kuhesabiwa kwa urahisi kwa kuzidisha tu kwa 2 (1, 2 na 3, kwa mtiririko huo). Lakini wakati muhimu hutokea wakati pod ya nne inaonekana kwenye seva hii, ambayo uzito, kwa urahisi, itakuwa 3000. Inachukua sehemu ya rasilimali za CPU (nusu ya cores), na kwa pods iliyobaki huhesabiwa tena (nusu):
Rasilimali za Kubernetes na CPU
Katika Kubernetes, rasilimali za CPU kawaida hupimwa miliadrax, i.e. Cores 0,001 huchukuliwa kama uzani wa msingi. (Kitu kile kile katika istilahi ya Linux/cgroups inaitwa sehemu ya CPU, ingawa, kwa usahihi zaidi, millicores 1000 = hisa 1024 za CPU.) K8s huhakikisha kwamba haiweki maganda mengi kwenye seva kuliko kuna rasilimali za CPU kwa jumla ya uzani wa maganda yote.
Je, hii hutokeaje? Unapoongeza seva kwenye nguzo ya Kubernetes, inaripotiwa ni cores ngapi za CPU inayopatikana. Na wakati wa kuunda ganda jipya, mpangaji wa Kubernetes anajua ni cores ngapi ganda hili litahitaji. Kwa hivyo, pod itatolewa kwa seva ambapo kuna cores za kutosha.
Nini kitatokea ikiwa hakuna ombi limebainishwa (yaani ganda halina idadi iliyobainishwa ya cores inayohitaji)? Wacha tuone jinsi Kubernetes kwa ujumla huhesabu rasilimali.
Kwa pod unaweza kubainisha maombi yote mawili (kipanga ratiba cha CFS) na kikomo (unakumbuka taa ya trafiki?):
- Ikiwa zimeainishwa sawa, basi pod hupewa darasa la QoS uhakika. Idadi hii ya cores inayopatikana kila wakati imehakikishwa.
- Ikiwa ombi ni chini ya kikomo - darasa la QoS ya kupasuka. Wale. Tunatarajia ganda, kwa mfano, kutumia msingi 1 kila wakati, lakini dhamana hii sio kizuizi kwake: wakati mwingine pod inaweza kutumia zaidi (wakati seva ina rasilimali za bure kwa hili).
- Kuna pia darasa la QoS juhudi bora - inajumuisha yale maganda ambayo ombi halijabainishwa. Rasilimali hutolewa kwao mwisho.
kumbukumbu
Kwa kumbukumbu, hali ni sawa, lakini tofauti kidogo - baada ya yote, asili ya rasilimali hizi ni tofauti. Kwa ujumla, mlinganisho ni kama ifuatavyo:
Wacha tuone jinsi maombi yanatekelezwa kwenye kumbukumbu. Acha maganda yaishi kwenye seva, ikibadilisha utumiaji wa kumbukumbu, hadi mmoja wao atakapokuwa mkubwa sana hadi apoteze kumbukumbu. Katika kesi hii, muuaji wa OOM anaonekana na kuua mchakato mkubwa zaidi:
Hii haifai kila wakati, kwa hivyo inawezekana kudhibiti michakato ambayo ni muhimu kwetu na haipaswi kuuawa. Ili kufanya hivyo, tumia parameter oom_alama_adj.
Wacha turudi kwenye madarasa ya QoS ya CPU na tuchore mlinganisho na maadili ya oom_score_adj ambayo huamua vipaumbele vya utumiaji wa kumbukumbu kwa maganda:
- Thamani ya chini kabisa ya oom_score_adj kwa ganda - -998 - inamaanisha kuwa ganda kama hilo linapaswa kuuawa mwisho, hii uhakika.
- Ya juu zaidi - 1000 - ni juhudi bora, maganda kama hayo huuawa kwanza.
- Ili kuhesabu maadili yaliyobaki (ya kupasuka) kuna fomula, kiini chake ambacho kinahusishwa na ukweli kwamba rasilimali nyingi ambazo pod imeomba, kuna uwezekano mdogo wa kuuawa.
Ya pili "twist" - kikomo_katika_baiti - kwa mipaka. Pamoja nayo, kila kitu ni rahisi zaidi: tunatoa tu kiwango cha juu cha kumbukumbu iliyotolewa, na hapa (tofauti na CPU) hakuna swali la jinsi ya kuipima (kumbukumbu).
Katika jumla ya
Kila ganda katika Kubernetes limetolewa requests ΠΈ limits - vigezo vyote viwili vya CPU na kumbukumbu:
- kulingana na maombi, mpangilio wa Kubernetes hufanya kazi, ambayo inasambaza maganda kati ya seva;
- kulingana na vigezo vyote, darasa la QoS la pod limedhamiriwa;
- Uzito wa jamaa huhesabiwa kulingana na maombi ya CPU;
- kipanga ratiba cha CFS kimesanidiwa kulingana na maombi ya CPU;
- OOM killer imeundwa kulingana na maombi ya kumbukumbu;
- "taa ya trafiki" imeundwa kulingana na mipaka ya CPU;
- Kulingana na mipaka ya kumbukumbu, kikomo kinasanidiwa kwa kikundi.
Kwa ujumla, picha hii inajibu maswali yote kuhusu jinsi sehemu kuu ya usimamizi wa rasilimali hutokea katika Kubernetes.
Kuongeza kasi kiotomatiki
K8s nguzo-otomatiki
Wacha tufikirie kuwa nguzo nzima tayari imechukuliwa na ganda jipya linahitaji kuundwa. Ingawa ganda haliwezi kuonekana, linaning'inia katika hali Inasubiri hakikisho. Ili ionekane, tunaweza kuunganisha seva mpya kwenye nguzo au... kusakinisha cluster-autoscaler, ambayo itatufanyia: agiza mashine pepe kutoka kwa mtoa huduma wa wingu (kwa kutumia ombi la API) na uunganishe kwenye nguzo. , baada ya hapo ganda litaongezwa.
Huu ni kuongeza kasi ya nguzo ya Kubernetes, ambayo inafanya kazi vizuri (katika uzoefu wetu). Walakini, kama mahali pengine, kuna nuances kadhaa hapa ...
Kwa muda mrefu kama tuliongeza saizi ya nguzo, kila kitu kilikuwa sawa, lakini nini kinatokea wakati nguzo akaanza kujiweka huru? Shida ni kwamba kuhama maganda (kufungua majeshi) ni ngumu sana kiufundi na ni ghali katika suala la rasilimali. Kubernetes hutumia mbinu tofauti kabisa.
Fikiria kundi la seva 3 ambazo zina Usambazaji. Ina ganda 6: sasa kuna 2 kwa kila seva. Kwa sababu fulani tulitaka kuzima moja ya seva. Ili kufanya hivyo, tutatumia amri kubectl drain, ambayo:
- itakataza kutuma maganda mapya kwa seva hii;
- itafuta maganda yaliyopo kwenye seva.
Kwa kuwa Kubernetes ina jukumu la kudumisha idadi ya maganda (6), ni rahisi itaunda upya kwenye vifundo vingine, lakini si kwa ile iliyozimwa, kwa kuwa tayari imetiwa alama kuwa haipatikani kwa kupangisha maganda mapya. Huyu ni fundi wa kimsingi wa Kubernetes.
Walakini, kuna nuance hapa pia. Katika hali sawa, kwa StatefulSet (badala ya Usambazaji), vitendo vitakuwa tofauti. Sasa tayari tunayo maombi ya hali - kwa mfano, pods tatu na MongoDB, moja ambayo ina aina fulani ya tatizo (data imeharibiwa au kosa lingine ambalo linazuia pod kuanza kwa usahihi). Na tunaamua tena kuzima seva moja. Nini kitatokea?
MongoDB inaweza kufa kwa sababu inahitaji akidi: kwa nguzo ya usakinishaji tatu, angalau mbili lazima zifanye kazi. Hata hivyo, hii haifanyiki - Shukrani kwa PodDisruptionBudget. Kigezo hiki huamua idadi ya chini inayohitajika ya maganda ya kazi. Kujua kuwa moja ya maganda ya MongoDB haifanyi kazi tena, na kuona kwamba PodDisruptionBudget imewekwa kwa MongoDB. minAvailable: 2, Kubernetes haitakuruhusu kufuta ganda.
Mstari wa chini: ili harakati (na kwa kweli, kuundwa upya) ya pods kufanya kazi kwa usahihi wakati nguzo inatolewa, ni muhimu kusanidi PodDisruptionBudget.
Kuongeza usawa
Hebu tuchunguze hali nyingine. Kuna programu inayoendesha kama Usambazaji katika Kubernetes. Trafiki ya mtumiaji inakuja kwenye maganda yake (kwa mfano, kuna tatu kati yao), na tunapima kiashiria fulani ndani yao (sema, mzigo wa CPU). Wakati mzigo unapoongezeka, tunarekodi kwa ratiba na kuongeza idadi ya maganda ili kusambaza maombi.
Leo katika Kubernetes hii haihitaji kufanywa kwa mikono: ongezeko la moja kwa moja / kupungua kwa idadi ya maganda imeundwa kulingana na maadili ya viashiria vya mzigo uliopimwa.
Maswali kuu hapa ni: nini hasa cha kupima ΠΈ jinsi ya kutafsiri maadili yaliyopatikana (kwa kufanya uamuzi juu ya kubadilisha idadi ya maganda). Unaweza kupima mengi:
Jinsi ya kufanya hivyo kitaalam - kukusanya metrics, nk. - Nilizungumza kwa undani katika ripoti kuhusu . Na ushauri kuu wa kuchagua vigezo bora ni majaribio!
Kuna (Kueneza kwa Matumizi na Makosa), maana yake ni kama ifuatavyo. Ni kwa msingi gani ina mantiki kupima, kwa mfano, php-fpm? Kulingana na ukweli kwamba wafanyikazi wanaisha, hii ni matumizi. Na ikiwa wafanyikazi wameisha na miunganisho mipya haikubaliki, hii tayari kueneza. Vigezo vyote viwili vinapaswa kupimwa, na kulingana na maadili, kuongeza lazima kufanyike.
Badala ya hitimisho
Ripoti ina muendelezo: kuhusu kuongeza wima na jinsi ya kuchagua rasilimali zinazofaa. Nitazungumza juu ya hili katika video zijazo - jiandikishe ili usikose!
Video na slaidi
Video kutoka kwa utendaji (dakika 44):
Uwasilishaji wa ripoti:
PS
Ripoti zingine kuhusu Kubernetes kwenye blogi yetu:
- «» (Andrey Polovov; Aprili 8, 2019 kwenye Saint HighLoad++);
- «» (Dmitry Stolyarov; Novemba 8, 2018 kwenye HighLoad++);
- «» (Dmitry Stolyarov; Mei 28, 2018 katika RootConf);
- «» (Dmitry Stolyarov; Novemba 7, 2017 kwenye HighLoad++);
- «» (Dmitry Stolyarov; Juni 6, 2017 katika RootConf).
Chanzo: mapenzi.com