Tři úrovně automatického škálování v Kubernetes: Jak je efektivně používat

Tři úrovně automatického škálování v Kubernetes: Jak je efektivně používat
K úplnému zvládnutí Kubernetes potřebujete znát různé způsoby škálování prostředků clusteru: podle podle vývojářů systému, to je jeden z hlavních úkolů Kubernetes. Poskytli jsme přehled na vysoké úrovni o horizontálním a vertikálním automatickém škálování a mechanismech změny velikosti clusteru a také doporučení, jak je efektivně používat.

článek Kubernetes Autoscaling 101: Cluster Autoscaler, Horizontal Autoscaler a Vertical Pod Autoscaler přeložil tým, který implementoval automatické škálování v Kubernetes aaS z Mail.ru.

Proč je důležité myslet na škálování

Kubernetes - nástroj pro správu a orchestraci zdrojů. Samozřejmě je příjemné pohrát si se skvělými funkcemi nasazení, monitorování a správy modulů (pod je skupina kontejnerů, které jsou spuštěny v reakci na požadavek).

Měli byste se však také zamyslet nad následujícími otázkami:

  1. Jak škálovat moduly a aplikace?
  2. Jak udržet kontejnery provozuschopné a efektivní?
  3. Jak reagovat na neustálé změny kódu a zátěže ze strany uživatelů?

Konfigurace clusterů Kubernetes pro vyvážení zdrojů a výkonu může být náročná a vyžaduje odborné znalosti vnitřního fungování Kubernetes. Pracovní zátěž vaší aplikace nebo služeb může kolísat v průběhu dne nebo dokonce v průběhu hodiny, takže vyvažování je nejlépe chápat jako probíhající proces.

Úrovně automatického škálování Kubernetes

Efektivní automatické škálování vyžaduje koordinaci mezi dvěma úrovněmi:

  1. Úroveň stojanu, včetně horizontálního (Horizontal Pod Autoscaler, HPA) a vertikálního automatického scaleru (Vertical Pod Autoscaler, VPA). Toto je škálování dostupných zdrojů pro vaše kontejnery.
  2. Úroveň clusteru, kterou spravuje Cluster Autoscaler (CA), která zvyšuje nebo snižuje počet uzlů v rámci clusteru.

Modul Horizontal Autoscaler (HPA).

Jak název napovídá, HPA škáluje počet replik podů. Většina devopů používá CPU a zatížení paměti jako spouštěče pro změnu počtu replik. Je však možné škálovat systém na základě vlastní metriky, jejich kombinace nebo externí metriky.

Provozní diagram HPA na vysoké úrovni:

  1. HPA nepřetržitě kontroluje metrické hodnoty zadané během instalace ve výchozím intervalu 30 sekund.
  2. Pokud je dosaženo zadané prahové hodnoty, HPA se pokusí zvýšit počet modulů.
  3. HPA aktualizuje počet replik v rámci řadiče nasazení/replikace.
  4. Řadič nasazení/replikace pak nasadí všechny potřebné další moduly.

Tři úrovně automatického škálování v Kubernetes: Jak je efektivně používat
HPA spustí proces nasazení modulu, když je dosaženo prahové hodnoty metriky

Při používání HPA zvažte následující:

  • Výchozí interval kontroly HPA je 30 sekund. Je stanovena vlajkou horizontální-pod-autoscaler-synchronizační-období ve správci kontroléru.
  • Výchozí relativní chyba je 10 %.
  • Po posledním zvýšení počtu modulů HPA očekává, že se metriky ustálí do tří minut. Tento interval je nastaven příznakem horizontal-pod-autoscaler-upscale-delay.
  • Po posledním snížení počtu modulů čeká HPA pět minut na stabilizaci. Tento interval je nastaven příznakem horizontal-pod-autoscaler-downscale-delay.
  • HPA funguje nejlépe s objekty nasazení spíše než s řadiči replikace. Horizontální automatické škálování není kompatibilní s postupnou aktualizací, která přímo manipuluje s řadiči replikace. Při nasazení závisí počet replik přímo na objektech nasazení.

Vertikální automatické škálování lusků

Vertikální automatické škálování (VPA) přiděluje stávajícím modulům více (nebo méně) času CPU nebo paměti. Vhodné pro stavové nebo bezstavové moduly, ale hlavně určené pro stavové služby. VPA však můžete použít i pro bezstavové moduly, pokud potřebujete automaticky upravit množství původně přidělených zdrojů.

VPA také reaguje na události OOM (nedostatek paměti). Změna času CPU a paměti vyžaduje restartování modulů. Při opětovném spuštění dobrovolná dohoda o partnerství respektuje přidělený rozpočet (rozpočet na distribuci lusků, PNR), aby byl zaručen minimální požadovaný počet modulů.

Pro každý modul můžete nastavit minimální a maximální zdroje. Můžete tedy omezit maximální množství přidělené paměti na 8 GB. To je užitečné, pokud aktuální uzly rozhodně nemohou alokovat více než 8 GB paměti na kontejner. Podrobné specifikace a ovládací mechanismus jsou popsány v oficiální wiki VPA.

VPA má navíc zajímavou funkci doporučení (VPA Recommender). Monitoruje využití zdrojů a události OOM všech modulů a navrhuje nové hodnoty paměti a času CPU na základě inteligentního algoritmu založeného na historických metrikách. K dispozici je také rozhraní API, které přebírá popisovač modulu a vrací navrhované hodnoty prostředků.

Stojí za zmínku, že VPA Recommender nesleduje „limit zdroje“. To může vést k tomu, že modul monopolizuje zdroje v rámci uzlů. Je lepší nastavit limit na úrovni jmenného prostoru, abyste se vyhnuli velké spotřebě paměti nebo CPU.

Schéma provozu VPA na vysoké úrovni:

  1. VPA nepřetržitě kontroluje metrické hodnoty zadané během instalace ve výchozím intervalu 10 sekund.
  2. Pokud je dosaženo zadané prahové hodnoty, VPA se pokusí změnit přidělené množství zdrojů.
  3. VPA aktualizuje počet prostředků v řadiči nasazení/replikace.
  4. Když jsou moduly restartovány, všechny nové prostředky se aplikují na vytvořené instance.

Tři úrovně automatického škálování v Kubernetes: Jak je efektivně používat
VPA přidá požadované množství zdrojů

Při používání VPA mějte na paměti následující body:

  • Změna měřítka vyžaduje povinný restart modulu. To je nezbytné, aby se zabránilo nestabilnímu provozu po provedení změn. Kvůli spolehlivosti jsou moduly restartovány a distribuovány mezi uzly na základě nově přidělených zdrojů.
  • VPA a HPA ještě nejsou vzájemně kompatibilní a nemohou běžet na stejných modulech. Pokud používáte oba mechanismy škálování ve stejném clusteru, ujistěte se, že vaše nastavení brání jejich aktivaci na stejných objektech.
  • VPA ladí požadavky kontejnerů na zdroje pouze na základě minulého a současného využití. Nestanovuje limity využití zdrojů. Mohou nastat problémy s tím, že aplikace nefungují správně a začnou přebírat stále více zdrojů, což povede k tomu, že Kubernetes tento modul vypne.
  • VPA je stále v rané fázi vývoje. Buďte připraveni, že systém může v blízké budoucnosti projít určitými změnami. Můžete si přečíst o známá omezení и plány rozvoje. Existují tedy plány na implementaci společného provozu VPA a HPA, jakož i na nasazení modulů spolu s politikou vertikálního automatického škálování (například zvláštní označení „vyžaduje VPA“).

Automatické škálování clusteru Kubernetes

Cluster Autoscaler (CA) mění počet uzlů na základě počtu čekajících modulů. Systém pravidelně kontroluje nevyřízené moduly – a zvětšuje velikost clusteru, pokud je potřeba více zdrojů a pokud cluster nepřekračuje stanovené limity. CA komunikuje s poskytovatelem cloudových služeb, požaduje od něj další uzly nebo uvolňuje nečinné uzly. První obecně dostupná verze CA byla představena v Kubernetes 1.8.

Schéma provozu SA na vysoké úrovni:

  1. CA kontroluje nevyřízené moduly ve výchozím intervalu 10 sekund.
  2. Pokud je jeden nebo více modulů v pohotovostním stavu, protože cluster nemá dostatek dostupných prostředků k jejich přidělení, pokusí se zřídit jeden nebo více dalších uzlů.
  3. Když poskytovatel cloudových služeb přidělí požadovaný uzel, připojí se ke clusteru a je připraven obsluhovat moduly.
  4. Plánovač Kubernetes distribuuje čekající pody do nového uzlu. Pokud po tomto některé moduly stále zůstávají ve stavu čekání, proces se opakuje a do clusteru jsou přidány nové uzly.

Tři úrovně automatického škálování v Kubernetes: Jak je efektivně používat
Automatické zřizování uzlů clusteru v cloudu

Při používání CA zvažte následující:

  • CA zajišťuje, že všechny moduly v clusteru mají prostor pro spuštění bez ohledu na zatížení procesoru. Snaží se také zajistit, aby v clusteru nebyly žádné zbytečné uzly.
  • CA zaregistruje potřebu škálování přibližně po 30 sekundách.
  • Jakmile uzel již není potřeba, CA standardně počká 10 minut, než systém rozšíří.
  • Systém automatického škálování má koncept expandérů. Jedná se o různé strategie pro výběr skupiny uzlů, do kterých budou přidány nové uzly.
  • Používejte tuto možnost zodpovědně cluster-autoscaler.kubernetes.io/safe-to-evict (pravda). Pokud nainstalujete mnoho modulů nebo pokud je mnoho z nich rozptýleno ve všech uzlech, ztratíte do značné míry schopnost škálovat cluster.
  • použití PodDisruptionBudgetsabyste zabránili smazání podů, což by mohlo způsobit úplné selhání částí vaší aplikace.

Jak se autoscalery Kubernetes vzájemně ovlivňují

Pro dokonalou harmonii by mělo být automatické škálování aplikováno jak na úrovni modulu (HPA/VPA), tak na úrovni clusteru. Navzájem se vzájemně ovlivňují poměrně jednoduše:

  1. HPA nebo VPA aktualizují repliky podů nebo prostředky přidělené existujícím podům.
  2. Pokud není dostatek uzlů pro plánované škálování, CA zaznamená přítomnost podů ve stavu čekání.
  3. CA přiděluje nové uzly.
  4. Moduly jsou distribuovány do nových uzlů.

Tři úrovně automatického škálování v Kubernetes: Jak je efektivně používat
Kolaborativní škálovací systém Kubernetes

Časté chyby v automatickém škálování Kubernetes

Existuje několik běžných problémů, na které devops narazí při pokusu o implementaci automatického škálování.

HPA a VPA závisí na metrikách a některých historických datech. Pokud nebudou přiděleny dostatečné zdroje, moduly budou minimalizovány a nebudou schopny generovat metriky. V tomto případě k automatickému škálování nikdy nedojde.

Samotná operace škálování je časově citlivá. Chceme, aby se moduly a cluster rychle škálovaly – dříve, než si uživatelé všimnou jakýchkoli problémů nebo selhání. Proto je třeba vzít v úvahu průměrnou dobu škálování pro lusky a shluk.

Ideální scénář – 4 minuty:

  1. 30 sekund. Aktualizovat cílové metriky: 30–60 sekund.
  2. 30 sekund. HPA kontroluje metrické hodnoty: 30 sekund.
  3. Méně než 2 sekundy. Pody se vytvoří a přejdou do stavu čekání: 1 sekunda.
  4. Méně než 2 sekundy. CA vidí čekající moduly a odesílá volání do zajišťovacích uzlů: 1 sekunda.
  5. 3 minuty. Poskytovatel cloudu přiděluje uzly. K8s čeká, dokud nejsou připraveny: až 10 minut (v závislosti na několika faktorech).

Nejhorší (realističtější) scénář – 12 minut:

  1. 30 sekund. Aktualizujte cílové metriky.
  2. 30 sekund. HPA kontroluje metrické hodnoty.
  3. Méně než 2 sekundy. Pody se vytvoří a přejdou do pohotovostního stavu.
  4. Méně než 2 sekundy. CA vidí čekající moduly a zavolá do uzlů.
  5. 10 minut. Poskytovatel cloudu přiděluje uzly. K8 čeká, dokud nebudou připraveni. Čekací doba závisí na několika faktorech, jako je zpoždění dodavatele, zpoždění OS a nástroje podpory.

Nepleťte si škálovací mechanismy poskytovatelů cloudu s naší CA. Ten běží uvnitř clusteru Kubernetes, zatímco engine poskytovatele cloudu funguje na bázi distribuce uzlů. Neví, co se děje s vašimi pody nebo aplikací. Tyto systémy fungují paralelně.

Jak spravovat škálování v Kubernetes

  1. Kubernetes je nástroj pro správu a orchestraci zdrojů. Operace pro správu modulů a prostředků clusteru jsou klíčovým milníkem ve zvládnutí Kubernetes.
  2. Pochopte logiku škálovatelnosti podů s ohledem na HPA a VPA.
  3. CA byste měli používat pouze v případě, že dobře rozumíte potřebám svých podů a nádob.
  4. Chcete-li optimálně nakonfigurovat cluster, musíte pochopit, jak různé systémy škálování spolupracují.
  5. Při odhadování doby škálování mějte na paměti nejhorší a nejlepší scénáře.

Zdroj: www.habr.com

Přidat komentář