27. aprÄ«lÄ« konferencÄ , sadaļas āDevOpsā ietvaros tika sniegts ziÅojums āAutomÄrogoÅ”ana un resursu pÄrvaldÄ«ba Kubernetesā. TajÄ ir runÄts par to, kÄ jÅ«s varat izmantot K8s, lai nodroÅ”inÄtu savu lietojumprogrammu augstu pieejamÄ«bu un nodroÅ”inÄtu maksimÄlu veiktspÄju.
SaskaÅÄ ar tradÄ«ciju mÄs esam priecÄ«gi iepazÄ«stinÄt (44 minÅ«tes, daudz informatÄ«vÄks par rakstu) un galvenais kopsavilkums teksta formÄ. Aiziet!
AnalizÄsim ziÅojuma tÄmu vÄrdu pa vÄrdam un sÄksim no beigÄm.
Kubernetes
PieÅemsim, ka mÅ«su resursdatorÄ ir Docker konteineri. Par ko? Lai nodroÅ”inÄtu atkÄrtojamÄ«bu un izolÄciju, kas savukÄrt nodroÅ”ina vienkÄrÅ”u un labu izvietoÅ”anu, CI/CD. Mums ir daudz Å”Ädu transportlÄ«dzekļu ar konteineriem.
Ko Å”ajÄ gadÄ«jumÄ nodroÅ”ina Kubernetes?
- MÄs pÄrtraucam domÄt par Ŕīm maŔīnÄm un sÄkam strÄdÄt ar "mÄkoni" konteineru kopa vai pÄkstis (konteineru grupas).
- TurklÄt mÄs pat nedomÄjam par atseviŔķÄm pÄkstÄ«m, bet pÄrvaldÄm vairÄkŠ¾lielÄkÄm grupÄm. TÄdas augsta lÄ«meÅa primitÄ«vi ļaujiet mums teikt, ka ir veidne noteiktas darba slodzes izpildei, un Å”eit ir nepiecieÅ”amais gadÄ«jumu skaits, lai to palaistu. Ja pÄc tam mainÄ«sim veidni, mainÄ«sies visi gadÄ«jumi.
- Ar deklaratÄ«vÄ API TÄ vietÄ, lai izpildÄ«tu noteiktu komandu secÄ«bu, mÄs aprakstÄm āpasaules struktÅ«ruā (YAML), ko izveido Kubernetes. Un vÄlreiz: mainoties aprakstam, mainÄ«sies arÄ« tÄ faktiskais attÄlojums.
Resursu vadība
CPU
Ä»aujiet mums serverÄ« palaist nginx, php-fpm un mysql. Å ajos pakalpojumos faktiski darbosies vÄl vairÄk procesu, no kuriem katram ir nepiecieÅ”ami skaitļoÅ”anas resursi:
(cipari uz slaida ir āpapagailisā, katra procesa abstraktÄ nepiecieÅ”amÄ«ba pÄc skaitļoÅ”anas jaudas)
Lai ar to bÅ«tu vieglÄk strÄdÄt, ir loÄ£iski apvienot procesus grupÄs (piemÄram, visus nginx procesus vienÄ grupÄ ānginxā). VienkÄrÅ”s un acÄ«mredzams veids, kÄ to izdarÄ«t, ir ievietot katru grupu konteinerÄ:
Lai turpinÄtu, jums jÄatceras, kas ir konteiners (operÄtÄjsistÄmÄ Linux). To izskats bija iespÄjams, pateicoties trim galvenajÄm kodola funkcijÄm, kas ieviestas diezgan sen: , Šø . Un turpmÄko attÄ«stÄ«bu veicinÄja citas tehnoloÄ£ijas (tostarp Ärtas āÄaulasā, piemÄram, Docker):
ZiÅojuma kontekstÄ mÅ«s interesÄ tikai grupas, jo kontroles grupas ir konteineru (Docker u.c.) funkcionalitÄtes daļa, kas ievieÅ” resursu pÄrvaldÄ«bu. Procesi, kas apvienoti grupÄs, kÄ mÄs vÄlÄjÄmies, ir kontroles grupas.
AtgriezÄ«simies pie CPU prasÄ«bÄm Å”iem procesiem un tagad arÄ« procesu grupÄm:
(Es atkÄrtoju, ka visi skaitļi ir abstrakta resursu nepiecieÅ”amÄ«bas izpausme)
TajÄ paÅ”Ä laikÄ paÅ”am CPU ir noteikts ierobežots resurss (piemÄrÄ tas ir 1000), kas katram var pietrÅ«kt (visu grupu vajadzÄ«bu summa 150+850+460=1460). Kas notiks Å”ajÄ gadÄ«jumÄ?
Kodols sÄk izplatÄ«t resursus un dara to āgodÄ«giā, pieŔķirot katrai grupai vienÄdu resursu daudzumu. Bet pirmajÄ gadÄ«jumÄ to ir vairÄk nekÄ nepiecieÅ”ams (333>150), tÄpÄc pÄrpalikums (333-150=183) paliek rezervÄ, kas arÄ« tiek vienÄdi sadalÄ«ts starp diviem citiem konteineriem:
RezultÄtÄ: pirmajam konteineram pietika resursu, otrajam ā nepietika resursu, treÅ”ajam ā nepietika resursu. Tas ir darbÄ«bu rezultÄts "godÄ«gs" plÄnotÄjs operÄtÄjsistÄmÄ Linux SÄkot no . TÄs darbÄ«bu var pielÄgot, izmantojot uzdevumu svari katrs no konteineriem. PiemÄram, Å”Ädi:
ApskatÄ«sim gadÄ«jumu, kad otrajÄ konteinerÄ (php-fpm) trÅ«kst resursu. Visi konteineru resursi tiek vienÄdi sadalÄ«ti starp procesiem. RezultÄtÄ galvenais process darbojas labi, bet visi darbinieki palÄninÄs, saÅemot mazÄk nekÄ pusi no nepiecieÅ”amÄ:
Å Ädi darbojas CFS plÄnotÄjs. MÄs turpmÄk sauksim svarus, ko pieŔķiram konteineriem pieprasÄ«jumus. KÄpÄc tas tÄ ir - skatiet tÄlÄk.
PaskatÄ«simies uz visu situÄciju no citas puses. KÄ zinÄms, visi ceļi ved uz Romu un datora gadÄ«jumÄ uz centrÄlo procesoru. Viens centrÄlais procesors, daudz uzdevumu ā vajag luksoforu. VienkÄrÅ”Äkais veids, kÄ pÄrvaldÄ«t resursus, ir "luksofors": tie vienam procesam pieŔķīra fiksÄtu piekļuves laiku CPU, pÄc tam nÄkamajam utt.
Å o pieeju sauc par cietajÄm kvotÄm (stingrs ierobežojums). AtcerÄsimies to vienkÄrÅ”i kÄ robežas. TaÄu, ja sadala limitus visiem konteineriem, rodas problÄma: mysql brauca pa ceļu un kÄdÄ brÄ«dÄ« tam beidzÄs nepiecieÅ”amÄ«ba pÄc CPU, bet visi pÄrÄjie procesi ir spiesti gaidÄ«t lÄ«dz CPU. dÄ«kstÄvÄ.
AtgriezÄ«simies pie Linux kodola un tÄ mijiedarbÄ«bas ar centrÄlo procesoru ā kopaina ir Å”Äda:
cgroup ir divi iestatÄ«jumi - bÅ«tÄ«bÄ tie ir divi vienkÄrÅ”i āpagriezieniā, kas ļauj noteikt:
- svars konteineram (pieprasījumiem) ir akcijas;
- procentuÄlÄ daļa no kopÄjÄ CPU laika darbam ar konteinera uzdevumiem (limiti) ir kvota.
KÄ izmÄrÄ«t CPU?
Ir dažÄdi veidi:
- Kas ir papagaiļi, neviens nezina - vajag katru reizi sarunÄt.
- Interese skaidrÄks, bet relatÄ«vs: 50% servera ar 4 kodoliem un ar 20 kodoliem ir pilnÄ«gi dažÄdas lietas.
- Varat izmantot jau minÄtos svari, ko Linux zina, taÄu tie arÄ« ir relatÄ«vi.
- VispiemÄrotÄkÄ iespÄja ir izmÄrÄ«t skaitļoÅ”anas resursus sekundes. Tie. procesora laika sekundÄs attiecÄ«bÄ pret reÄlÄ laika sekundÄm: uz 1 reÄlo sekundi tika dota 1 sekunde procesora laika - tas ir viens viss CPU kodols.
Lai runÄtu bÅ«tu vÄl vieglÄk, viÅi sÄka mÄrÄ«ties tieÅ”i iekÅ”Ä kodoli, kas nozÄ«mÄ to paÅ”u CPU laiku attiecÄ«bÄ pret reÄlo. TÄ kÄ Linux saprot svarus, bet ne tik daudz CPU laika/kodolu, bija nepiecieÅ”ams mehÄnisms, lai tulkotu no viena uz otru.
ApskatÄ«sim vienkÄrÅ”u piemÄru ar serveri ar 3 CPU kodoliem, kur trim podiem tiks pieŔķirti svari (500, 1000 un 1500), kas ir viegli konvertÄjami uz tÄm pieŔķirtajÄm atbilstoÅ”ajÄm kodolu daļÄm (0,5, 1 un 1,5).
Ja paÅemat otru serveri, kurÄ bÅ«s divreiz vairÄk kodolu (6), un ievietojat tur tos paÅ”us podiÅus, kodolu sadalÄ«jumu var viegli aprÄÄ·inÄt, vienkÄrÅ”i reizinot ar 2 (attiecÄ«gi 1, 2 un 3). Bet svarÄ«gs brÄ«dis notiek, kad Å”ajÄ serverÄ« parÄdÄs ceturtais pods, kura svars ÄrtÄ«bas labad bÅ«s 3000. Tas atÅem daļu no CPU resursiem (puse kodolu), un pÄrÄjiem podiem tie tiek pÄrrÄÄ·inÄti (uz pusi):
Kubernetes un CPU resursi
ProgrammÄ Kubernetes CPU resursi parasti tiek mÄrÄ«ti miliadrakss, t.i. Par pamatsvaru Åem 0,001 serdeÅus. (Tas pats Linux/cgroups terminoloÄ£ijÄ tiek saukts par CPU koplietojumu, lai gan, precÄ«zÄk, 1000 milicores = 1024 CPU koplietoÅ”anas.) K8s nodroÅ”ina, ka tas nenovieto serverÄ« vairÄk podi, nekÄ ir CPU resursi visu podiÅu svaru summai.
KÄ tas notiek? Kad pievienojat serveri Kubernetes klasterim, tiek ziÅots, cik CPU kodolu tajÄ ir pieejams. Un, veidojot jaunu podziÅu, Kubernetes plÄnotÄjs zina, cik kodolu Å”im podam bÅ«s nepiecieÅ”ams. TÄdÄjÄdi pods tiks pieŔķirts serverim, kurÄ ir pietiekami daudz kodolu.
Kas notiks, ja nÄ pieprasÄ«jums ir norÄdÄ«ts (t.i., podam nav noteikts skaits nepiecieÅ”amo kodolu)? IzdomÄsim, kÄ Kubernetes kopumÄ uzskaita resursus.
Podam varat norÄdÄ«t gan pieprasÄ«jumus (CFS plÄnotÄjs), gan ierobežojumus (atceraties luksoforu?):
- Ja tie ir norÄdÄ«ti vienÄdi, podam tiek pieŔķirta QoS klase garantÄta. Å is vienmÄr pieejamais kodolu skaits ir garantÄts.
- Ja pieprasÄ«jums ir mazÄks par limitu - QoS klase pÄrsprÄgstoÅ”s. Tie. MÄs sagaidÄm, ka, piemÄram, pods vienmÄr izmantos 1 kodolu, taÄu Ŕī vÄrtÄ«ba tam nav ierobežojums: dažreiz pod var izmantot vairÄk (ja serverim ir brÄ«vi resursi Å”im nolÅ«kam).
- Ir arÄ« QoS klase labÄkÄs pÅ«les ā tajÄ ietilpst tie paÅ”i pÄksti, kuriem pieprasÄ«jums nav norÄdÄ«ts. Resursi viÅiem tiek pieŔķirti pÄdÄjiem.
AtmiÅa
Ar atmiÅu situÄcija ir lÄ«dzÄ«ga, bet nedaudz atŔķirÄ«ga - galu galÄ Å”o resursu raksturs ir atŔķirÄ«gs. KopumÄ analoÄ£ija ir Å”Äda:
ApskatÄ«sim, kÄ pieprasÄ«jumi tiek Ä«stenoti atmiÅÄ. Ä»aujiet podiem dzÄ«vot serverÄ«, mainot atmiÅas patÄriÅu, lÄ«dz viens no tiem kļūst tik liels, ka tam beidzas atmiÅa. Å ajÄ gadÄ«jumÄ parÄdÄs OOM slepkava un nogalina lielÄko procesu:
Tas mums ne vienmÄr padodas, tÄpÄc ir iespÄjams regulÄt, kuri procesi mums ir svarÄ«gi un kurus nevajag nogalinÄt. Lai to izdarÄ«tu, izmantojiet parametru oom_score_adj.
AtgriezÄ«simies pie CPU QoS klasÄm un izveidosim analoÄ£iju ar oom_score_adj vÄrtÄ«bÄm, kas nosaka atmiÅas patÄriÅa prioritÄtes podiem:
- ZemÄkÄ oom_score_adj vÄrtÄ«ba podam ā 998 ā nozÄ«mÄ, ka Å”Äds aplikums ir jÄnogalina kÄ pÄdÄjais. garantÄta.
- AugstÄkais - 1000 - ir labÄkÄs pÅ«les, Å”Ädas pÄkstis tiek nogalinÄtas vispirms.
- Lai aprÄÄ·inÄtu atlikuÅ”Äs vÄrtÄ«bas (pÄrsprÄgstoÅ”s) ir formula, kuras bÅ«tÄ«ba ir tÄda, ka, jo vairÄk resursu ir pieprasÄ«jis pods, jo mazÄka iespÄjamÄ«ba, ka tÄ tiks nogalinÄta.
Otrais "pagrieziens" - limits_in_bytes - par ierobežojumiem. Ar to viss ir vienkÄrÅ”Äk: mÄs vienkÄrÅ”i pieŔķiram maksimÄlo izsniegtÄs atmiÅas apjomu, un Å”eit (atŔķirÄ«bÄ no CPU) nav runas par to, kÄ to (atmiÅu) izmÄrÄ«t.
KopÄ
Katra pÄksts Kubernetes ir dota requests Šø limits - abi CPU un atmiÅas parametri:
- pamatojoties uz pieprasÄ«jumiem, darbojas Kubernetes plÄnotÄjs, kas sadala podi starp serveriem;
- pamatojoties uz visiem parametriem, tiek noteikta poda QoS klase;
- RelatÄ«vie svari tiek aprÄÄ·inÄti, pamatojoties uz CPU pieprasÄ«jumiem;
- CFS plÄnotÄjs ir konfigurÄts, pamatojoties uz CPU pieprasÄ«jumiem;
- OOM killer ir konfigurÄts, pamatojoties uz atmiÅas pieprasÄ«jumiem;
- āluksoforsā ir konfigurÄts, pamatojoties uz CPU ierobežojumiem;
- Pamatojoties uz atmiÅas ierobežojumiem, cgroup tiek konfigurÄts ierobežojums.
KopumÄ Å”is attÄls atbild uz visiem jautÄjumiem par to, kÄ galvenÄ resursu pÄrvaldÄ«bas daļa notiek Kubernetes.
AutomÄtiska mÄrogoÅ”ana
K8s klasteris-autoscaler
IedomÄsimies, ka viss klasteris jau ir aizÅemts un ir jÄizveido jauns pods. KamÄr pods nevar parÄdÄ«ties, tas uzkaras statusÄ lÄ«dz. Lai tas parÄdÄ«tos, varam pieslÄgt klasterim jaunu serveri vai... instalÄt cluster-autoscaler, kas to izdarÄ«s mÅ«su vietÄ: pasÅ«tÄ«t virtuÄlo maŔīnu no mÄkoÅpakalpojuma sniedzÄja (izmantojot API pieprasÄ«jumu) un savienot to ar klasteru. , pÄc kura pÄksts tiks pievienots .
Å Ä« ir Kubernetes klastera automÄtiskÄ mÄrogoÅ”ana, kas darbojas lieliski (pÄc mÅ«su pieredzes). TomÄr, tÄpat kÄ citur, Å”eit ir dažas nianses...
KamÄr mÄs palielinÄjÄm klastera izmÄru, viss bija kÄrtÄ«bÄ, bet kas notiek, kad klasteris sÄka atbrÄ«voties? ProblÄma ir tÄ, ka pÄkstu migrÄÅ”ana (lai atbrÄ«votu saimniekdatorus) ir tehniski ļoti sarežģīta un dÄrga resursu ziÅÄ. Kubernetes izmanto pavisam citu pieeju.
Apsveriet 3 serveru kopu ar izvietoÅ”anu. Tam ir 6 podi: tagad katram serverim ir 2. Nez kÄpÄc gribÄjÄm izslÄgt vienu no serveriem. Lai to izdarÄ«tu, mÄs izmantosim komandu kubectl drain, kas:
- aizliedz jaunu podziÅu sÅ«tÄ«Å”anu uz Å”o serveri;
- izdzÄsÄ«s serverÄ« esoÅ”os aplikumus.
TÄ kÄ Kubernetes ir atbildÄ«gs par pÄkstu skaita uzturÄÅ”anu (6), tas vienkÄrÅ”i radÄ«s no jauna tos citos mezglos, bet ne tajÄ, kas ir atspÄjots, jo tas jau ir atzÄ«mÄts kÄ nepieejams jaunu podziÅu mitinÄÅ”anai. Tas ir Kubernetes pamatmehÄniÄ·is.
TomÄr arÄ« Å”eit ir kÄda nianse. LÄ«dzÄ«gÄ situÄcijÄ StatefulSet (nevis Deployment) darbÄ«bas bÅ«s atŔķirÄ«gas. Tagad mums jau ir statusful lietojumprogramma - piemÄram, trÄ«s podi ar MongoDB, no kuriem vienÄ ir kÄda veida problÄma (dati ir bojÄti vai cita kļūda, kas neļauj podam startÄt pareizi). Un mÄs atkal nolemjam atspÄjot vienu serveri. Kas notiks?
MongoDB varÄtu mirst, jo tai ir vajadzÄ«gs kvorums: trÄ«s instalÄciju klasterim jÄdarbojas vismaz divÄm. TomÄr Å”is nenotiek - Pateicoties PodDisruptionBudget. Å is parametrs nosaka minimÄlo nepiecieÅ”amo darba pÄkstu skaitu. Zinot, ka viens no MongoDB podiem vairs nedarbojas, un redzot, ka PodDisruptionBudget ir iestatÄ«ts MongoDB minAvailable: 2, Kubernetes neļaus izdzÄst podziÅu.
ApakÅ”ÄjÄ lÄ«nija: lai pÄkstu pÄrvietoÅ”ana (un faktiski arÄ« atkÄrtota izveide) darbotos pareizi, kad klasteris tiek atbrÄ«vots, ir jÄkonfigurÄ PodDisruptionBudget.
HorizontÄlÄ mÄrogoÅ”ana
ApskatÄ«sim citu situÄciju. VietnÄ Kubernetes ir lietojumprogramma, kas darbojas kÄ izvietoÅ”ana. LietotÄju datplÅ«sma nonÄk uz tÄ podiem (piemÄram, tie ir trÄ«s), un mÄs izmÄrÄm tajos noteiktu rÄdÄ«tÄju (teiksim, CPU slodzi). Kad slodze palielinÄs, mÄs to ierakstÄm grafikÄ un palielinÄm aplikumu skaitu, lai izplatÄ«tu pieprasÄ«jumus.
Å odien Kubernetes tas nav jÄdara manuÄli: atkarÄ«bÄ no izmÄrÄ«to slodzes indikatoru vÄrtÄ«bÄm tiek konfigurÄts automÄtisks pÄkstu skaita palielinÄjums/samazinÄjums.
Galvenie jautÄjumi Å”eit ir: ko tieÅ”i izmÄrÄ«t Šø kÄ interpretÄt iegÅ«tÄs vÄrtÄ«bas (lÄmuma pieÅemÅ”anai par pÄkstu skaita maiÅu). JÅ«s varat izmÄrÄ«t daudz:
KÄ to izdarÄ«t tehniski - savÄkt metriku utt. ā Es detalizÄti runÄju ziÅojumÄ par . Un galvenais padoms optimÄlo parametru izvÄlei ir eksperiments!
Ir (LietoÅ”anas piesÄtinÄjums un kļūdas), kuras nozÄ«me ir Å”Äda. Uz kÄda pamata ir jÄga mÄrogot, piemÄram, php-fpm? Pamatojoties uz faktu, ka strÄdnieki beidzas, tas tÄ ir utilizÄcija. Un, ja strÄdnieki ir beiguÅ”ies un jauni savienojumi netiek pieÅemti, tas jau ir piesÄtinÄjuma. Abi Å”ie parametri ir jÄmÄra, un atkarÄ«bÄ no vÄrtÄ«bÄm jÄveic mÄrogoÅ”ana.
TÄ vietÄ, lai noslÄgtu
ZiÅojumam ir turpinÄjums: par vertikÄlo mÄrogoÅ”anu un to, kÄ izvÄlÄties pareizos resursus. Par to es runÄÅ”u nÄkamajos videoklipos - abonÄjiet, lai nepalaistu garÄm!
Videoklipi un slaidi
Video no izrÄdes (44 minÅ«tes):
ZiÅojuma prezentÄcija:
PS
Citi ziÅojumi par Kubernetes mÅ«su emuÄrÄ:
- Ā«Ā» (Andrijs Polovs; 8. gada 2019. aprÄ«lis pakalpojumÄ Saint HighLoad++);
- Ā«Ā» (Dmitrijs Stoļarovs; 8. gada 2018. novembris vietnÄ HighLoad++);
- Ā«Ā» (Dmitrijs Stoļarovs; 28. gada 2018. maijÄ, RootConf);
- Ā«Ā» (Dmitrijs Stoļarovs; 7. gada 2017. novembris vietnÄ HighLoad++);
- Ā«Ā» (Dmitrijs Stoļarovs; 6. gada 2017. jÅ«nijs, RootConf).
Avots: www.habr.com