Tri úrovne automatického škálovania v Kubernetes: Ako ich efektívne používať

Tri úrovne automatického škálovania v Kubernetes: Ako ich efektívne používať
Na úplné zvládnutie Kubernetes potrebujete poznať rôzne spôsoby škálovania prostriedkov klastra: podľa podľa vývojárov systému, to je jedna z hlavných úloh Kubernetes. Poskytli sme prehľad na vysokej úrovni o horizontálnom a vertikálnom automatickom škálovaní a mechanizmoch zmeny veľkosti klastrov, ako aj odporúčania, ako ich efektívne používať.

Článok Kubernetes Autoscaling 101: Cluster Autoscaler, Horizontálny Autoscaler a Vertical Pod Autoscaler preložil tím, ktorý implementoval automatické škálovanie v Kubernetes aaS z Mail.ru.

Prečo je dôležité myslieť na škálovanie

Kubernetes - nástroj na riadenie a organizáciu zdrojov. Samozrejme, je príjemné pohrať sa so skvelými funkciami nasadzovania, monitorovania a správy modulov (pod je skupina kontajnerov, ktoré sa spúšťajú ako odpoveď na požiadavku).

Mali by ste sa však zamyslieť aj nad nasledujúcimi otázkami:

  1. Ako škálovať moduly a aplikácie?
  2. Ako udržať kontajnery funkčné a efektívne?
  3. Ako reagovať na neustále zmeny v kóde a záťaži od používateľov?

Konfigurácia klastrov Kubernetes na vyváženie zdrojov a výkonu môže byť náročná a vyžaduje si odborné znalosti vnútorného fungovania Kubernetes. Pracovné zaťaženie vašej aplikácie alebo služieb môže kolísať počas dňa alebo dokonca v priebehu hodiny, takže vyváženie je najlepšie chápať ako prebiehajúci proces.

Úrovne automatického škálovania Kubernetes

Efektívne automatické škálovanie vyžaduje koordináciu medzi dvoma úrovňami:

  1. Úroveň podstavca vrátane horizontálneho (Horizontal Pod Autoscaler, HPA) a vertikálneho automatického scaleru (Vertical Pod Autoscaler, VPA). Toto je škálovanie dostupných zdrojov pre vaše kontajnery.
  2. Úroveň klastra, ktorú spravuje Cluster Autoscaler (CA), ktorá zvyšuje alebo znižuje počet uzlov v rámci klastra.

Horizontálny Autoscaler (HPA) modul

Ako už názov napovedá, HPA zvyšuje počet replík pod. Väčšina vývojárov používa CPU a zaťaženie pamäte ako spúšťače na zmenu počtu replík. Je však možné škálovať systém na základe vlastné metriky, oni kombinácia alebo externé metriky.

Prevádzkový diagram na vysokej úrovni HPA:

  1. HPA nepretržite kontroluje metrické hodnoty zadané počas inštalácie v predvolenom intervale 30 sekúnd.
  2. HPA sa pokúsi zvýšiť počet modulov, ak sa dosiahne určený prah.
  3. HPA aktualizuje počet replík v rámci radiča nasadenia/replikácie.
  4. Radič nasadenia/replikácie potom nasadí všetky potrebné dodatočné moduly.

Tri úrovne automatického škálovania v Kubernetes: Ako ich efektívne používať
HPA spustí proces nasadenia modulu, keď sa dosiahne metrický prah

Pri používaní HPA zvážte nasledovné:

  • Predvolený interval kontroly HPA je 30 sekúnd. Stanovuje sa vlajkou horizontal-pod-autoscaler-sync-period v správcovi kontroléra.
  • Predvolená relatívna chyba je 10 %.
  • Po poslednom zvýšení počtu modulov HPA očakáva stabilizáciu metrík do troch minút. Tento interval je nastavený príznakom horizontal-pod-autoscaler-upscale-delay.
  • Po poslednom znížení počtu modulov čaká HPA päť minút na stabilizáciu. Tento interval je nastavený príznakom horizontal-pod-autoscaler-downscale-delay.
  • HPA funguje najlepšie s objektmi nasadenia, a nie s radičmi replikácie. Horizontálne automatické škálovanie je nekompatibilné s postupnou aktualizáciou, ktorá priamo manipuluje s radičmi replikácie. Pri nasadení závisí počet replík priamo od objektov nasadenia.

Vertikálne automatické škálovanie strukov

Vertikálne automatické škálovanie (VPA) prideľuje viac (alebo menej) CPU alebo pamäte existujúcim modulom. Vhodné pre stavové alebo bezstavové moduly, ale hlavne určené pre stavové služby. VPA však môžete použiť aj pre bezstavové moduly, ak potrebujete automaticky upraviť množstvo pôvodne pridelených zdrojov.

VPA tiež reaguje na udalosti OOM (nedostatok pamäte). Zmena času procesora a pamäte vyžaduje reštartovanie modulov. Pri opätovnom spustení DDP rešpektuje prideľovací rozpočet (rozpočet na distribúciu strukov, PNR), aby sa zaručil minimálny požadovaný počet modulov.

Pre každý modul môžete nastaviť minimálne a maximálne zdroje. Môžete teda obmedziť maximálne množstvo pridelenej pamäte na 8 GB. To je užitočné, ak súčasné uzly určite nemôžu prideliť viac ako 8 GB pamäte na kontajner. Podrobné špecifikácie a ovládací mechanizmus sú popísané v oficiálna wiki VPA.

VPA má navyše zaujímavú funkciu odporúčania (VPA Recommender). Monitoruje využitie zdrojov a udalosti OOM všetkých modulov, aby navrhol nové hodnoty pamäte a času CPU na základe inteligentného algoritmu založeného na historických metrikách. K dispozícii je tiež rozhranie API, ktoré používa rukoväť modulu a vracia navrhované hodnoty zdrojov.

Stojí za zmienku, že VPA Recommender nesleduje „limit zdrojov“. To môže viesť k tomu, že modul monopolizuje zdroje v uzloch. Je lepšie nastaviť limit na úrovni menného priestoru, aby ste sa vyhli veľkej spotrebe pamäte alebo CPU.

Prevádzková schéma vysokej úrovne VPA:

  1. VPA nepretržite kontroluje metrické hodnoty zadané počas inštalácie v predvolenom intervale 10 sekúnd.
  2. Ak sa dosiahne určený prah, VPA sa pokúsi zmeniť pridelené množstvo zdrojov.
  3. VPA aktualizuje počet prostriedkov v radiči nasadenia/replikácie.
  4. Keď sa moduly reštartujú, všetky nové prostriedky sa aplikujú na vytvorené inštancie.

Tri úrovne automatického škálovania v Kubernetes: Ako ich efektívne používať
VPA pridáva požadované množstvo zdrojov

Pri používaní VPA majte na pamäti nasledujúce body:

  • Zmena mierky vyžaduje povinné reštartovanie modulu. Je to potrebné, aby sa predišlo nestabilnej prevádzke po vykonaní zmien. Kvôli spoľahlivosti sú moduly reštartované a distribuované medzi uzlami na základe novo pridelených zdrojov.
  • VPA a HPA ešte nie sú navzájom kompatibilné a nemôžu bežať na rovnakých moduloch. Ak používate oba mechanizmy škálovania v rovnakom klastri, uistite sa, že vaše nastavenia zabránia ich aktivácii na rovnakých objektoch.
  • VPA ladí požiadavky kontajnerov na zdroje len na základe minulého a súčasného používania. Nestanovuje limity využívania zdrojov. Môžu sa vyskytnúť problémy s aplikáciami, ktoré nefungujú správne a začnú preberať stále viac zdrojov, čo povedie k tomu, že Kubernetes vypne tento modul.
  • VPA je stále v ranom štádiu vývoja. Buďte pripravení, že systém môže v blízkej budúcnosti prejsť niekoľkými zmenami. Môžete si prečítať o známe obmedzenia и rozvojové plány. Existujú teda plány na implementáciu spoločnej prevádzky VPA a HPA, ako aj nasadenie modulov spolu s politikou vertikálneho automatického škálovania (napríklad špeciálne označenie „vyžaduje VPA“).

Automatické škálovanie klastra Kubernetes

Cluster Autoscaler (CA) mení počet uzlov na základe počtu čakajúcich modulov. Systém pravidelne kontroluje čakajúce moduly – a zväčšuje veľkosť klastra, ak je potrebných viac zdrojov a ak klaster neprekračuje stanovené limity. CA komunikuje s poskytovateľom cloudových služieb, požaduje od neho ďalšie uzly alebo uvoľňuje nečinné. Prvá všeobecne dostupná verzia CA bola predstavená v Kubernetes 1.8.

Schéma prevádzky SA na vysokej úrovni:

  1. CA kontroluje čakajúce moduly v predvolenom intervale 10 sekúnd.
  2. Ak je jeden alebo viac modulov v pohotovostnom stave, pretože klaster nemá dostatok dostupných prostriedkov na ich pridelenie, pokúsi sa poskytnúť jeden alebo viacero ďalších uzlov.
  3. Keď poskytovateľ cloudových služieb pridelí požadovaný uzol, pripojí sa ku klastra a je pripravený poskytovať moduly.
  4. Plánovač Kubernetes distribuuje čakajúce moduly do nového uzla. Ak potom niektoré moduly stále zostávajú v stave čakania, proces sa zopakuje a do klastra sa pridajú nové uzly.

Tri úrovne automatického škálovania v Kubernetes: Ako ich efektívne používať
Automatické poskytovanie uzlov klastra v cloude

Pri používaní CA zvážte nasledovné:

  • CA zabezpečuje, že všetky moduly v klastri majú priestor na spustenie bez ohľadu na zaťaženie procesora. Snaží sa tiež zabezpečiť, aby v klastri neboli žiadne zbytočné uzly.
  • CA zaregistruje potrebu škálovania približne po 30 sekundách.
  • Akonáhle uzol už nie je potrebný, CA predvolene počká 10 minút pred škálovaním systému.
  • Systém automatického škálovania má koncepciu expandérov. Ide o rôzne stratégie výberu skupiny uzlov, do ktorých sa pridajú nové uzly.
  • Použite túto možnosť zodpovedne cluster-autoscaler.kubernetes.io/safe-to-evict (pravda). Ak nainštalujete veľa modulov alebo ak je veľa z nich rozptýlených vo všetkých uzloch, do značnej miery stratíte schopnosť škálovať klaster.
  • použitie PodDisruptionBudgetsaby ste zabránili vymazaniu modulov, čo by mohlo spôsobiť úplné zlyhanie častí vašej aplikácie.

Ako medzi sebou automatické škálovače Kubernetes interagujú

Pre dokonalú harmóniu by sa malo použiť automatické škálovanie na úrovni modulu (HPA/VPA) aj na úrovni klastra. Navzájom sa vzájomne ovplyvňujú pomerne jednoducho:

  1. HPA alebo VPA aktualizujú repliky modulov alebo prostriedky pridelené existujúcim modulom.
  2. Ak nie je dostatok uzlov na plánované škálovanie, CA si všimne prítomnosť podov v čakacom stave.
  3. CA prideľuje nové uzly.
  4. Moduly sú distribuované do nových uzlov.

Tri úrovne automatického škálovania v Kubernetes: Ako ich efektívne používať
Kolaboratívny systém škálovania Kubernetes

Bežné chyby v automatickom škálovaní Kubernetes

Existuje niekoľko bežných problémov, s ktorými sa devops stretáva pri pokuse o implementáciu automatického škálovania.

HPA a VPA závisia od metrík a niektorých historických údajov. Ak nie sú alokované dostatočné zdroje, moduly budú minimalizované a nebudú schopné generovať metriky. V tomto prípade sa automatické škálovanie nikdy neuskutoční.

Samotná operácia škálovania je citlivá na čas. Chceme, aby sa moduly a klaster rýchlo škálovali – skôr, ako používatelia zaznamenajú akékoľvek problémy alebo zlyhania. Preto by sa mal brať do úvahy priemerný čas škálovania strukov a klastra.

Ideálny scenár – 4 minúty:

  1. 30 sekúnd. Aktualizujte cieľové metriky: 30 – 60 sekúnd.
  2. 30 sekúnd. HPA kontroluje metrické hodnoty: 30 sekúnd.
  3. Menej ako 2 sekundy. Moduly sa vytvoria a prejdú do stavu čakania: 1 sekunda.
  4. Menej ako 2 sekundy. CA vidí čakajúce moduly a posiela hovory do uzlov poskytovania: 1 sekunda.
  5. 3 minúty. Poskytovateľ cloudu prideľuje uzly. K8s čaká, kým budú pripravené: až 10 minút (v závislosti od viacerých faktorov).

Najhorší prípad (realistickejší) scenár – 12 minút:

  1. 30 sekúnd. Aktualizujte cieľové metriky.
  2. 30 sekúnd. HPA kontroluje metrické hodnoty.
  3. Menej ako 2 sekundy. Moduly sa vytvoria a prejdú do pohotovostného stavu.
  4. Menej ako 2 sekundy. CA vidí čakajúce moduly a zavolá na poskytovanie uzlov.
  5. 10 minút. Poskytovateľ cloudu prideľuje uzly. K8 čaká, kým budú pripravené. Čakacia doba závisí od niekoľkých faktorov, ako je oneskorenie dodávateľa, oneskorenie operačného systému a nástroje podpory.

Nepleťte si škálovacie mechanizmy poskytovateľov cloudu s našou CA. Ten beží vo vnútri klastra Kubernetes, zatiaľ čo motor poskytovateľa cloudu funguje na báze distribúcie uzlov. Nevie, čo sa deje s vašimi modulmi alebo aplikáciou. Tieto systémy fungujú paralelne.

Ako spravovať škálovanie v Kubernetes

  1. Kubernetes je nástroj na správu a orchestráciu zdrojov. Operácie na správu modulov a klastrových prostriedkov sú kľúčovým míľnikom v ovládaní Kubernetes.
  2. Pochopte logiku škálovateľnosti pod s ohľadom na HPA a VPA.
  3. CA by ste mali používať len vtedy, ak dobre rozumiete potrebám svojich strukov a nádob.
  4. Ak chcete optimálne nakonfigurovať klaster, musíte pochopiť, ako rôzne systémy škálovania spolupracujú.
  5. Pri odhadovaní času škálovania majte na pamäti najhoršie a najlepšie scenáre.

Zdroj: hab.com

Pridať komentár