Tri ravni samodejnega skaliranja v Kubernetesu: kako jih učinkovito uporabljati

Tri ravni samodejnega skaliranja v Kubernetesu: kako jih učinkovito uporabljati
Če želite v celoti obvladati Kubernetes, morate poznati različne načine za povečanje virov gruče: po po mnenju razvijalcev sistema, je to ena glavnih nalog Kubernetesa. Zagotovili smo pregled na visoki ravni horizontalnega in vertikalnega samodejnega skaliranja in mehanizmov za spreminjanje velikosti gruče ter priporočila, kako jih učinkovito uporabljati.

Članek Kubernetes AutoScaling 101: Samodejno skaliranje gruče, Horizontalno samodejno skaliranje in Vertikalno samodejno skaliranje podov prevedla ekipa, ki je implementirala samodejno skaliranje v Kubernetes aaS iz Mail.ru.

Zakaj je pomembno razmišljati o skaliranju

Kubernetes - orodje za upravljanje virov in orkestracijo. Seveda se je lepo poigrati s kul funkcijami uvajanja, spremljanja in upravljanja podov (pod je skupina vsebnikov, ki se zaženejo kot odgovor na zahtevo).

Vendar pa morate razmisliti tudi o naslednjih vprašanjih:

  1. Kako povečati module in aplikacije?
  2. Kako ohraniti zabojnike operativne in učinkovite?
  3. Kako se odzvati na stalne spremembe kode in delovne obremenitve uporabnikov?

Konfiguriranje gruč Kubernetes za uravnoteženje virov in zmogljivosti je lahko zahtevno in zahteva strokovno znanje o notranjem delovanju Kubernetesa. Delovna obremenitev vaše aplikacije ali storitev lahko niha čez dan ali celo v eni uri, zato je uravnoteženje najbolje obravnavati kot stalen proces.

Ravni samodejnega skaliranja Kubernetes

Učinkovito samodejno skaliranje zahteva usklajevanje med dvema nivojema:

  1. Raven bloka, vključno z vodoravnim (Horizontal Pod Autoscaler, HPA) in navpičnim samodejnim skaliranjem (Vertical Pod Autoscaler, VPA). To je povečanje razpoložljivih virov za vaše vsebnike.
  2. Raven gruče, ki jo upravlja Cluster Autoscaler (CA), ki poveča ali zmanjša število vozlišč znotraj gruče.

Modul Horizontal Autoscaler (HPA).

Kot že ime pove, HPA meri število replik podov. Večina devops uporablja obremenitev procesorja in pomnilnika kot sprožilce za spreminjanje števila replik. Vendar pa je mogoče sistem prilagoditi na podlagi meritve po meri, njim Kombinacija ali celo zunanje metrike.

Diagram delovanja HPA na visoki ravni:

  1. HPA nenehno preverja metrične vrednosti, določene med namestitvijo, v privzetem intervalu 30 sekund.
  2. HPA poskuša povečati število modulov, če je dosežen podani prag.
  3. HPA posodablja število replik znotraj krmilnika razmestitve/podvajanja.
  4. Krmilnik za razmestitev/podvajanje nato razmesti vse potrebne dodatne module.

Tri ravni samodejnega skaliranja v Kubernetesu: kako jih učinkovito uporabljati
HPA začne postopek uvajanja modula, ko je dosežen prag metrike

Pri uporabi HPA upoštevajte naslednje:

  • Privzeti interval preverjanja HPA je 30 sekund. Določeno je z zastavo horizontal-pod-autoscaler-sync-period v upravitelju krmilnika.
  • Privzeta relativna napaka je 10 %.
  • Po zadnjem povečanju števila modulov HPA pričakuje, da se bodo metrike stabilizirale v treh minutah. Ta interval je nastavljen z zastavo horizontal-pod-autoscaler-upscale-delay.
  • Po zadnjem zmanjšanju števila modulov HPA počaka pet minut, da se stabilizira. Ta interval je nastavljen z zastavo horizontal-pod-autoscaler-downscale-delay.
  • HPA najbolje deluje z razmestitvenimi objekti namesto s krmilniki podvajanja. Horizontalno samodejno skaliranje ni združljivo s tekočim posodabljanjem, ki neposredno manipulira s krmilniki podvajanja. Pri razmestitvi je število replik neposredno odvisno od objektov razmestitve.

Navpično samodejno skaliranje podov

Navpično samodejno skaliranje (VPA) dodeli več (ali manj) procesorskega časa ali pomnilnika obstoječim sklopom. Primerno za pode s stanjem ali brez stanja, vendar je namenjeno predvsem storitvam s stanjem. Vendar pa lahko VPA uporabite tudi za module brez stanja, če morate samodejno prilagoditi količino prvotno dodeljenih virov.

VPA se odzove tudi na dogodke OOM (out of memory). Spreminjanje časa procesorja in pomnilnika zahteva ponovni zagon podov. Pri ponovnem zagonu VPA upošteva proračun za dodelitev (proračun razdelitve strokov, PPP), da se zagotovi minimalno zahtevano število modulov.

Za vsak modul lahko nastavite minimalna in največja sredstva. Tako lahko največjo količino dodeljenega pomnilnika omejite na 8 GB. To je uporabno, če trenutna vozlišča zagotovo ne morejo dodeliti več kot 8 GB pomnilnika na vsebnik. Podrobne specifikacije in mehanizem delovanja so opisani v uradni wiki VPA.

Poleg tega ima VPA zanimivo funkcijo priporočil (VPA Recommender). Spremlja uporabo virov in dogodke OOM vseh modulov, da predlaga nove vrednosti pomnilnika in časa CPU na podlagi inteligentnega algoritma, ki temelji na zgodovinskih meritvah. Obstaja tudi API, ki prevzame ročaj pod in vrne predlagane vrednosti virov.

Omeniti velja, da VPA Recommender ne sledi "omejitve" virov. Zaradi tega lahko modul monopolizira vire znotraj vozlišč. Bolje je, da omejitev nastavite na ravni imenskega prostora, da se izognete veliki porabi pomnilnika ali procesorja.

Shema delovanja VPA na visoki ravni:

  1. VPA nenehno preverja metrične vrednosti, določene med namestitvijo, v privzetem intervalu 10 sekund.
  2. Če je določeni prag dosežen, VPA poskuša spremeniti dodeljeno količino virov.
  3. VPA posodablja število virov znotraj krmilnika za uvajanje/podvajanje.
  4. Ko se moduli znova zaženejo, se vsi novi viri uporabijo za ustvarjene primerke.

Tri ravni samodejnega skaliranja v Kubernetesu: kako jih učinkovito uporabljati
VPA doda zahtevano količino virov

Pri uporabi VPA upoštevajte naslednje točke:

  • Skaliranje zahteva obvezen ponovni zagon sklopa. To je potrebno, da se izognete nestabilnemu delovanju po spremembah. Zaradi zanesljivosti se moduli znova zaženejo in porazdelijo po vozliščih na podlagi na novo dodeljenih virov.
  • VPA in HPA še nista združljiva drug z drugim in ne moreta delovati na istih podih. Če uporabljate oba mehanizma skaliranja v isti gruči, se prepričajte, da vaše nastavitve preprečujejo njuno aktiviranje na istih objektih.
  • VPA prilagaja zahteve vsebnika za vire samo na podlagi pretekle in trenutne uporabe. Ne določa omejitev uporabe virov. Lahko pride do težav z aplikacijami, ki ne delujejo pravilno in začnejo prevzemati vedno več virov, zaradi česar bo Kubernetes izklopil to enoto.
  • VPA je še vedno v zgodnji fazi razvoja. Bodite pripravljeni, da bo sistem v bližnji prihodnosti morda deležen nekaterih sprememb. Lahko preberete o znane omejitve и razvojne načrte. Tako se načrtuje izvajanje skupnega delovanja VPA in HPA ter uvedba modulov skupaj s politiko vertikalnega samodejnega skaliranja zanje (na primer posebna oznaka "zahteva VPA").

Samodejno skaliranje gruče Kubernetes

Cluster Autoscaler (CA) spremeni število vozlišč glede na število čakajočih blokov. Sistem redno preverja module v teku - in poveča velikost gruče, če je potrebnih več virov in če gruče ne presegajo določenih omejitev. CA komunicira s ponudnikom storitev v oblaku, od njega zahteva dodatna vozlišča ali sprosti nedejavna. Prva splošno dostopna različica CA je bila predstavljena v Kubernetesu 1.8.

Shema delovanja SA na visoki ravni:

  1. CA preverja module v privzetem intervalu 10 sekund.
  2. Če je eden ali več podov v stanju pripravljenosti, ker gruča nima dovolj razpoložljivih virov za njihovo dodelitev, poskuša omogočiti eno ali več dodatnih vozlišč.
  3. Ko ponudnik storitev v oblaku dodeli zahtevano vozlišče, se le-to pridruži gruči in je pripravljeno streči podom.
  4. Razporejevalnik Kubernetes razdeli čakajoče sklope v novo vozlišče. Če po tem nekaj modulov še vedno ostane v stanju čakanja, se postopek ponovi in ​​v gručo dodajo nova vozlišča.

Tri ravni samodejnega skaliranja v Kubernetesu: kako jih učinkovito uporabljati
Samodejno zagotavljanje vozlišč gruče v oblaku

Pri uporabi CA upoštevajte naslednje:

  • CA zagotavlja, da imajo vsi podi v gruči prostor za delovanje, ne glede na obremenitev procesorja. Prav tako poskuša zagotoviti, da v gruči ni nepotrebnih vozlišč.
  • CA zazna potrebo po skaliranju po približno 30 sekundah.
  • Ko vozlišče ni več potrebno, CA privzeto počaka 10 minut, preden razširi sistem.
  • Sistem samodejnega skaliranja ima koncept ekspanderjev. To so različne strategije za izbiro skupine vozlišč, ki jim bodo dodana nova vozlišča.
  • Možnost uporabljajte odgovorno cluster-autoscaler.kubernetes.io/safe-to-evict (true). Če namestite veliko podov ali če jih je veliko razpršenih po vseh vozliščih, boste v veliki meri izgubili možnost povečanja gruče.
  • Uporabi PodDisruptionBudgetsda preprečite brisanje podov, kar bi lahko povzročilo popolno okvaro delov vaše aplikacije.

Kako Kubernetes autoscalers medsebojno delujejo

Za popolno harmonijo je treba samodejno skaliranje uporabiti tako na ravni sklopa (HPA/VPA) kot na ravni gruče. Medsebojno delujejo relativno preprosto:

  1. HPA ali VPA posodobijo replike podov ali vire, dodeljene obstoječim podom.
  2. Če ni dovolj vozlišč za načrtovano skaliranje, CA opazi prisotnost podov v stanju čakanja.
  3. CA dodeli nova vozlišča.
  4. Moduli se porazdelijo na nova vozlišča.

Tri ravni samodejnega skaliranja v Kubernetesu: kako jih učinkovito uporabljati
Sodelovalni razširljivi sistem Kubernetes

Pogoste napake pri samodejnem skaliranju Kubernetes

Obstaja več pogostih težav, na katere devops naleti, ko poskuša implementirati samodejno skaliranje.

HPA in VPA sta odvisna od meritev in nekaterih zgodovinskih podatkov. Če ni dodeljenih dovolj virov, bodo moduli minimizirani in ne bodo mogli ustvarjati meritev. V tem primeru se samodejno skaliranje ne bo nikoli zgodilo.

Sama operacija skaliranja je časovno občutljiva. Želimo, da se moduli in gruča hitro povečajo – preden uporabniki opazijo kakršne koli težave ali napake. Zato je treba upoštevati povprečni čas za skaliranje strokov in grozda.

Idealen scenarij - 4 minute:

  1. 30 sekund. Posodobite ciljne meritve: 30–60 sekund.
  2. 30 sekund. HPA preveri metrične vrednosti: 30 sekund.
  3. Manj kot 2 sekundi. Stroki so ustvarjeni in gredo v stanje čakanja: 1 sekunda.
  4. Manj kot 2 sekundi. CA vidi čakajoče module in pošlje klice vozliščem za zagotavljanje: 1 sekunda.
  5. 3 minute. Ponudnik oblaka dodeli vozlišča. K8s čaka, dokler niso pripravljeni: do 10 minut (odvisno od več dejavnikov).

Najslabši možni (bolj realistični) scenarij - 12 minut:

  1. 30 sekund. Posodobite ciljne meritve.
  2. 30 sekund. HPA preveri metrične vrednosti.
  3. Manj kot 2 sekundi. Stroki so ustvarjeni in preidejo v stanje pripravljenosti.
  4. Manj kot 2 sekundi. Služba za potrdila vidi čakajoče module in izvaja klice za zagotavljanje vozlišč.
  5. 10 minut. Ponudnik oblaka dodeli vozlišča. K8s čaka, dokler niso pripravljeni. Čakalni čas je odvisen od več dejavnikov, kot so zamuda prodajalca, zamuda OS in podporna orodja.

Ne zamenjujte mehanizmov skaliranja ponudnikov oblaka z našim CA. Slednji deluje znotraj gruče Kubernetes, medtem ko motor ponudnika oblaka deluje na podlagi distribucije vozlišč. Ne ve, kaj se dogaja z vašimi podi ali aplikacijo. Ti sistemi delujejo vzporedno.

Kako upravljati skaliranje v Kubernetesu

  1. Kubernetes je orodje za upravljanje virov in orkestracijo. Operacije za upravljanje podov in virov gruče so ključni mejnik pri obvladovanju Kubernetesa.
  2. Razumeti logiko razširljivosti podov ob upoštevanju HPA in VPA.
  3. CA uporabljajte le, če dobro poznate potrebe vaših podov in posod.
  4. Če želite optimalno konfigurirati gručo, morate razumeti, kako različni sistemi skaliranja delujejo skupaj.
  5. Pri ocenjevanju časa skaliranja upoštevajte najslabši in najboljši možni scenarij.

Vir: www.habr.com

Dodaj komentar