Om Kubernetes folslein te behearskjen, moatte jo ferskate manieren witte om klusterboarnen te skaaljen: troch , dit is ien fan 'e wichtichste taken fan Kubernetes. Wy hawwe in oersjoch op heech nivo levere fan horizontale en fertikale autoskalearring en meganismen foar feroarjen fan klustergrutte, lykas oanbefellings oer hoe't se effektyf kinne brûke.
Lidwurd oerset troch it team dat autoscaling ymplementearre yn .
Wêrom is it wichtich om te tinken oer skaalfergrutting
- in ark foar boarnebehear en orkestraasje. Fansels is it moai om te tinken mei de koele funksjes fan it ynsetten, kontrolearjen en behearen fan pods (in pod is in groep konteners dy't lansearre wurde yn reaksje op in fersyk).
Jo moatte lykwols ek tinke oer de folgjende fragen:
- Hoe modules en applikaasjes skaalje?
- Hoe kinne konteners operasjoneel en effisjint hâlde?
- Hoe reagearje op konstante feroaringen yn koade en wurkdruk fan brûkers?
It konfigurearjen fan Kubernetes-klusters om boarnen en prestaasjes te balansearjen kin útdaagjend wêze en fereasket saakkundige kennis fan 'e ynderlike wurking fan Kubernetes. De wurkdruk fan jo applikaasje of tsjinsten kin de hiele dei of sels yn 'e rin fan in oere fluktuearje, dus it balansearjen wurdt it bêste beskôge as in trochgeand proses.
Kubernetes autoscaling nivo's
Effektive autoskalearring fereasket koördinaasje tusken twa nivo's:
- Podnivo, ynklusyf horizontaal (Horizontal Pod Autoscaler, HPA) en fertikale autoscaler (Vertical Pod Autoscaler, VPA). Dit is skaalfergrutting fan de beskikbere boarnen foar jo konteners.
- Clusternivo, dat wurdt beheard troch de Cluster Autoscaler (CA), dy't it oantal knopen binnen it kluster fergruttet of fermindert.
Horizontale Autoscaler (HPA) module
Lykas de namme al fermoeden docht, skaalet HPA it oantal pod-replika's. De measte devops brûke CPU en ûnthâldlading as triggers foar it feroarjen fan it oantal replika's. It is lykwols mooglik om it systeem te skaaljen basearre op harren of sels .
HPA-bestjoeringsdiagram op hege nivo:
- De HPA kontroleart kontinu de metryske wearden oantsjutte tidens de ynstallaasje mei in standertynterval fan 30 sekonden.
- De HPA besiket it oantal modules te fergrutsjen as de opjûne drompel wurdt berikt.
- De HPA fernijt it oantal replika's binnen de ynset-/replikaasjecontroller.
- De ynset-/replikaasjekontrôler set dan alle nedige ekstra modules yn.
HPA begjint it module-ynsetproses as in metrike drompel wurdt berikt
By it brûken fan HPA, beskôgje it folgjende:
- De standert HPA-kontrôle-ynterval is 30 sekonden. It wurdt ynsteld troch de flagge horizontale-pod-autoscaler-sync-perioade yn de controller manager.
- De standert relative flater is 10%.
- Nei de lêste ferheging fan it oantal modules ferwachtet HPA dat de metriken binnen trije minuten stabilisearje. Dit ynterval wurdt ynsteld troch de flagge horizontale-pod-autoscaler-upscale-fertraging.
- Nei de lêste fermindering fan it oantal modules wachtet de HPA fiif minuten om te stabilisearjen. Dit ynterval wurdt ynsteld troch de flagge horizontale-pod-autoscaler-downscale-fertraging.
- HPA wurket it bêste mei ynsetobjekten ynstee fan replikaasjekontrôles. Horizontale autoskalearring is ynkompatibel mei rôljende update, dy't direkt replikaasjekontrôles manipulearret. Mei ynset hinget it oantal replika's direkt ôf fan 'e ynsetobjekten.
Fertikale autoskalearring fan pods
Fertikale autoskalearring (VPA) allocearret mear (of minder) CPU-tiid as ûnthâld oan besteande pods. Geskikt foar steatlike of steatleaze pods, mar benammen bedoeld foar steatlike tsjinsten. Jo kinne lykwols ek VPA brûke foar steatleaze modules as jo it bedrach fan ynearsten tawiisde boarnen automatysk moatte oanpasse.
VPA reagearret ek op OOM (út ûnthâld) eveneminten. It feroarjen fan CPU-tiid en ûnthâld fereasket it opnij starte fan de pods. By opnij opstart respektearret de VPA it tawizingsbudzjet () om it minimaal fereaske oantal modules te garandearjen.
Jo kinne de minimale en maksimale boarnen foar elke module ynstelle. Sa kinne jo it maksimum bedrach fan tawiisd ûnthâld beheine ta 8 GB. Dit is handich as de hjoeddeistige knopen perfoarst net mear dan 8 GB ûnthâld per kontener kinne tawize. Detaillearre spesifikaasjes en bestjoeringssysteem meganisme wurde beskreaun yn .
Derneist hat VPA in ynteressante oanbefellingsfunksje (VPA-oanbefelling). It kontrolearret boarnegebrûk en OOM-eveneminten fan alle modules om nije ûnthâld- en CPU-tiidwearden foar te stellen basearre op in yntelligint algoritme basearre op histoaryske metriken. D'r is ek in API dy't in podhandgreep nimt en foarstelde boarnewearden werombringt.
It is de muoite wurdich op te merken dat VPA Recommender gjin boarne "limyt" folget. Dit kin resultearje yn de module monopolisearje boarnen binnen knopen. It is better om de limyt op it nammeromtenivo yn te stellen om enoarm ûnthâld of CPU-konsumpsje te foarkommen.
VPA-operaasjeskema op hege nivo:
- VPA kontrolearret kontinu de metryske wearden oantsjutte tidens ynstallaasje mei in standert ynterval fan 10 sekonden.
- As de oantsjutte drompel wurdt berikt, besiket de VPA it tawiisde bedrach fan middels te feroarjen.
- De VPA fernijt it oantal boarnen binnen de ynset-/replikaasjecontroller.
- As modules opnij starte, wurde alle nije boarnen tapast op de makke eksimplaren.
VPA foeget de fereaske hoemannichte boarnen ta
Hâld asjebleaft de folgjende punten yn gedachten by it brûken fan VPA:
- Skaalfergrutting fereasket in ferplichte werstart fan 'e pod. Dit is nedich om instabiele operaasje te foarkommen nei it meitsjen fan wizigingen. Foar betrouberens wurde modules opnij starte en ferdield oer knopen basearre op nij tawiisde boarnen.
- VPA en HPA binne noch net kompatibel mei elkoar en kinne net op deselde pods rinne. As jo beide skaalmeganismen yn itselde kluster brûke, soargje derfoar dat jo ynstellingen foarkomme dat se op deselde objekten wurde aktivearre.
- VPA stimt konteneroanfragen foar boarnen allinich op basis fan ferline en hjoeddeistige gebrûk. It stelt gjin limiten foar gebrûk fan boarnen yn. D'r kinne problemen wêze mei applikaasjes dy't net goed wurkje en mear en mear boarnen begjinne oer te nimmen, dit sil liede ta Kubernetes dy't dizze pod útsette.
- VPA is noch yn in ier stadium fan ûntwikkeling. Wês taret dat it systeem yn 'e heine takomst wat feroaringen kin ûndergean. Jo kinne lêze oer и . Sa binne d'r plannen om de mienskiplike operaasje fan VPA en HPA út te fieren, lykas de ynset fan modules tegearre mei in fertikaal autoskalearringsbelied foar har (bygelyks in spesjaal label 'fereasket VPA').
Autoscaling in Kubernetes kluster
Cluster Autoscaler (CA) feroaret it oantal knopen basearre op it oantal wachtsjende pods. It systeem kontrolearret periodyk op ôfwachting fan modules - en fergruttet de klustergrutte as mear middels nedich binne en as it kluster de fêststelde grinzen net boppe giet. De CA kommunisearret mei de cloud-tsjinstferliener, freget ekstra knooppunten fan him, of makket idle frij. De earste algemien beskikbere ferzje fan CA waard yntrodusearre yn Kubernetes 1.8.
Heech nivo skema fan SA operaasje:
- CA kontrolearret foar wachtsjende modules mei in standert ynterval fan 10 sekonden.
- As ien of mear pods yn in standby-tastân binne om't it kluster net genôch beskikbere boarnen hat om se te allocearjen, besiket it ien of mear ekstra knopen te foarsjen.
- As de provider fan 'e wolktsjinst it fereaske knooppunt tawiist, giet it by it kluster en is ree om de pods te tsjinjen.
- De Kubernetes-planner ferspriedt wachtjende pods nei it nije knooppunt. As nei dit guon modules noch bliuwe yn in wachtsjen steat, it proses wurdt werhelle en nije knopen wurde tafoege oan it kluster.
Automatyske foarsjenning fan klusterknooppunten yn 'e wolk
Tink oan it folgjende as jo CA brûke:
- CA soarget derfoar dat alle pods yn it kluster hawwe romte om te rinnen, nettsjinsteande CPU load. It besiket ek te soargjen dat d'r gjin ûnnedige knopen binne yn it kluster.
- CA registrearret de needsaak om te skaaljen nei likernôch 30 sekonden.
- Sadree't in knooppunt net mear nedich is, is de CA standert om 10 minuten te wachtsjen foardat it systeem útskale.
- It autoskaalsysteem hat it konsept fan expanders. Dit binne ferskillende strategyen foar it selektearjen fan in groep knooppunten dêr't nije knooppunten wurde tafoege.
- Brûk de opsje ferantwurde cluster-autoscaler.kubernetes.io/safe-to-evict (wier). As jo in protte pods ynstalleare, of as in protte fan harren binne ferspraat oer alle knooppunten, sille jo foar in grut part de mooglikheid ferlieze om it kluster út te skaaljen.
- Gebrûk om foar te kommen dat pods wiske wurde, wat dertroch kin dat dielen fan jo applikaasje folslein mislearje.
Hoe Kubernetes autoscalers mei elkoar ynteraksje
Foar perfekte harmony moat autoskalearring tapast wurde op sawol it podnivo (HPA / VPA) as it klusternivo. Se ynteraksje mei elkoar relatyf ienfâldich:
- HPA's as VPA's aktualisearje pod-replika's as boarnen tawiisd oan besteande pods.
- As d'r net genôch knopen binne foar de plande skaalfergrutting, merkt de CA de oanwêzigens fan pods yn in wachtstân.
- De CA jout nije knopen ta.
- Modules wurde ferdield nei nije knopen.
Gearwurking Kubernetes scale-out systeem
Algemiene flaters yn Kubernetes autoscaling
D'r binne ferskate mienskiplike problemen dy't devops tsjinkomme by it besykjen fan autoskalearring.
HPA en VPA binne ôfhinklik fan metriken en guon histoaryske gegevens. As net genôch middels wurde tawiisd, wurde de modules minimalisearre en kinne se gjin metriken generearje. Yn dit gefal sil autoscaling nea barre.
De skaalfergrutting sels is tiidgefoel. Wy wolle dat de modules en kluster fluch skaalje - foardat brûkers problemen of mislearrings opmerke. Dêrom moat de gemiddelde tiid foar skaalfergrutting fan pods en it kluster rekken holden wurde.
Ideaal senario - 4 minuten:
- 30 sekonden. Update doelmetriken: 30-60 sekonden.
- 30 sekonden. HPA kontrolearret metryske wearden: 30 sekonden.
- Minder as 2 sekonden. Pods wurde oanmakke en gean yn wachtstatus: 1 sekonde.
- Minder as 2 sekonden. CA sjocht wachtmodules en stjoert oproppen nei foarsjenning nodes: 1 sekonde.
- 3 minuten. De wolkprovider allocates knopen. K8s wachtsje oant se klear binne: oant 10 minuten (ôfhinklik fan ferskate faktoaren).
Slimste gefal (realistysker) senario - 12 minuten:
- 30 sekonden. Update doelmetriken.
- 30 sekonden. HPA kontrolearret de metrike wearden.
- Minder as 2 sekonden. De pods wurde oanmakke en geane yn 'e standby-status.
- Minder as 2 sekonden. De CA sjocht de wachtmodules en docht oproppen om de knopen te foarsjen.
- 10 minúten. De wolkprovider allocates knopen. K8s wachtsje oant se klear binne. De wachttiid hinget ôf fan ferskate faktoaren, lykas ferkeapfertraging, OS-fertraging, en stipe-ark.
Ferwarre skaalmeganismen fan wolkproviders net mei ús CA. De lêste rint binnen in Kubernetes-kluster, wylst de wolkprovidermotor wurket op in node-distribúsjebasis. It wit net wat der bart mei jo pods of applikaasje. Dizze systemen wurkje parallel.
Hoe skaalfergrutting te behearjen yn Kubernetes
- Kubernetes is in ark foar boarnebehear en orkestraasje. Operaasje foar it behearen fan pods en klusterboarnen binne in wichtige mylpeal yn it behearskjen fan Kubernetes.
- Begryp de logika fan pod-skaalberens mei rekken hâldend mei HPA en VPA.
- CA moat allinich brûkt wurde as jo in goed begryp hawwe fan 'e behoeften fan jo pods en konteners.
- Om in kluster optimaal te konfigurearjen, moatte jo begripe hoe't ferskate skaalsysteem gearwurkje.
- By it skatten fan skaaltiid, hâld de minste en bêste gefal senario's yn gedachten.
Boarne: www.habr.com