ProHoster > Blog > Administrim > Tre nivele të automatizmit në Kubernetes: si t'i përdorim ato me efikasitet

Tre nivele të automatizmit në Kubernetes: si t'i përdorim ato me efikasitet

Tre nivele të automatizmit në Kubernetes: si t'i përdorim ato me efikasitet
Për të zotëruar plotësisht Kubernetes, duhet të njihni mënyrat e ndryshme të shkallëzimit të burimeve të klasterit: sipas fjalëve të zhvilluesve të sistemit, kjo është një nga detyrat kryesore të Kubernetes. Ne kemi përgatitur një përmbledhje të nivelit të lartë të mekanizmave të automatizimit horizontal dhe vertical, si dhe rekomandime për t'i përdorur ato në mënyrë efektive.

Artikulli Kubernetes Autoscaling 101: Cluster Autoscaler, Horizontal Autoscaler, dhe Vertical Pod Autoscaler u përkthye nga ekipi që implementoi automatizimin në Kubernetes aaS nga Mail.ru.

Pse është e rëndësishme të mendoni për shkallëzimin

Kubernetes — njĂ« mjet pĂ«r menaxhimin e burimeve dhe orkestrimin. Sigurisht, Ă«shtĂ« mirĂ« tĂ« eksperimentoni me funksionalitetet e shkĂ«lqyera tĂ« implementimit, monitorimit dhe menaxhimit tĂ« podĂ«ve (moduli pod — njĂ« grup kontejnerĂ«sh qĂ« drejtohen nĂ« pĂ«rgjigje tĂ« kĂ«rkesĂ«s).

Megjithatë, duhet të mendojmë edhe për këto çështje:

  1. Si të shkallëzohet modulet dhe aplikacionet?
  2. Si të mbahen kontejnerët në gjendje funksionale dhe efektive?
  3. Si të reagoni ndaj ndryshimeve të vazhdueshme në kodin dhe ngarkesat e punës nga përdoruesit?

Konfigurimi i klastereve Kubernetes për ekuilibrimin e burimeve dhe performancës mund të jetë një sfidë e komplikuar, kërkon njohuri ekspertësh mbi funksionimin e brendshëm të Kubernetes. Ngarkesa në aplikacionin tuaj ose shërbime mund të ndryshojë gjatë ditës ose madje brenda një ore, prandaj ekuilibrimin duhet ta perceptoni si një proces të vazhdueshëm.

Nivelet e automatizimit të Kubernetes

Automatizimi efektiv kërkon koordinim midis dy niveleve:

  1. Niveli i podëve, duke përfshirë automatizimin horizontal (Horizontal Pod Autoscaler, HPA) dhe automatizimin vertical (Vertical Pod Autoscaler, VPA). Ky është shkallëzimi i burimeve aktuale për kontejnerët tuaj.
  2. Niveli i klasterit, i cili menaxhohet nga sistemi i automatizimit të klasterit (Cluster Autoscaler, CA), ai rrit ose ul numrin e njësive brenda klasterit.

Moduli i automatizimit horizontal (HPA)

Siç sugjeron emri, HPA shkallëzon numrin e replikave të podëve. Si nxitës për të ndryshuar numrin e replikave, shumica e devopëve përdorin ngarkesën e procesorit dhe kujtesës. Megjithatë, sisteme mund të shkallëzohen në bazë të metrikave të përdoruesve, kombinimi i tyre metrikave të jashtme apo madje Skema e nivelit të lartë e funksionimit të HPA:.

Schemi i punës HPA në një nivel të lartë:

  1. HPA monitoron vazhdimisht vlerat e metrikeve të vendosura gjatë instalimit, me intervalin default prej 30 sekondash.
  2. HPA përpiqet të rrisë numrin e moduleve nëse arrihet kufiri i caktuar.
  3. HPA përditëson numrin e replikave brenda menaxherit të implementimit/replikimit.
  4. Menaxheri i implementimit/replikimit pastaj deployon të gjitha modulet e nevojshme shtesë.

Tre nivele të automatizmit në Kubernetes: si t'i përdorim ato me efikasitet
HPA aktivizon procesin e implementimit të moduleve kur arrihet vlera kufitare e metrikeve.

Kur përdorni HPA, merrni parasysh të följat:

  • Intervali i kontrollit tĂ« HPA default Ă«shtĂ« 30 sekonda. Ai pĂ«rcaktohet nga flagu horizontal-pod-autoscaler-sync-period nĂ« menaxherin e kontrollit.
  • Gabimi relativ default Ă«shtĂ« 10%.
  • Pas rritjes sĂ« fundit tĂ« numrit tĂ« moduleve, HPA pret stabilizimin e metrikeve pĂ«r tre minuta. Ky interval pĂ«rcaktohet nga flagu horizontal-pod-autoscaler-upscale-delay.
  • Pas uljes sĂ« fundit tĂ« numrit tĂ« moduleve, HPA pret stabilizimin pĂ«r pesĂ« minuta. Ky interval pĂ«rcaktohet nga flagu horizontal-pod-autoscaler-downscale-delay.
  • HPA funksionon mĂ« sĂ« miri me objektet e implementimit, jo me menaxherĂ«t e replikimeve. Automatizimi horizontal i skalimit nuk Ă«shtĂ« i pajtueshĂ«m me pĂ«rditĂ«simin e vazhdueshĂ«m (rolling update) qĂ« manipulon drejtpĂ«rdrejt me menaxherĂ«t e replikimit. Kur deployohet, numri i replikave varet drejtpĂ«rdrejt nga objektet e implementimit.

Skalimi vertical i pod’ave

Skalimi vertical (VPA) rezervon mĂ« shumĂ« (ose mĂ« pak) kohĂ« CPU ose memorie pĂ«r pod’at ekzistues. ËshtĂ« e pĂ«rshtatshme pĂ«r pod’at me ruajtje gjendjeje (stateful) ose pa tĂ« (stateless), por kryesisht Ă«shtĂ« e destinuar pĂ«r shĂ«rbime stateful. MegjithatĂ«, mund tĂ« aplikoni VPA edhe pĂ«r modulet pa ruajtje gjendjeje, nĂ«se Ă«shtĂ« e nevojshme pĂ«r tĂ« rregulluar automatikisht sasinĂ« e resurseve fillimisht tĂ« alokuara.

VPA gjithashtu reagon ndaj ngjarjeve OOM (out of memory, mungesĂ« memorie). PĂ«r tĂ« ndryshuar kohĂ«n e procesorit dhe sasinĂ« e memories, nevojitet ribashkimi i pod’ave. GjatĂ« ribashkimit, VPA respekton buxhetin e shpĂ«rndarjes (pods distribution budget, PDB), pĂ«r tĂ« garantuar numrin minimal tĂ« nevojshĂ«m tĂ« moduleve.

Ju mund të vendosni një vëllim minimal dhe maksimal burimesh për secilën modulin. Në këtë mënyrë, mund të kufizoni vëllimin maksimal të memories të caktuar në një kufi prej 8 GB. Kjo është e dobishme, nëse nyjat aktuale nuk mund të caktojnë më shumë se 8 GB memorie për kontejnerin. Specifikimet e detajuara dhe mekanizmi i funksionimit janë përshkruar në wiki zyrtare VPA.

Për më tepër, VPA ka një funksion interesant rekomandimesh (VPA Recommender). Ai ndjek përdorimin e burimeve dhe ngjarjet OOM të të gjitha moduleve, për të sugjeruar vlera të reja për memory dhe kohën e procesorit bazuar në një algoritëm inteligjent që merr parasysh metrikat historike. Ka gjithashtu një ndërfaqe API që pranon një deshkriptor pod dhe kthen vlerat e sugjeruara për burimet.

Duhet theksuar se VPA Recommender nuk ndjek "kufirin" e burimeve. Kjo mund tĂ« çojĂ« nĂ« monopolizimin e burimeve brenda nyjave nga moduli. ËshtĂ« mĂ« mirĂ« tĂ« vendosni njĂ« kufi nĂ« nivelin e hapĂ«sirĂ«s emrore pĂ«r tĂ« shmangur shpenzimin e madh tĂ« memories ose kohĂ«s sĂ« procesorit.

Schemi e nivelit të lartë e funksionimit të VPA:

  1. VPA kontrollon vazhdimisht vlerat e metrikave të specifikuara gjatë instalimit, me një interval të paracaktuar prej 10 sekondash.
  2. Nëse arrihet pragu i caktuar, VPA përpiqet të ndryshojë sasinë e caktuar të burimeve.
  3. VPA përditëson sasinë e burimeve brenda kontrolluesit të desplejimit/replikimit.
  4. Kur modulat rinisin, të gjitha burimet e reja aplikohen për instancat e krijuara.

Tre nivele të automatizmit në Kubernetes: si t'i përdorim ato me efikasitet
VPA shton sasinë e nevojshme të burimeve

Merrni parasysh këto pika gjatë përdorimit të VPA:

  • Skalimi kĂ«rkon patjetĂ«r rinisjen e pod-it. Kjo Ă«shtĂ« e nevojshme pĂ«r tĂ« shmangur funksionimin e pasigurt pas ndryshimeve. PĂ«r besueshmĂ«ri, modulat rinisin dhe shpĂ«rndahen nĂ« nyja sipas burimeve tĂ« reja tĂ« caktuara.
  • VPA dhe HPA pĂ«r momentin nuk janĂ« tĂ« pajtueshme me njĂ«ra-tjetrĂ«n dhe nuk mund tĂ« punojnĂ« nĂ« tĂ« njĂ«jtat pod-e. NĂ«se aplikoni tĂ« dy mekanizmat e skalimit nĂ« njĂ« klastri, sigurohuni qĂ« konfigurimet tĂ« mos lejojnĂ« qĂ« ata tĂ« aktivizohen nĂ« tĂ« njĂ«jtat objekte.
  • VPA konfiguron kĂ«rkesat e konteinerĂ«ve pĂ«r burime, duke u bazuar vetĂ«m nĂ« pĂ«rdorimin e tyre tĂ« kaluar dhe aktual. Ai nuk vendos kufij pĂ«r pĂ«rdorimin e burimeve. Mund tĂ« ndodhin probleme me funksionimin e saktĂ« tĂ« aplikacioneve, tĂ« cilat fillojnĂ« tĂ« kapin gjithnjĂ« e mĂ« shumĂ« burime, duke bĂ«rĂ« qĂ« Kubernetes tĂ« ndalĂ« kĂ«tĂ« pod.
  • VPA Ă«shtĂ« ende nĂ« fazĂ«n fillestare tĂ« zhvillimit. BĂ«ni kujdes, sistemi mund tĂ« pĂ«rjetojĂ« disa ndryshime nĂ« kohĂ«t nĂ« vijim. Mund tĂ« lexoni mbi kufizimet e njohura dhe planin e zhvillimit. Pra, nĂ« planet Ă«shtĂ« realizimi i bashkĂ«punimit mes VPA dhe HPA, si dhe shpĂ«rndarja e moduleve sĂ« bashku me politikĂ«n pĂ«r automatizimin vertical tĂ« shkallĂ«zimit pĂ«r to (pĂ«r shembull, njĂ« etiketĂ« speciale 'requires VPA').

Automatizimi i përmasave të klasterit Kubernetes

Automatizimi i pĂ«rmasave tĂ« klasterit (Cluster Autoscaler, CA) ndryshon numrin e nyjeve, duke u bazuar nĂ« numrin e moduleve tĂ« pritura pod. Sistemi kontrollon herĂ« pas here nĂ«se ka module tĂ« pritura — dhe rrit numrin e klasterit, nĂ«se kĂ«rkohen mĂ« shumĂ« burime dhe nĂ«se klasteri nuk kalon kufijtĂ« e vendosur. CA bashkĂ«punon me ofruesin e shĂ«rbimeve cloud, duke kĂ«rkuar nyje shtesĂ« ose duke çliruar ato qĂ« nuk janĂ« nĂ« pĂ«rdorim. Versioni i parĂ« publik i CA u prezantua nĂ« Kubernetes 1.8.

Diagrami i punës së CA:

  1. CA kontrollon nëse ka module në gjendje pritjeje me një interval prej 10 sekondash, me të drejtë.
  2. Nëse një ose disa module janë në gjendje pritjeje për shkak të mungesës së burimeve të disponueshme në klaster për t'i shpërndarë, ai përpiqet të përgatisë një ose disa nyje shtesë.
  3. Kur ofruesi i shërbimeve cloud alokon nyjën e nevojshme, ajo i bashkohet klasterit dhe është gati për të shërbyer moduleve pod.
  4. Planifikuesi i Kubernetes shpĂ«rndan modulĂ«t e pritur nĂ« nyjĂ«n e re. NĂ«se pas kĂ«saj disa module akoma mbeten nĂ« gjendje pritjeje, procesi pĂ«rsĂ«ritet — dhe nyje tĂ« reja shtohen nĂ« klaster.

Tre nivele të automatizmit në Kubernetes: si t'i përdorim ato me efikasitet
Alokimi automatik i nyjeve të klasterit në cloud

Merrni parasysh këtë kur përdorni CA:

  • CA garanton qĂ« tĂ« gjitha modulĂ«t nĂ« klaster kanĂ« hapĂ«sirĂ« pĂ«r tĂ« funksionuar, pa marrĂ« parasysh nivelin e ngarkesĂ«s sĂ« procesorit. PĂ«r mĂ« tepĂ«r, ai pĂ«rpiqet tĂ« garantojĂ« qĂ« nĂ« klaster nuk ka nyje tĂ« panevojshme.
  • CA regjistron nevojĂ«n pĂ«r shkallĂ«zim pas rreth 30 sekondash.
  • Pas qĂ« nodi bĂ«het i panevojshĂ«m, CA nĂ« mĂ«nyrĂ« tĂ« paracaktuar pret 10 minuta pĂ«rpara se tĂ« shkallĂ«zojĂ« sistemin.
  • NĂ« sistemin e automatikisht shkallĂ«zues, ekziston koncepti i zgjeruesve (expanders). KĂ«to janĂ« strategji tĂ« ndryshme pĂ«r pĂ«rzgjedhjen e grupit tĂ« nodĂ«ve nĂ« tĂ« cilin do tĂ« shtohen tĂ« rinjtĂ«.
  • Apliko me pĂ«rgjegjĂ«si opsionin cluster-autoscaler.kubernetes.io/safe-to-evict (true). NĂ«se vendosni shumĂ« pod’e ose nĂ«se shumĂ« prej tyre shpĂ«rndahen nĂ« tĂ« gjithĂ« nodĂ«t, do tĂ« humbni nĂ« masĂ« mundĂ«sinĂ« pĂ«r tĂ« shkallĂ«zuar pĂ«rsĂ«ri klasterin.
  • PĂ«rdorni PodDisruptionBudgets, pĂ«r tĂ« parandaluar heqjen e pod’eve, e cila mund tĂ« shkaktojĂ« qĂ« njĂ« pjesĂ« e aplikacionit tuaj tĂ« dĂ«shtojĂ« plotĂ«sisht.

Si sistemet e automatikisht shkallëzuesit të Kubernetes ndërveprojnë me njëra-tjetrën

PĂ«r harmoni ideale duhet tĂ« aplikohet automatikisht shkallĂ«zimi njĂ«kohĂ«sisht nĂ« nivelin e pod’eve (HPA/VPA) dhe nĂ« nivelin e klasterit. Ato ndĂ«rveprojnĂ« relativisht thjeshtĂ« me njĂ«ra-tjetrĂ«n:

  1. HPA ose VPA pĂ«rditĂ«sojnĂ« replikat e pod’eve ose burimet e dedikuara pĂ«r pod’ët ekzistues.
  2. Nëse mungojnë nodë për shkallëzimin e planifikuar, CA vëren podët që janë në gjendje pritjeje.
  3. CA dedikon nodë të reja.
  4. Modulet shpërndahen mbi nodët e reja.

Tre nivele të automatizmit në Kubernetes: si t'i përdorim ato me efikasitet
Sistemi i bashkuar i shkallëzimit të Kubernetes

Gabimet tipike në automatikisht shkallëzimin e Kubernetes

Ekziston një numër problematikave tipike me të cilat përballen dev ops-ët kur përpiqen të zbatojnë automatikisht shkallëzimin.

HPA dhe VPA varen nga metrika dhe disa të dhëna historike. Nëse ndahen burime të pamjaftueshme, modulet do të mbyllen dhe nuk do të jenë në gjendje të gjenerojnë metrika. Në këtë rast, automatikisht shkallëzimi nuk do të ndodhë kurrë.

VetĂ« operacioni i shkallĂ«zimit Ă«shtĂ« i ndjeshĂ«m ndaj kohĂ«s. Ne duam qĂ« modulet dhe klasteri tĂ« shkallĂ«zohen shpejt — pĂ«rpara se pĂ«rdoruesit tĂ« vĂ«rejnĂ« ndonjĂ« problem dhe dĂ«shtim. Prandaj, duhet marrĂ« parasysh koha mesatare e shkallĂ«zimit tĂ« pod’eve dhe klasterit.

Skenari ideal — 4 minuta:

  1. 30 sekonda. PĂ«rditĂ«simi i metrikes synuese: 30−60 sekonda.
  2. 30 sekonda. HPA kontrollon vlerat e metrikave: 30 sekonda.
  3. Më pak se 2 sekonda. Modulet pod krijohen dhe kalojnë në gjendje pritjeje: 1 sekondë.
  4. Më pak se 2 sekonda. CA sheh modulet në pritje dhe dërgon thirrjet për përgatitjen e nodëve: 1 sekondë.
  5. 3 minuta. Ofruesi i cloud ndan nyjat. K8s pret deri sa ato të jenë gati: deri në 10 minuta (varet nga disa faktorë).

Skenari mĂ« i keq (mĂ« real) — 12 minuta:

  1. 30 sekonda. Përditësimi i metrikave qëllimore.
  2. 30 sekonda. HPA kontrollon vlerat e metrikave.
  3. Më pak se 2 sekonda. Modulët pod krijohen dhe kalojnë në gjendjen pritëse.
  4. Më pak se 2 sekonda. CA sheh modulët në pritje dhe dërgon thirrje për përgatitjen e nyjeve.
  5. 10 minuta. Ofruesi i cloud ndan nyjat. K8s pret deri sa ato të jenë gati. Koha e pritjes varet nga disa faktorë, si vonesa e ofruesit, vonesa e OS, funksionimi i mjeteve ndihmëse.

Mos ngatërroni mekanizmat e shkallëzimit të ofruesve të cloud me CA-në tonë. E fundit funksionon brenda klasterit Kubernetes, ndërsa mekanizmi i ofruesit të cloud funksionon mbi bazën e shpërndarjes së nyjeve. Ai nuk di se çfarë ndodh me pod-at ose aplikacionin tuaj. Këto sisteme funksionojnë paralelisht.

Si të menaxhoni shkallëzimin në Kubernetes

  1. Kubernetes është një mjet për menaxhimin e burimeve dhe orkestrimin. Operacionet e menaxhimit të pod-ëve dhe burimeve të klasterit janë një pikë kyçe në zotërimin e Kubernetes.
  2. Masteroni logjikën e shkallëzimit të pod-ëve duke marrë parasysh HPA-në dhe VPA-në.
  3. CA duhet përdorur vetëm nëse e kuptoni mirë nevojat e pod-ëve dhe kontejnerëve tuaj.
  4. Për konfigurimin optimal të klasterit, duhet të kuptoni se si sistemet e ndryshme të shkallëzimit funksionojnë së bashku.
  5. Kur vlerësoni kohën e shkallëzimit, mbani në mend skenarët më të keq dhe më të mirë.

Burimi: habr.com

Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS đŸ”„ Blini hosting tĂ« besueshĂ«m pĂ«r faqe interneti me mbrojtje nga DDoS, serverĂ« VPS VDS | ProHoster