Pre každý zdroj Kubernetes je možné nastaviť dva typy požiadaviek — Requests a Limits. Prvé popisuje minimálne požiadavky na dostupnosť voľných zdrojov uzla, potrebných na spustenie kontajnera alebo podu, druhé striktne obmedzuje zdroje dostupné kontajneru.
Keď Kubernetes plánuje pod, je veľmi dôležité, aby kontajnery mali dostatok zdrojov na normálnu prevádzku. Ak plánujete nasadiť veľkú aplikáciu na uzle s obmedzenými zdrojmi, je veľmi pravdepodobné, že nebude fungovať, pretože uzlu dochádza pamäť alebo mu chýba výkon procesora. V tomto článku sa pozrieme, ako možno vyriešiť problémy s nedostatkom výpočtových zdrojov pomocou požiadaviek na zdroje a obmedzení.
Požiadavky Requests a obmedzenia Limits sú mechanizmy, ktoré Kubernetes používa na správu takýchto zdrojov, ako je napríklad procesor a pamäť. Requests sú to, v dôsledku ktorých kontajner garantovane dostáva požadovaný zdroj. Ak kontajner požaduje zdroj, Kubernetes ho naplánuje len na tom uzle, ktorý ho dokáže poskytnúť. Obmedzenia Limits kontrolujú, aby zdroje, ktoré kontajner požaduje, nikdy neprekročili určitú hodnotu.
Kontajner môže zvyšovať výpočtové kapacity 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 pody. Typická špecifikácia zdrojov pre pod vyzerá takto.
Každý kontajner v pod môže nastaviť svoje vlastné požiadavky a obmedzenia, všetko je to aditívne. Zdroje procesora sú definované v milikrohrách. Ak váš kontajner na spustenie potrebuje dva plné jadrá, nastavíte hodnotu 2000m. Ak však kontajnerovi stačí výkon iba 1/4 jadra, hodnota bude 250m. Majte na pamäti, že ak priradíte hodnotu procesorových zdrojov vyššiu ako počet jadier najväčšieho uzla, spustenie vášho podu nebude vôbec naplánované. Podobná situácia nastane, ak máte pod, ktorý potrebuje štyri jadrá, a klaster Kubernetes pozostáva iba z dvoch základných virtuálnych strojov.
Ak vaše aplikácie nie sú vyvinuté špeciálne na využitie výhod viacerých jadier (na mysli máme také programy, ako sú zložité vedecké výpočty a operácie s databázami), najlepšou praxou je nastaviť požiadavky CPU na 1 alebo menej a následne spustiť väčší počet replik pre škálovateľnosť. Toto riešenie poskytne systému väčšiu flexibilitu a spoľahlivosť.
Keď príde na obmedzenia procesora, všetko sa stáva zaujímavejším, pretože je považovaný za kompresibilný zdroj. Ak sa vaša aplikácia začne blížiť k limitu procesorového výkonu, Kubernetes začne obmedzovať váš kontajner pomocou CPU Throttling — zníženia frekvencie procesora. To znamená, že procesor bude umelo obmedzený, čo môže viesť k horšiemu výkonu aplikácie, avšak proces nebude prerušený alebo ukončený.
Zdroje pamäte sú definované v bajtoch. Zvyčajne sa hodnota v nastaveniach meria v mebibajtoch Mib, ale môžete zadať akúkoľvek hodnotu, od bajtov po petabajty. Tu platí tá istá situácia ako s CPU — ak umiestnite požiadavku na množstvo pamäte, ktoré presahuje objem pamäte na vašich uzloch, vykonanie tohto podu nebude naplánované. Na rozdiel od procesorových zdrojov však pamäť nie je kompresibilná, pretože neexistuje žiaden spôsob, ako obmedziť jej používanie. Preto sa vykonávanie kontajnera zastaví, akonáhle prekročí pridelenú pamäť.
Je dôležité si uvedomiť, že nemôžete nastaviť požiadavky, ktoré presahujú kapacity zdrojov, ktoré môžu vaše uzly poskytnúť. Vlastnosti zdieľaných zdrojov pre virtuálne stroje GKE nájdete v odkazoch umiestnených pod týmto videom.
V ideálnom svete by predvolené nastavenia kontajnera mali byť dostatočné na to, aby pracovné toky prebiehali hladko. Skutočný svet však nie je taký, ľudia môžu ľahko zabudnúť nastaviť využívanie zdrojov alebo hackeri nastavia požiadavky a obmedzenia presahujúce reálne kapacity infraštruktúry. Aby sa predišlo rozvoju takýchto scenárov, je možné nastaviť kvóty zdrojov ResourceQuota a rozsahy obmedzení LimitRange.
Po vytvorení menného priestoru ich môžete zablokovať pomocou kvót. Napríklad, ak máte menné priestory prod a dev, použije sa vzor, v ktorom kvóty pre produkciu vôbec neexistujú, zatiaľ čo kvóty pre vývoj sú veľmi prísne. To umožňuje prod v prípade náhleho nárastu prevádzky získať všetky dostupné zdroje a úplne zablokovať dev.
Kvóta zdrojov môže vyzerať takto. V tomto príklade sú štyri sekcie – to sú štyri dolné riadky kódu.
Pozrime sa na každú z nich. Requests.cpu je maximálne kombinované množstvo požiadaviek na procesorový výkon, ktoré môžu prichádzať od všetkých kontajnerov v mennom priestore. V tomto príklade môžete mať 50 kontajnerov so žiadosťami po 10m, päť kontajnerov so žiadosťami po 100m alebo jednoducho jeden kontajner so žiadosťou 500m. Pokiaľ celkové množstvo requests.cpu tohto menného priestoru bude menej než 500m, všetko bude v poriadku.
Požadovaná pamäť requests.memory je maximálna kombinovaná kapacita 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 kontajnerov po 2 MiB, päť kontajnerov po 20 MiB alebo jediný kontajner s 100 MiB, pokiaľ celkové množstvo požadovanej pamäte v mennom priestore bude menej než 100 mebibajtov.
Limits.cpu je maximálna kombinovaná hodnota procesorového výkonu, ktorú môžu všetky kontajnery v mennom priestore používať. Môže sa považovať za limit požiadaviek na procesorový výkon.
Nakoniec, limits.memory – maximálny objem celkovej pamäte, ktorý môžu využiť všetky kontajnery v menej priestore. Toto obmedzenie súhrnných požiadaviek na pamäť.
Takže, predvolene kontajnery v klastri Kubernetes fungujú s neobmedzenými výpočtovými zdrojmi. Pomocou kvót zdrojov môžu administrátori klastra obmedziť spotrebu zdrojov a ich vytváranie na základe menej priestoru. V menej priestore môže modul pod alebo kontajner spotrebovať toľko výkonu CPU a pamäte, koľko je určené kvótou zdrojov menej priestoru. Existuje však obava, že jeden pod alebo kontajner môže monopolizovať všetky dostupné zdroje. Na zabránenie takejto situácie sa používa obmedzujúci rozsah limit Range – politika obmedzovania rozdeľovania zdrojov (pre pod alebo kontajnery) v menej priestore.
Obmedzujúci rozsah poskytuje obmedzenia, ktoré môžu:
- zabezpečiť minimálne a maximálne používanie výpočtových zdrojov pre každý modul alebo kontajner v menej priestore;
- prísne vykonávať minimálny a maximálny požiadavok na úložisko Storage Request pre každý PersistentVolumeClaim v menej priestore;
- prísne stanoviť pomer medzi požiadavkou Request a obmedzením Limit pre zdroj v menej priestore;
- stanoviť Requests/Limits predvolene pre výpočtové zdroje v menej priestore a automaticky ich zavádzať do kontajnerov počas prevádzky.
Takže môžete vytvoriť obmedzujúci rozsah vo svojom menej priestore. Na rozdiel od kvóty, ktorá sa vzťahuje na celé meno priestoru, Limit Range sa používa pre jednotlivé kontajnery. To môže zabrániť vytváraniu veľmi malých alebo naopak obrovských kontajnerov v menej priestore. Obmedzujúci rozsah Limit Range môže vyzerať takto.
Ako v predchádzajúcom prípade, tu môžeme vyzdvihnúť 4 sekcie. Pozrime sa na každú.
V sekcii default sú stanovené obmedzenia predvolene pre kontajner v pode. Ak nastavíte tieto hodnoty v obmedzujúcom rozsahu, akékoľvek kontajnery, pre ktoré tieto hodnoty neboli výslovne určené, budú sa riadiť hodnotami predvolene.
V sekcii defaultRequest sú nastavené predvolené požiadavky pre kontajner v pode. Znova, ak nastavíte tieto hodnoty na maximálne rozmedzie, akékoľvek kontajnery, pre ktoré tieto parametre nie sú výslovne nastavené, budú používať tieto predvolené hodnoty.
V sekcii max sú uvedené maximálne obmedzenia, ktoré môžu byť nastavené pre kontajner v pode. Hodnoty v sekcii default a obmedzenia pre kontajner nemôžu byť nastavené nad tento limit. Je dôležité poznamenať, že ak je nastavená hodnota max a sekcia default chýba, maximálna hodnota sa stáva predvolenou hodnotou.
V sekcii min sú uvedené minimálne požiadavky, ktoré môžu byť nastavené pre kontajner v pode. Hodnoty v sekcii default a požiadavky pre kontajner nemôžu byť nastavené pod tento limit.
Znova, je dôležité poznamenať, že ak je táto hodnota nastavená a hodnota default nie je, minimálna hodnota sa stáva požiadavkou predvolene.
Nakoniec tieto požiadavky na zdroje používa plánovač Kubernetes na vykonávanie vašich pracovných záťaží. Aby ste mohli správne nastaviť svoje kontajnery, je veľmi dôležité pochopiť, ako to funguje. Predpokladajme, že chcete spustiť niekoľko modulov vo svojom klastri. Ak sú špecifikácie podu platné, na plánovanie Kubernetes sa použije cyklické zaťaženie na výber uzla na vykonanie pracovnej záťaže.
Kubernetes skontroluje, či má uzol Node 1 dostatok zdrojov na vykonanie požiadaviek kontajnerov podu, a ak nie, prejde k nasledujúcemu uzlu. Ak však žiadny z uzlov v systéme nie je schopný uspokojiť požiadavky, pady prejdú do stavu čakajúceho Pending state. Pomocou funkcií Google Kubernetes Engine, ako je automatické škálovanie uzlov, môže GKE automaticky určiť stav čakajúceho a vytvoriť niekoľko ďalších uzlov.
Ak neskôr nastane nadbytočná kapacita uzlov, funkcia automatického škálovania zníži ich počet, aby vám ušetrila peniaze. Preto Kubernetes plánuje pady na základe požiadaviek. Môže sa však stať, že limit 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 overcommitment.
Ako som už povedal, keď ide o procesor, Kubernetes začne obmedzovať pod. Každý pod dostane toľko, koľko požiadal, ale ak nedosiahne limit, začne sa uplatňovať spomalenie.
Pokiaľ ide o pamäťové zdroje, Kubernetes je nútený prijímať rozhodnutia o tom, ktoré pódy odstrániť a ktoré zachovať, kým neuvoľníte systémové zdroje, inak sa celý systém rozpadne.
Predstavme si scenár, v ktorom máte stroj, ktorý vyčerpal limit pamäte – ako sa v takom prípade správa Kubernetes?
Kubernetes bude hľadať pódy, ktoré používajú viac zdrojov, ako požadovali. Ak vaše kontajnery nemajú žiadne požiadavky, znamená to, že predvolene používajú viac, ako požiadali, jednoducho preto, že vôbec nič nepožiadali! Takéto kontajnery sa stávajú hlavnými kandidátmi na vypnutie. Nasledujúcimi kandidátmi sú kontajnery, ktoré splnili všetky svoje požiadavky, ale stále sú pod maximálnym limitom.
Ak Kubernetes nájde niekoľko podov, ktoré prekročili parametre svojich požiadaviek, zoradí ich podľa priority a potom odstráni najnižšie prioritné moduly. Ak majú všetky moduly rovnakú prioritu, Kubernetes zastaví prevádzku tých podov, ktoré prekročili svoje požiadavky viac ako ostatné pódy.
Vo veľmi zriedkavých prípadoch môže Kubernetes prerušiť činnosť podov, ktoré sú stále v rámci svojich požiadaviek. To sa môže stať, keď také kritické komponenty systému, ako je agent Kubelet alebo Docker, začnú spotrebovávať viac zdrojov, ako bolo pre nich rezervované.
Takže v počiatočných fázach fungovania malých spoločností môže klaster Kubernetes fungovať bez nastavenia požiadaviek na zdroje a obmedzení, ale s rastom vašich tímov a projektov riskujete, že sa stretnete s problémami v tejto oblasti. Pridanie požiadaviek a obmedzení do vašich modulov a názvových priestorov si vyžaduje len veľmi málo dodatočného úsilia a môže vás zbaviť mnohých problémov.
Trochu reklamy 🙂
Ďakujeme, že ostávate s nami. Páčia sa vám naše články? Chcete vidieť viac zaujímavých materiálov? Podporte nás, vytvorením objednávky alebo odporúčaním známym, , unikátny ekvivalent entry-level serverov, ktorý sme pre vás vytvorili: (k dispozícii varianty s RAID1 a RAID10, až 24 jadier a až 40GB DDR4).
Dell R730xd je dvakrát lacnejší v dátovom centre Equinix Tier IV v Amsterdame? Len u nás v Holandsku! Dell R420 — 2x E5-2430 2.2Ghz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — od 99 dolárov! Prečítajte si o tom
Zdroj: habr.com
