ProHoster > Blog > Administrimi > Tre nivele të automatikës në Kubernetes: si t'i përdorim ato në mënyrë efektive

Tre nivele të automatikës në Kubernetes: si t'i përdorim ato në mënyrë efektive

Tre nivele të automatikës në Kubernetes: si t'i përdorim ato në mënyrë efektive
Për t'u njohur plotësisht me Kubernetes, është e nevojshme të njihni mënyrat e ndryshme të skalimit të burimeve të klasterit: sipas 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 të skalimit dhe rritjes së madhësisë së klasterëve, si dhe rekomandime se si t'i përdorni 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 Kubernetes aaS nga Mail.ru.

Pse është e rëndësishme të mendoni për skalimin

Kubernetes — njĂ« mjet pĂ«r menaxhimin e burimeve dhe orkestrimin. Sigurisht, Ă«shtĂ« e bukur tĂ« merremi me funksionet e mrekullueshme tĂ« implementimit, monitorimit dhe menaxhimit tĂ« pod-Ă«ve (moduli pod Ă«shtĂ« njĂ« grup kontejnerĂ«sh qĂ« ekzekutohen nĂ« pĂ«rgjigje tĂ« njĂ« kĂ«rkese).

Megjithatë, është e nevojshme të mendohet edhe për këto pyetje:

  1. Si të shkallëzojmë modulet dhe aplikacionet?
  2. Si t'i mbajmë kontejnerët në një gjendje funksionale dhe efektive?
  3. Si të reagojmë ndaj ndryshimeve të vazhdueshme në kod dhe ngarkesat nga përdoruesit?

Konfigurimi i klastereve Kubernetes për balancimin e burimeve dhe performancës mund të jetë një nga detyrat më të vështira, duke kërkuar njohuri ekspertësh për funksionimin e brendshëm të Kubernetes. Ngarkesa në aplikacionin tuaj ose shërbimet mund të ndryshojë gjatë ditës ose madje brenda një ore, kështu që balancimi duhet të paraqitet si një proces i vazhdueshëm.

Nivelet e automatizimit në Kubernetes

Automatizimi efektiv kërkon koordinim midis dy niveleve:

  1. Niveli i pod-ëve, i cili përfshin automatizimin horizontal (Horizontal Pod Autoscaler, HPA) dhe automatizimin vertical (Vertical Pod Autoscaler, VPA). Ky automatizim përfshin rritjen e burimeve ekzistuese për kontejnerët tuaj.
  2. Niveli i klasterit, i cili menaxhohet nga sistemi i automatizimit të klasterit (Cluster Autoscaler, CA), i cili rrit ose ul numrin e nyjeve brenda klasterit.

Moduli i automatizimit horizontal (HPA)

Siç sugjeron emri, HPA automatizon numrin e replikave të pod-ëve. Si triger të ndryshimit të numrit të replikave, shumica e zhvilluesve të DevOps përdorin ngarkesën e procesorit dhe të memories. Megjithatë, është e mundur të automatizohet sistemi duke u bazuar në metrika të personalizuara, kombinimin e tyre metrika të jashtme ose madje Schema e nivelit të lartë e punës së HPA:.

HPA kontrollon vazhdimisht vlerat e metrikeve të caktuara gjatë vendosjes, me një interval të paracaktuar prej 30 sekondash.

  1. HPA përpiqet të rrisë numrin e moduleve nëse arrihet një kufi i caktuar.
  2. HPA përditëson numrin e replikave brenda kontrolluesit të implementimit/replikimit.
  3. Kontrolluesi i implementimit/replikimit pastaj implementon të gjitha modulët e nevojshëm shtesë.
  4. HPA fillon procesin e implementimit të moduleve me arritjen e vlerës së kufirit të metrikeve

Tre nivele të automatikës në Kubernetes: si t'i përdorim ato në mënyrë efektive
Kur përdorni HPA, merrni parasysh sa vijon:

Intervali i kontrollit të HPA është në default 30 sekonda. Ky është vendosur me flamurin

  • horizontal-pod-autoscaler-sync-period nĂ« menaxherin e kontrolluesit. Gabimi relativ nĂ« default Ă«shtĂ« 10%.
  • Pas rritjes sĂ« fundit tĂ« numrit tĂ« moduleve, HPA pret stabilizimin e metrikeve pĂ«r tre minuta. Ky interval Ă«shtĂ« vendosur me flamurin
  • horizontal-pod-autoscaler-upscale-delay Pas uljes sĂ« fundit tĂ« numrit tĂ« moduleve, HPA pret stabilizimin pĂ«r pesĂ« minuta. Ky interval Ă«shtĂ« vendosur me flamurin.
  • horizontal-pod-autoscaler-downscale-delay HPA funksionon mĂ« mirĂ« me objektet e implementimit dhe jo me kontrolluesit e replikimit. Automatizimi horizontal Ă«shtĂ« i papajtueshĂ«m me pĂ«rditĂ«simet e rregullta (rolling update) qĂ« ndikojnĂ« drejtpĂ«rdrejt nĂ« kontrolluesit e replikimit. Kur implementohet, numri i replikave varet drejtpĂ«rdrejt nga objektet e implementimit..
  • HPA funksionon mĂ« mirĂ« me objektet e shpĂ«rndarjes, jo me kontrollorĂ«t e replikimit. Autoskalimi horizontal Ă«shtĂ« nĂ« kundĂ«rshtim me pĂ«rditĂ«simin rresht, i cili manipulohet drejtpĂ«rdrejt nga kontrollorĂ«t e replikimit. GjatĂ« shpĂ«rndarjes, numri i replikave varet drejtpĂ«rdrejt nga objektet e shpĂ«rndarjes.

Automatizimi vertical i pod-Ă«ve

Automatizimi vertical (VPA) ndan më shumë (ose më pak) kohë procesori ose memorie për pod-ët ekzistues. Ky është i përshtatshëm për pod-et me ruajtje (stateful) ose pa ruajtje (stateless), por kryesisht është i dizajnuar për shërbimet stateful. Megjithatë, mund ta aplikoni VPA për modulet pa ruajtje nëse është e nevojshme të korrektohet automatikisht sasia fillimisht e ndarë e burimeve.

VPA gjithashtu reagon ndaj ngjarjeve OOM (out of memory, mungesë memorie). Për të ndryshuar kohën e përpunimit dhe sasinë e memories, nevojitet rivendosja e pod-ëve. Gjatë rivendosjes, VPA respekton buxhetin e shpërndarjes (pods distribution budget, PDB), për të garantuar numrin minimal të moduleve të nevojshëm.

Mund të vendosni një sasi minimale dhe maksimale burimesh për çdo modul. Pra, është e mundur të kufizohet sasia maksimale e memories në 8 GB. Kjo është e dobishme nëse nodet aktuale saktësisht nuk mund të ofrojnë më shumë se 8 GB memorie për kontejnerin. Specifikimet e detajuara dhe mekanizmi i funksionimit janë përshkruar në wiki-n zyrtare të VPA.

Për më tepër, VPA ka një funksion interesant rekomandimesh (VPA Recommender). Ai monitoron përdorimin e burimeve dhe ngjarjet OOM të të gjithë moduleve, për t'u ofruar vlera të reja për memorie dhe kohën e procesorit bazuar në një algoritëm inteligjent që merr parasysh metrikat historike. Gjithashtu, ka një ndërfaqe API që merr një descriptor pod dhe kthen vlerat e rekomanduara për burimet.

Duhet theksuar se VPA Recommender nuk monitoron "limitin" e burimeve. Kjo mund tĂ« çojĂ« nĂ« faktin qĂ« moduli monopolizon burimet brenda nodĂ«ve. ËshtĂ« mĂ« mirĂ« tĂ« vendosni njĂ« kufi nĂ« nivelin e hapĂ«sirĂ«s emĂ«rtuese, pĂ«r tĂ« shmangur shpenzime tĂ« mĂ«dha tĂ« memories ose kohĂ«s sĂ« procesorit.

Skema e punës së VPA në nivel të lartë:

  1. VPA kontrollon vazhdimisht vlerat e metrikave të specifikuara gjatë vendosjes, me një interval të paracaktuar prej 10 sekondash.
  2. Nëse arrihet threshold-i i caktuar, VPA përpiqet të ndryshojë sasinë e burimeve të ndara.
  3. VPA përditëson sasinë e burimeve brenda kontrolluesit të shpërndarjes/replikimit.
  4. Kur moduli riniset, të gjitha burimet e reja aplikohen në instancat e krijuara.

Tre nivele të automatikës në Kubernetes: si t'i përdorim ato në mënyrë efektive
VPA shton sasinë e nevojshme të burimeve

Konsideroni këto pika kur përdorni VPA:

  • Skalimi kĂ«rkon rinisjen e detyrueshme tĂ« pod-it. Kjo Ă«shtĂ« e nevojshme pĂ«r tĂ« shmangur punĂ«n e pasigurt pas ndryshimeve. PĂ«r siguri, modulet rinisen dhe shpĂ«rndahen nĂ« nodĂ« sipas burimeve tĂ« reja tĂ« ndara.
  • VPA dhe HPA aktualisht nuk janĂ« tĂ« pajtueshĂ«m me njĂ«ri-tjetrin dhe nuk mund tĂ« funksionojnĂ« mbi tĂ« njĂ«jtat pod. NĂ«se pĂ«rdorni tĂ« dy mekanizmat e skalimit nĂ« njĂ« grup, sigurohuni qĂ« konfigurat e tyre mos t'i lejojnĂ« tĂ« aktivizohen mbi tĂ« njĂ«jtat objekte.
  • VPA konfiguron kĂ«rkesat e burimeve tĂ« kontejnerĂ«ve vetĂ«m nĂ« bazĂ« tĂ« pĂ«rdorimit tĂ« kaluar dhe aktual. Ai nuk vendos limite pĂ«r pĂ«rdorimin e burimeve. Mund tĂ« ndodhin probleme me funksionimin e gabuar tĂ« aplikacioneve, tĂ« cilat do tĂ« fillojnĂ« tĂ« konsumojnĂ« gjithnjĂ« e mĂ« shumĂ« burime, duke shkaktuar qĂ« Kubernetes tĂ« ndalojĂ« kĂ«tĂ« pod.
  • VPA Ă«shtĂ« ende nĂ« fazĂ«n e hershme tĂ« zhvillimit. BĂ«ni kujdes qĂ« sistemi mund tĂ« kalojĂ« disa ndryshime sĂ« shpejti. Mund tĂ« lexoni rreth kufizimeve tĂ« njohura dhe planet e zhvillimit. KĂ«shtu, nĂ« planet Ă«shtĂ« tĂ« realizohet bashkĂ«punimi i VPA dhe HPA, si dhe shpĂ«rndarja e moduleve sĂ« bashku me politikĂ«n e automatikĂ«s vertikale pĂ«r to (pĂ«r shembull, njĂ« etiketĂ« e veçantĂ« 'requires VPA').

Automatizimi i klasterit Kubernetes

Automatizimi i klasterit (Cluster Autoscaler, CA) ndryshon numrin e nodĂ«ve, nĂ« bazĂ« tĂ« numrit tĂ« moduleve pod qĂ« presin. Sistemi kontrollon periodikisht nĂ«se ka module nĂ« pritje — dhe rrit madhĂ«sinĂ« 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 nodĂ« tĂ« tjera ose çliruar ato qĂ« nuk janĂ« nĂ« pĂ«rdorim. Versioni i parĂ« publik i CA u prezantua nĂ« Kubernetes 1.8.

Skema e punës së CA në nivel të lartë:

  1. CA kontrollon nëse ka module në pritje me një interval të paracaktuar prej 10 sekondash.
  2. Nëse një ose disa module janë në pritje për shkak se klasteri nuk ka burime të mjaftueshme për t'i alokuar, ai përpiqet të përgatisë një ose disa nodë të tjera.
  3. Kur ofruesi i shërbimeve cloud ofron nodin e nevojshëm, ai bashkohet me klasterin dhe është gati të shërbejë moduleve pod.
  4. Planifikuesi i Kubernetes shpĂ«rndan module tĂ« pritura nĂ« nodet e reja. NĂ«se pas kĂ«saj disa module ende mbeten nĂ« pritje, procesi pĂ«rsĂ«ritet — dhe nodĂ« tĂ« reja shtohen nĂ« klaster.

Tre nivele të automatikës në Kubernetes: si t'i përdorim ato në mënyrë efektive
Shpërndarja automatike e nodëve të klasterit në cloud

Konsideroni këtë gjatë përdorimit të CA:

  • CA garanton qĂ« tĂ« gjitha modulet nĂ« klaster kanĂ« vend pĂ«r tĂ« funksionuar, pavarĂ«sisht nga niveli i ngarkesĂ«s sĂ« procesorit. PĂ«r mĂ« tepĂ«r, ai pĂ«rpiqet tĂ« sigurojĂ« qĂ« nĂ« klaster nuk ka nodĂ« tĂ« panevojshme.
  • CA regjistron nevojĂ«n pĂ«r skalim rreth 30 sekonda.
  • Pasi njĂ« nod bĂ«het i panevojshĂ«m, CA sipas parazgjedhjes pret 10 minuta para se tĂ« ndryshojĂ« madhĂ«sinĂ« e sistemit.
  • NĂ« sistemin e automatizimit tĂ« skalimit ekziston koncepti i zgjeruesve (expanders). KĂ«to janĂ« strategji tĂ« ndryshme pĂ«r tĂ« zgjedhur grupin e nodĂ«ve, nĂ« tĂ« cilin do tĂ« shtohen tĂ« reja.
  • PĂ«rdorni mundĂ«sinĂ« me pĂ«rgjegjĂ«si cluster-autoscaler.kubernetes.io/safe-to-evict (true). NĂ«se vendosni shumĂ« pod’e ose nĂ«se shumĂ« prej tyre janĂ« shpĂ«rndarĂ« mbi tĂ« gjitha nyjat, do tĂ« humbni nĂ« masĂ« mundĂ«sinĂ« pĂ«r tĂ« zvogĂ«luar shkallĂ«n e klasterit.
  • PĂ«rdorni PodDisruptionBudgets, pĂ«r tĂ« parandaluar fshirjen e pod’eve, duke bĂ«rĂ« qĂ« pjesa e aplikacionit tuaj mund tĂ« dĂ«shtojĂ« krejtĂ«sisht.

Si sistemet e autoskalimit Kubernetes ndërveprojnë me njëra-tjetrën

PĂ«r njĂ« harmoni tĂ« pĂ«rsosur, duhet tĂ« pĂ«rdorni autoskalimin si nĂ« nivelin e pod’eve (HPA/VPA), ashtu edhe nĂ« nivelin e klasterit. Ato ndĂ«rveprojnĂ« relativisht lehtĂ« me njĂ«ra-tjetrĂ«n:

  1. HPA ose VPA pĂ«rditĂ«sojnĂ« replikat e pod’eve ose resurset e dedikuara pĂ«r pod’ët ekzistues.
  2. NĂ«se ka mungesĂ« nyjash pĂ«r shkallĂ«zimin e planifikuar, CA vĂ«ren se ka pod’e nĂ« gjendje pritjeje.
  3. CA ndan nyja të reja.
  4. Modulet shpërndahen mbi nyjat e reja.

Tre nivele të automatikës në Kubernetes: si t'i përdorim ato në mënyrë efektive
Sistemi i përbashkët i shkallëzimit Kubernetes

Gabimet tipike në autoskalimin Kubernetes

Ekzistojnë disa probleme tipike me të cilat DevOps përballen kur përpiqen të zbatojnë autoskalimin.

HPA dhe VPA varen nga metrikat dhe disa të dhëna historike. Nëse resurseve u janë dhënë më pak se sa nevojiten, modulet do të zvogëlohen dhe nuk do të kenë mundësi të gjenerojnë metrika. Në këtë rast, autoskalimi nuk do të realizohet kurrë.

Operacioni i shkallĂ«zimit Ă«shtĂ« i ndjeshĂ«m ndaj kohĂ«s. Ne duam qĂ« modulet dhe klasteri tĂ« shkallĂ«zohen shpejt — para se pĂ«rdoruesit tĂ« vĂ«rejnĂ« ndonjĂ« problem apo dĂ«shtim. Prandaj duhet tĂ« merrni parasysh kohĂ«n mesatare tĂ« shkallĂ«zimit tĂ« pod’eve dhe klasterit.

Scenari ideal është 4 minuta:

  1. 30 sekonda. Rindërtimi i metrikave të synuara: 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 nyjave: 1 sekondë.
  5. 3 minuta. Ofruesi i cloud-it ndan nyja. K8s pret që ato të jenë gati: deri në 10 minuta (varet nga disa faktorë).

Scenari më i keq (më realist) është 12 minuta:

  1. 30 sekonda. Rindërtimi i metrikave të synuara.
  2. 30 sekonda. HPA kontrollon vlerat e metrikave.
  3. Më pak se 2 sekonda. Modulet pod krijohen dhe kalojnë në gjendje pritjeje.
  4. Më pak se 2 sekonda. CA sheh modulet në pritje dhe dërgon thirrjet për përgatitjen e nyjave.
  5. 10 minuta. Ofruesi i cloud-it ndan nyja. K8s pret që 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-it me CA tonĂ«. E fundit punon brenda klasterit Kubernetes, ndĂ«rsa mekanizmi i ofruesit tĂ« cloud-it punon nĂ« bazĂ« tĂ« shpĂ«rndarjes sĂ« nyjave. Ai nuk di se çfarĂ« ndodh me pod’ët ose aplikacionin tuaj. KĂ«to sisteme punojnĂ« paralelisht.

Si të menaxhoni shkallëzimin në Kubernetes

  1. Kubernetes Ă«shtĂ« njĂ« mjet pĂ«r menaxhimin e resurseve dhe orkestrimin. Operacionet e menaxhimit tĂ« pod’eve dhe resurseve tĂ« klasterit janĂ« njĂ« pikĂ« kyçe nĂ« zotĂ«rimin e Kubernetes.
  2. Merrni logjikĂ«n e shkallĂ«zueshmĂ«risĂ« sĂ« pod’eve nĂ« konsideratĂ« duke u bazuar nĂ« HPA dhe VPA.
  3. CA duhet tĂ« pĂ«rdoret vetĂ«m nĂ«se e kuptoni mirĂ« nevojat e pod’eve dhe kontejnerĂ«ve tuaj.
  4. Për një konfigurim optimal të klasterit, duhet të kuptoni si funksionojnë së bashku sistemet e ndryshme të shkallëzimit.
  5. Kur vlerësoni kohën e shkallëzimit, kini parasysh skenarët më të keq dhe më të mirë.

Burimi: habr.com

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