Pre každý zdroj Kubernetes môžete nakonfigurovať dva typy požiadaviek – požiadavky a limity. Prvý popisuje minimálne požiadavky na dostupnosť voľných zdrojov uzla potrebných na spustenie kontajnera alebo podu, druhý prísne obmedzuje zdroje dostupné pre kontajner.
Keď Kubernetes plánuje moduly, je veľmi dôležité, aby kontajnery mali dostatok zdrojov na správne fungovanie. Ak plánujete nasadiť veľkú aplikáciu na uzle s obmedzenými zdrojmi, je možné, že sa nespustí, pretože uzol má málo pamäte alebo výkon procesora. V tomto článku sa pozrieme na to, ako môžete vyriešiť nedostatok výpočtového výkonu pomocou požiadaviek na zdroje a limitov.
Požiadavky a limity sú mechanizmy, ktoré Kubernetes používa na správu zdrojov, ako sú CPU a pamäť. Požiadavky zabezpečujú, že kontajner dostane požadovaný zdroj. Ak kontajner požaduje zdroj, Kubernetes ho naplánuje iba v uzle, ktorý ho môže poskytnúť. Limity riadia, že zdroje požadované kontajnerom nikdy neprekročia určitú hodnotu.
Kontajner môže zvýšiť svoj výpočtový výkon len do určitého limitu, po ktorom bude obmedzený. Pozrime sa, ako to funguje. Existujú teda dva typy zdrojov - procesor a pamäť. Plánovač Kubernetes používa údaje o týchto zdrojoch, aby zistil, kde spustiť vaše moduly. Typická špecifikácia zdroja pre modul vyzerá takto.
Každý kontajner v pod môže nastaviť svoje vlastné otázky a limity, všetko je aditívne. Zdroje procesora sú definované v milicores. Ak váš kontajner potrebuje na spustenie dve plné jadrá, nastavte hodnotu na 2000 m. Ak kontajner potrebuje výkon iba 1/4 jadra, hodnota bude 250m. Majte na pamäti, že ak priradíte hodnotu prostriedku CPU väčšiu ako počet jadier najväčšieho uzla, spustenie vašej pod nebude vôbec naplánované. Podobná situácia nastane, ak máte Pod, ktorý potrebuje štyri jadrá a klaster Kubernetes tvoria iba dva hlavné virtuálne počítače.
Pokiaľ nie je vaša aplikácia navrhnutá špeciálne na využitie viacerých jadier (napadnú ma programy ako zložité vedecké výpočty a databázové operácie), potom je najlepším postupom nastaviť požiadavky CPU na hodnotu 1 alebo nižšiu a potom spustiť viac replík na škálovateľnosť. Toto riešenie poskytne systému väčšiu flexibilitu a spoľahlivosť.
Pokiaľ ide o obmedzenia CPU, veci sú zaujímavejšie, pretože sa považuje za komprimovateľný zdroj. Ak sa vaša aplikácia začne blížiť k limitu výkonu procesora, Kubernetes začne spomaľovať váš kontajner pomocou CPU Throttling – zníženie frekvencie procesora. To znamená, že CPU bude umelo priškrtené, čo dáva aplikácii potenciálne horší výkon, ale proces nebude ukončený ani vyradený.
Pamäťové prostriedky sú definované v bajtoch. Zvyčajne sa hodnota v nastaveniach meria v mebibajtoch Mib, ale môžete nastaviť akúkoľvek hodnotu, od bajtov po petabajty. Platí tu rovnaká situácia ako pri CPU – ak zadáte požiadavku na množstvo pamäte väčšie ako je množstvo pamäte na vašich uzloch, nebude naplánované spustenie tohto modulu. Ale na rozdiel od zdrojov CPU, pamäť nie je komprimovaná, pretože neexistuje spôsob, ako obmedziť jej použitie. Preto sa vykonávanie kontajnera zastaví, len čo presiahne pridelenú pamäť.
Je dôležité si zapamätať, že nemôžete konfigurovať požiadavky, ktoré presahujú zdroje, ktoré môžu poskytnúť vaše uzly. Špecifikácie zdieľaných prostriedkov pre virtuálne stroje GKE nájdete v odkazoch pod týmto videom.
V ideálnom svete by predvolené nastavenia kontajnera postačovali na udržanie hladkého chodu pracovných postupov. Reálny svet ale taký nie je, ľudia môžu ľahko zabudnúť na konfiguráciu využívania zdrojov, prípadne hackeri nastavia požiadavky a obmedzenia, ktoré presahujú reálne možnosti infraštruktúry. Ak chcete zabrániť výskytu takýchto scenárov, môžete nakonfigurovať kvóty prostriedkov ResourceQuota a LimitRange.
Po vytvorení menného priestoru ho možno zablokovať pomocou kvót. Napríklad, ak máte menné priestory prod a dev, vzor je taký, že neexistujú žiadne výrobné kvóty a veľmi prísne kvóty na vývoj. To umožňuje produktu v prípade prudkého nárastu návštevnosti prevziať celý dostupný zdroj a úplne zablokovať vývoj.
Kvóta zdrojov môže vyzerať takto. V tomto príklade sú 4 sekcie – to sú 4 spodné riadky kódu.
Pozrime sa na každú z nich. Requests.cpu je maximálny počet kombinovaných požiadaviek CPU, ktoré môžu pochádzať zo všetkých kontajnerov v mennom priestore. V tomto príklade by ste mohli mať 50 kontajnerov s 10 miliónmi požiadaviek, päť kontajnerov so 100 miliónmi požiadaviek alebo len jeden kontajner s 500 miliónmi požiadaviek. Pokiaľ je celkový počet request.cpu daného menného priestoru menší ako 500 m, všetko bude v poriadku.
Požiadavky na pamäť. pamäť je maximálny počet kombinovaných požiadaviek na pamäť, ktoré môžu mať všetky kontajnery v mennom priestore. Rovnako ako v predchádzajúcom prípade môžete mať 50 2 mib kontajnerov, päť 20 mib kontajnerov alebo jeden 100 mib kontajner, pokiaľ je celkové množstvo pamäte požadovanej v mennom priestore menšie ako 100 mebibajtov.
Limits.cpu je maximálne kombinované množstvo výkonu CPU, ktoré môžu použiť všetky kontajnery v mennom priestore. To môžeme považovať za limit požiadaviek na výkon procesora.
Nakoniec, limity.pamäť je maximálne množstvo zdieľanej pamäte, ktorú môžu používať všetky kontajnery v mennom priestore. Toto je limit celkových požiadaviek na pamäť.
V predvolenom nastavení teda kontajnery v klastri Kubernetes bežia s neobmedzenými výpočtovými zdrojmi. Pomocou kvót prostriedkov môžu správcovia klastra obmedziť spotrebu prostriedkov a vytváranie prostriedkov na základe priestoru názvov. V priestore názvov môže modul alebo kontajner spotrebovať toľko energie CPU a pamäte, ako je určené kvótou prostriedkov priestoru názvov. Existuje však obava, že jeden modul alebo kontajner môže monopolizovať všetky dostupné zdroje. Aby sa predišlo tejto situácii, používa sa limitný rozsah - politika na obmedzenie alokácie zdrojov (pre pody alebo kontajnery) v mennom priestore.
Limitný rozsah poskytuje obmedzenia, ktoré môžu:
- Zabezpečte minimálne a maximálne využitie výpočtových zdrojov pre každý modul alebo kontajner v mennom priestore;
- presadzovať minimálne a maximálne požiadavky na úložisko Starage Request pre každý PersistentVolumeClaim v mennom priestore;
- presadiť vzťah medzi Požiadavkou a Limitom pre zdroj v mennom priestore;
- nastaviť predvolené požiadavky/limity pre výpočtové zdroje v mennom priestore a automaticky ich vložiť do kontajnerov za behu.
Týmto spôsobom môžete vytvoriť limitný rozsah vo svojom mennom priestore. Na rozdiel od kvóty, ktorá platí pre celý priestor názvov, Limit Range sa používa pre jednotlivé kontajnery. To môže používateľom zabrániť vo vytváraní veľmi malých alebo naopak gigantických kontajnerov v rámci menného priestoru. Limitný rozsah môže vyzerať takto.
Rovnako ako v predchádzajúcom prípade sa tu dajú rozlíšiť 4 sekcie. Pozrime sa na každý jeden.
Predvolená sekcia nastavuje predvolené limity pre kontajner v pod. Ak nastavíte tieto hodnoty na extrémny rozsah, potom všetky kontajnery, pre ktoré tieto hodnoty neboli explicitne nastavené, budú nasledovať predvolené hodnoty.
Predvolená sekcia požiadaviek defaultRequest konfiguruje predvolené požiadavky pre kontajner v pod. Opäť, ak nastavíte tieto hodnoty na extrémny rozsah, potom všetky kontajnery, ktoré explicitne nenastavia tieto možnosti, budú predvolené na tieto hodnoty.
Časť max určuje maximálne limity, ktoré je možné nastaviť pre kontajner v pod. Hodnoty v predvolenej sekcii a limity kontajnera nemožno nastaviť nad tento limit. Je dôležité poznamenať, že ak je hodnota nastavená na max a neexistuje žiadna predvolená sekcia, potom sa maximálna hodnota stane predvolenou hodnotou.
Sekcia min špecifikuje minimálne požiadavky, ktoré je možné nastaviť pre kontajner v pod. Hodnoty v predvolenej sekcii a dopyty pre kontajner však nemožno nastaviť pod tento limit.
Opäť je dôležité poznamenať, že ak je táto hodnota nastavená, predvolená nie je, potom sa minimálna hodnota stane predvolenou výzvou.
Tieto požiadavky na zdroje v konečnom dôsledku používa plánovač Kubernetes na vykonávanie vašich úloh. Aby ste mohli správne nakonfigurovať svoje kontajnery, je veľmi dôležité pochopiť, ako to funguje. Povedzme, že chcete vo svojom klastri spustiť viacero modulov. Za predpokladu, že špecifikácie modulu sú platné, plán Kubernetes použije kruhové vyvažovanie na výber uzla na spustenie pracovného zaťaženia.
Kubernetes skontroluje, či má Node 1 dostatok zdrojov na splnenie požiadaviek z kontajnerov pod, a ak nie, presunie sa na ďalší uzol. Ak žiadny z uzlov v systéme nie je schopný uspokojiť požiadavky, moduly prejdú do stavu Čakajúce. Pomocou funkcií nástroja Google Kubernetes, ako je automatické škálovanie uzlov, môže GKE automaticky zistiť stav čakania a vytvoriť niekoľko ďalších uzlov.
Ak následne vyčerpáte kapacitu uzla, automatické škálovanie zníži počet uzlov, aby ste ušetrili peniaze. To je dôvod, prečo Kubernetes plánuje moduly na základe požiadaviek. Limit však môže byť vyšší ako požiadavky a v niektorých prípadoch môže uzol skutočne vyčerpať zdroje. Tento stav nazývame stavom previazanosti.
Ako som povedal, pokiaľ ide o CPU, Kubernetes začne obmedzovať moduly. Každý modul dostane toľko, koľko požadoval, ale ak nedosiahne limit, začne sa uplatňovať škrtenie.
Pokiaľ ide o pamäťové prostriedky, Kubernetes je nútený rozhodovať sa o tom, ktoré moduly vymaže a ktoré si ponechajú, kým neuvoľníte systémové prostriedky alebo kým sa celý systém nezrúti.
Predstavme si scenár, v ktorom máte stroj bez pamäte – ako by to Kubernetes zvládol?
Kubernetes vyhľadá moduly, ktoré využívajú viac zdrojov, ako požadovali. Ak teda vaše kontajnery nemajú vôbec žiadne požiadavky, znamená to, že predvolene používajú viac, ako požadovali, jednoducho preto, že nežiadali vôbec nič! Takéto kontajnery sa stávajú hlavnými kandidátmi na odstavenie. Ďalšími kandidátmi sú kontajnery, ktoré splnili všetky ich požiadavky, no stále sú pod maximálnym limitom.
Ak teda Kubernetes nájde niekoľko modulov, ktoré prekročili parametre požiadavky, zoradí ich podľa priority a potom odstráni moduly s najnižšou prioritou. Ak majú všetky moduly rovnakú prioritu, Kubernetes ukončí tie moduly, ktoré prekračujú ich požiadavky viac ako iné moduly.
Vo veľmi zriedkavých prípadoch môže Kubernetes zrušiť moduly, ktoré sú stále v rozsahu ich požiadaviek. To sa môže stať, keď kritické systémové komponenty, ako je Kubelet agent alebo Docker, začnú spotrebovávať viac zdrojov, ako bolo pre ne vyhradené.
Takže v počiatočných fázach malých spoločností môže klaster Kubernetes fungovať dobre bez nastavovania požiadaviek na zdroje a obmedzení, ale keď sa vaše tímy a projekty začnú zväčšovať, riskujete, že narazíte na problémy v tejto oblasti. Pridanie dotazov a obmedzení do vašich modulov a menných priestorov vyžaduje veľmi málo úsilia navyše a môže ušetriť veľa problémov.
Nejaké inzeráty 🙂
Ďakujeme, že ste zostali s nami. Páčia sa vám naše články? Chcete vidieť viac zaujímavého obsahu? Podporte nás zadaním objednávky alebo odporučením priateľom, , jedinečný analóg serverov základnej úrovne, ktorý sme pre vás vymysleli: (k dispozícii s RAID1 a RAID10, až 24 jadier a až 40 GB DDR4).
Dell R730xd 2 krát lacnejší v dátovom centre Equinix Tier IV v Amsterdame? Len tu v Holandsku! Dell R420 – 2x E5-2430 2.2 GHz 6C 128 GB DDR3 2 x 960 GB SSD 1 Gb/s 100 TB – od 99 USD! Čítať o
Zdroj: hab.com