27 Prill në konferencë , si pjesë e seksionit "DevOps", u dha raporti "Shkallëzimi automatik dhe menaxhimi i burimeve në Kubernetes". Ai flet për mënyrën se si mund të përdorni K8 për të siguruar disponueshmëri të lartë të aplikacioneve tuaja dhe për të siguruar performancë maksimale.
Sipas traditës, ne kemi kënaqësinë të prezantojmë (44 minuta, shumë më informuese se artikulli) dhe përmbledhja kryesore në formë teksti. Shkoni!
Le të analizojmë fjalë për fjalë temën e raportit dhe të fillojmë nga fundi.
Kubernetes
Le të themi se kemi kontejnerë Docker në hostin tonë. Per cfare? Për të siguruar përsëritshmërinë dhe izolimin, të cilat nga ana tjetër lejojnë vendosjen e thjeshtë dhe të mirë, CI/CD. Kemi shumë automjete të tilla me kontejnerë.
Çfarë ofron Kubernetes në këtë rast?
- Ne ndalojmë së menduari për këto makina dhe fillojmë të punojmë me "cloud" grup kontejnerësh ose bishtaja (grupe kontejnerësh).
- Për më tepër, ne as nuk mendojmë për pods individuale, por menaxhojmë më shumëоgrupe më të mëdha. Të tillë primitivë të nivelit të lartë na lejoni të themi se ekziston një shabllon për ekzekutimin e një ngarkese të caktuar pune dhe këtu është numri i nevojshëm i rasteve për ta ekzekutuar atë. Nëse më pas ndryshojmë shabllonin, të gjitha rastet do të ndryshojnë.
- Me API deklarative Në vend që të ekzekutojmë një sekuencë komandash specifike, ne përshkruajmë "strukturën e botës" (në YAML), e cila është krijuar nga Kubernetes. Dhe përsëri: kur përshkrimi ndryshon, shfaqja e tij aktuale gjithashtu do të ndryshojë.
Manaxhimi i burimeve
CPU
Le të ekzekutojmë nginx, php-fpm dhe mysql në server. Këto shërbime në fakt do të kenë edhe më shumë procese të ekzekutuara, secila prej të cilave kërkon burime llogaritëse:
(numrat në rrëshqitje janë "papagall", nevoja abstrakte e çdo procesi për fuqinë llogaritëse)
Për ta bërë më të lehtë punën me këtë, është logjike të kombinohen proceset në grupe (për shembull, të gjitha proceset nginx në një grup "nginx"). Një mënyrë e thjeshtë dhe e qartë për ta bërë këtë është vendosja e secilit grup në një enë:
Për të vazhduar, duhet të mbani mend se çfarë është një kontejner (në Linux). Shfaqja e tyre u bë e mundur falë tre veçorive kryesore në kernel, të implementuara shumë kohë më parë: , и . Dhe zhvillimi i mëtejshëm u lehtësua nga teknologji të tjera (përfshirë "predha" të përshtatshme si Docker):
Në kontekstin e raportit, neve na intereson vetëm grupeve, sepse grupet e kontrollit janë pjesa e funksionalitetit të kontejnerëve (Docker, etj.) që zbatojnë menaxhimin e burimeve. Proceset e kombinuara në grupe, siç donim ne, janë grupe kontrolli.
Le të kthehemi te kërkesat e CPU-së për këto procese, dhe tani për grupet e proceseve:
(E përsëris se të gjithë numrat janë një shprehje abstrakte e nevojës për burime)
Në të njëjtën kohë, vetë CPU ka një burim të caktuar të fundëm (në shembull kjo është 1000), që mund t'i mungojë të gjithëve (shuma e nevojave të të gjitha grupeve është 150+850+460=1460). Çfarë do të ndodhë në këtë rast?
Kerneli fillon të shpërndajë burime dhe e bën atë "drejtësisht", duke i dhënë të njëjtën sasi burimesh secilit grup. Por në rastin e parë ka më shumë seç duhet (333>150), pra teprica (333-150=183) mbetet në rezervë, e cila shpërndahet në mënyrë të barabartë edhe mes dy kontejnerëve të tjerë:
Si rezultat: kontejneri i parë kishte burime të mjaftueshme, i dyti - nuk kishte burime të mjaftueshme, i treti - nuk kishte burime të mjaftueshme. Ky është rezultat i veprimeve Planifikues "i ndershëm" në Linux - . Funksionimi i tij mund të rregullohet duke përdorur detyrën peshë secilin prej kontejnerëve. Për shembull, si kjo:
Le të shohim rastin e mungesës së burimeve në kontejnerin e dytë (php-fpm). Të gjitha burimet e kontejnerëve shpërndahen në mënyrë të barabartë ndërmjet proceseve. Si rezultat, procesi master funksionon mirë, por të gjithë punëtorët ngadalësohen, duke marrë më pak se gjysmën e asaj që u nevojitet:
Kështu funksionon planifikuesi CFS. Më tej do t'i quajmë peshat që u caktojmë kontejnerëve kërkesat. Pse është kështu - shih më tej.
Le ta shohim të gjithë situatën nga ana tjetër. Siç e dini, të gjitha rrugët të çojnë në Romë, dhe në rastin e një kompjuteri, në CPU. Një CPU, shumë detyra - keni nevojë për një semafor. Mënyra më e thjeshtë për të menaxhuar burimet është "semafori": ata i dhanë një procesi një kohë fikse aksesi në CPU, pastaj një tjetër, etj.
Kjo qasje quhet kuota të vështira (kufizim i vështirë). Le ta kujtojmë thjesht si kufijtë. Sidoqoftë, nëse shpërndani kufij për të gjithë kontejnerët, lind një problem: mysql po lëvizte përgjatë rrugës dhe në një moment nevoja e saj për CPU përfundoi, por të gjitha proceset e tjera detyrohen të presin derisa CPU boshe.
Le të kthehemi te kerneli Linux dhe ndërveprimi i tij me CPU - fotografia e përgjithshme është si më poshtë:
cgroup ka dy cilësime - në thelb këto janë dy "kthesa" të thjeshta që ju lejojnë të përcaktoni:
- pesha për enë (kërkesat) është aksione;
- përqindja e kohës totale të CPU-së për të punuar në detyrat e kontejnerit (kufijtë) është kuotë.
Si të matet CPU?
Ka mënyra të ndryshme:
- Çfarë është parrots, askush nuk e di - ju duhet të negocioni çdo herë.
- Interesi më e qartë, por relative: 50% e një serveri me 4 bërthama dhe me 20 bërthama janë gjëra krejtësisht të ndryshme.
- Ju mund të përdorni ato të përmendura tashmë peshë, të cilat Linux i njeh, por ato janë gjithashtu relative.
- Opsioni më adekuat është matja e burimeve llogaritëse në sekonda. Ato. në sekonda të kohës së procesorit në krahasim me sekondat e kohës reale: 1 sekondë e kohës së procesorit është dhënë për 1 sekondë reale - kjo është një bërthamë e tërë CPU.
Për ta bërë edhe më të lehtë të folurin, ata filluan të masin drejtpërdrejt bërthamat, që do të thotë prej tyre të njëjtën kohë të CPU-së në raport me atë reale. Meqenëse Linux kupton peshat, por jo aq shumë kohë/bërthamat e CPU-së, nevojitej një mekanizëm për të përkthyer nga njëri në tjetrin.
Le të shqyrtojmë një shembull të thjeshtë me një server me 3 bërthama CPU, ku tre pods do t'u jepen pesha (500, 1000 dhe 1500) që konvertohen lehtësisht në pjesët përkatëse të bërthamave të alokuara për to (0,5, 1 dhe 1,5).
Nëse merrni një server të dytë, ku do të ketë dy herë më shumë bërthama (6) dhe vendosni të njëjtat pods atje, shpërndarja e bërthamave mund të llogaritet lehtësisht duke shumëzuar thjesht me 2 (1, 2 dhe 3, respektivisht). Por një moment i rëndësishëm ndodh kur në këtë server shfaqet një pod i katërt, pesha e të cilit, për lehtësi, do të jetë 3000. Ai heq një pjesë të burimeve të CPU (gjysma e bërthamave), dhe për podet e mbetura ato rillogariten (përgjysmohen):
Kubernetes dhe burimet e CPU
Në Kubernetes, burimet e CPU zakonisht maten në milliadraks, d.m.th. 0,001 bërthama merren si peshë bazë. (E njëjta gjë në terminologjinë e Linux/cgroups quhet pjesë e CPU-së, megjithëse, më saktë, 1000 millicore = 1024 aksione CPU.) K8s siguron që të mos vendosë më shumë pods në server sesa ka burime CPU për shumën e peshave të të gjitha pods.
Si ndodh kjo? Kur shtoni një server në një grupim Kubernetes, raportohet se sa bërthama CPU ka në dispozicion. Dhe kur krijoni një pod të ri, programuesi Kubernetes e di se sa bërthama do t'i nevojiten këtij pod. Kështu, pod do t'i caktohet një serveri ku ka bërthama të mjaftueshme.
Çfarë do të ndodhë nëse jo është specifikuar kërkesa (d.m.th. pod nuk ka një numër të caktuar bërthamash që i nevojiten)? Le të kuptojmë se si Kubernetes në përgjithësi numëron burimet.
Për një pod mund të specifikoni të dyja kërkesat (planifikuesi CFS) dhe kufijtë (e mbani mend semaforin?):
- Nëse ato janë të përcaktuara të barabarta, atëherë podit i caktohet një klasë QoS garantuar. Ky numër bërthamash gjithmonë i disponueshëm për të është i garantuar.
- Nëse kërkesa është më e vogël se kufiri - klasa QoS i shpërthyeshëm. Ato. Ne presim që një pod, për shembull, të përdorë gjithmonë 1 bërthamë, por kjo vlerë nuk është një kufizim për të: иногда pod mund të përdorë më shumë (kur serveri ka burime falas për këtë).
- Ekziston edhe një klasë QoS perpjekja me e mire — përfshin ato grupe për të cilat kërkesa nuk është specifikuar. Burimet u jepen atyre të fundit.
kujtim
Me kujtesën, situata është e ngjashme, por paksa e ndryshme - në fund të fundit, natyra e këtyre burimeve është e ndryshme. Në përgjithësi, analogjia është si më poshtë:
Le të shohim se si zbatohen kërkesat në memorie. Lërini podet të jetojnë në server, duke ndryshuar konsumin e kujtesës, derisa njëri prej tyre të bëhet aq i madh sa të mbarojë memoria. Në këtë rast, vrasësi OOM shfaqet dhe vret procesin më të madh:
Kjo nuk na përshtatet gjithmonë, kështu që është e mundur të rregullojmë se cilat procese janë të rëndësishme për ne dhe nuk duhen vrarë. Për ta bërë këtë, përdorni parametrin oom_score_adj.
Le të kthehemi te klasat QoS të CPU-së dhe të nxjerrim një analogji me vlerat oom_score_adj që përcaktojnë përparësitë e konsumit të kujtesës për pods:
- Vlera më e ulët oom_score_adj për një pod - -998 - do të thotë që një pod i tillë duhet të vritet i fundit, kjo garantuar.
- Më e larta - 1000 - është perpjekja me e mire, bishtaja të tilla vriten së pari.
- Për të llogaritur vlerat e mbetura (i shpërthyeshëm) ekziston një formulë, thelbi i së cilës qëndron në faktin se sa më shumë burime të ketë kërkuar një pod, aq më pak ka gjasa që të vritet.
"Kthesë" e dytë - limit_në_bajtë - për kufijtë. Me të, gjithçka është më e thjeshtë: ne thjesht caktojmë sasinë maksimale të memories së lëshuar, dhe këtu (ndryshe nga CPU) nuk ka dyshim se si ta masim atë (memorien).
Në total
Çdo pod në Kubernetes jepet requests и limits - të dy parametrat për CPU dhe memorie:
- bazuar në kërkesat, funksionon planifikuesi Kubernetes, i cili shpërndan pods midis serverëve;
- bazuar në të gjithë parametrat, përcaktohet klasa QoS e pod;
- Peshat relative llogariten në bazë të kërkesave të CPU-së;
- planifikuesi CFS është konfiguruar në bazë të kërkesave të CPU;
- Vrasësi OOM është konfiguruar bazuar në kërkesat e kujtesës;
- një "semafor" është konfiguruar bazuar në kufijtë e CPU;
- Bazuar në kufijtë e memories, një limit është konfiguruar për cgroup.
Në përgjithësi, kjo fotografi i përgjigjet të gjitha pyetjeve se si ndodh pjesa kryesore e menaxhimit të burimeve në Kubernetes.
Shkallëzimi automatik
K8s cluster-autoscaler
Le të imagjinojmë që i gjithë grupi është tashmë i zënë dhe duhet të krijohet një pod i ri. Ndërsa pod nuk mund të shfaqet, ajo varet në status në pritje të. Që të shfaqet, ne mund të lidhim një server të ri me grupin ose... të instalojmë cluster-autoscaler, i cili do ta bëjë këtë për ne: të porosisni një makinë virtuale nga ofruesi i cloud (duke përdorur një kërkesë API) dhe ta lidhni atë me grupin , pas së cilës pod do të shtohet.
Ky është një shkallëzim automatik i grupit Kubernetes, i cili funksionon shkëlqyeshëm (në përvojën tonë). Megjithatë, si kudo tjetër, këtu ka disa nuanca...
Për sa kohë që rritëm madhësinë e grupit, gjithçka ishte në rregull, por çfarë ndodh kur grupi filloi të çlirohej? Problemi është se migrimi i pods (për të çliruar hostet) është teknikisht shumë i vështirë dhe i shtrenjtë për sa i përket burimeve. Kubernetes përdor një qasje krejtësisht të ndryshme.
Konsideroni një grup prej 3 serverësh që kanë Deployment. Ka 6 pods: tani ka 2 për secilin server. Për disa arsye ne donim të çaktivizonim një nga serverët. Për ta bërë këtë ne do të përdorim komandën kubectl drain, e cila:
- do të ndalojë dërgimin e pods të rinj në këtë server;
- do të fshijë podet ekzistuese në server.
Meqenëse Kubernetes është përgjegjës për ruajtjen e numrit të pods (6), ai thjesht do të rikrijojë ato në nyjet e tjera, por jo në atë që është çaktivizuar, pasi është shënuar tashmë si i padisponueshëm për të pritur pods të rinj. Ky është një mekanik themelor për Kubernetes.
Sidoqoftë, këtu ka edhe një nuancë. Në një situatë të ngjashme, për StatefulSet (në vend të Deployment), veprimet do të jenë të ndryshme. Tani ne kemi tashmë një aplikacion të gjendjes - për shembull, tre pods me MongoDB, njëra prej të cilave ka një lloj problemi (të dhënat janë korruptuar ose një gabim tjetër që pengon podin të fillojë siç duhet). Dhe ne përsëri vendosim të çaktivizojmë një server. Çfarë do të ndodhë?
MongoDB mund vdes sepse ka nevojë për një kuorum: për një grup prej tre instalimesh, të paktën dy duhet të funksionojnë. Megjithatë, kjo nuk ndodh - falë PodDisruptionBudget. Ky parametër përcakton numrin minimal të kërkuar të bishtajave të punës. Duke ditur që një nga pods MongoDB nuk po funksionon më dhe duke parë që PodDisruptionBudget është caktuar për MongoDB minAvailable: 2, Kubernetes nuk do t'ju lejojë të fshini një pod.
Përfundimi: në mënyrë që lëvizja (dhe në fakt, rikrijimi) i pods të funksionojë siç duhet kur grupi lëshohet, është e nevojshme të konfiguroni PodDisruptionBudget.
Shkallëzimi horizontal
Le të shqyrtojmë një situatë tjetër. Ekziston një aplikacion që funksionon si Deployment në Kubernetes. Trafiku i përdoruesit vjen në grupet e tij (për shembull, ka tre prej tyre) dhe ne matim një tregues të caktuar në to (të themi, ngarkesa e CPU). Kur ngarkesa rritet, ne e regjistrojmë atë në një orar dhe rrisim numrin e pods për të shpërndarë kërkesat.
Sot në Kubernetes kjo nuk ka nevojë të bëhet me dorë: një rritje/ulje automatike e numrit të pods konfigurohet në varësi të vlerave të treguesve të ngarkesës së matur.
Pyetjet kryesore këtu janë: çfarë saktësisht të matet и si të interpretohet vlerat e marra (për marrjen e një vendimi për ndryshimin e numrit të bishtajave). Mund të matni shumë:
Si ta bëni këtë teknikisht - mblidhni metrikë, etj. - Unë fola në detaje në raport për . Dhe këshilla kryesore për zgjedhjen e parametrave optimalë është eksperiment!
Ka (Ngopja e përdorimit dhe gabimet), kuptimi i të cilit është si më poshtë. Mbi çfarë baze ka kuptim të shkallëzoni, për shembull, php-fpm? Bazuar në faktin se punëtorët po mbarojnë, kjo është shfrytëzim. Dhe nëse punëtorët kanë mbaruar dhe lidhjet e reja nuk pranohen, kjo tashmë është ngopje. Të dy këta parametra duhet të maten dhe në varësi të vlerave duhet të bëhet shkallëzim.
Në vend të një përfundimi
Raporti ka një vazhdim: në lidhje me shkallëzimin vertikal dhe mënyrën e zgjedhjes së burimeve të duhura. Unë do të flas për këtë në videot e ardhshme - abonohuni që të mos humbisni!
Video dhe sllajde
Video nga performanca (44 minuta):
Prezantimi i raportit:
PS
Raporte të tjera rreth Kubernetes në blogun tonë:
- «» (Andrey Polovov; 8 Prill 2019 në Saint HighLoad++);
- «» (Dmitry Stolyarov; 8 nëntor 2018 në HighLoad++);
- «» (Dmitry Stolyarov; 28 maj 2018 në RootConf);
- «» (Dmitry Stolyarov; 7 nëntor 2017 në HighLoad++);
- «» (Dmitry Stolyarov; 6 qershor 2017 në RootConf).
Burimi: www.habr.com