Pro každý Kubernetes zdroj je možné nastavit dva typy požadavků – Requests a Limits. První popisuje minimální požadavky na dostupnost volných prostředků uzlu potřebných pro spuštění kontejneru nebo podu, druhé striktně omezuje prostředky dostupné kontejneru.
Když Kubernetes plánuje pod, je velmi důležité, aby kontejnery měly dostatek zdrojů pro normální fungování. Pokud plánujete nasadit velkou aplikaci na uzlu s omezenými prostředky, je možné, že nebude fungovat kvůli nedostatku paměti nebo procesorového výkonu. V tomto článku se podíváme na to, jak lze vyřešit problémy s nedostatkem výpočetních výkonů pomocí požadavků na prostředky a limitů.
Požadavky Requests a limity Limits jsou mechanismy, které Kubernetes používá k řízení takových prostředků, jako je například procesor a paměť. Requests je to, co kontejner zaručeně dostane jako požadovaný zdroj. Pokud kontejner požaduje zdroj, Kubernetes plánuje jeho nasazení pouze na tom uzlu, který je schopen ho poskytnout. Limity Limits kontrolují, aby zdroje požadované kontejnery nikdy nepřesáhly určitou hodnotu.
Kontejner může zvyšovat výpočetní výkon pouze do určitého limitu, po kterém bude omezen. Pojďme se podívat, jak to funguje. Existují dva typy zdrojů – procesor a paměť. Plánovač Kubernetes používá údaje o těchto zdrojích k určení, kde spustit vaše pody. Typická specifikace zdrojů pro pod vypadá takto.
Každý kontejner v podu může nastavit své vlastní požadavky a omezení, vše se sčítá. Procesorové zdroje jsou určeny v mili-kroch. Pokud váš kontejner potřebuje k běhu dvě plná jádra, nastavíte hodnotu 2000m. Pokud však kontejner potřebuje pouze jednu čtvrtinu jádra, hodnota bude 250m. Mějte na paměti, že pokud nastavíte hodnotu procesorových zdrojů vyšší než počet jader největšího uzlu, váš pod nebude vůbec naplánován k spuštění. Podobná situace nastane, pokud máte pod, který potřebuje čtyři jádra, a Kubernetes cluster se skládá pouze ze dvou hlavních virtuálních strojů.
Pokud vaše aplikace není navržena speciálně pro využití výhod více jader (přičemž na mysli máme takové programy, jako jsou složité vědecké výpočty a operace s databázemi), je nejlepší praxí nastavit CPU Requests na 1 nebo nižší s následným spuštěním většího počtu replik pro škálovatelnost. Toto řešení dodá systému větší flexibilitu a spolehlivost.
Když přijde řeč na omezení procesoru, vše se stává zajímavějším, protože se považuje za komprimovaný zdroj. Pokud se vaše aplikace začne blížit k limitu procesorového výkonu, Kubernetes začne zpomalovat váš kontejner pomocí CPU Throttling — snižování frekvence procesoru. To znamená, že procesor bude uměle omezen, což může znamenat horší výkon aplikace, avšak proces nebude přerušen ani vyřazen.
Zdroje paměti jsou určeny v bajtech. Obvykle se hodnota v nastaveních měří v mebibajtech Mib, ale můžete zadat jakoukoli hodnotu, od bajtů po petabajty. zde platí ta samá situace jako u CPU — pokud zadáte požadavek na množství paměti, které překračuje kapacitu paměti vašich uzlů, provádění tohoto podu nebude naplánováno. Ale na rozdíl od procesorových zdrojů se paměť nedá komprimovat, protože neexistuje žádný způsob, jak omezit její používání. Proto bude provádění kontejneru zastaveno, jakmile překročí přidělenou paměť.
Je důležité mít na paměti, že nemůžete nastavit požadavky, které přesahují kapacitu dostupných zdrojů vašich uzlů. Vlastnosti sdílených zdrojů pro virtuální stroje GKE naleznete na odkazech umístěných pod tímto videem.
V ideálním světě by výchozí nastavení kontejneru bylo zcela dostatečné pro bezproblémový běh pracovních procesů. Skutečný svět však takový není, lidé snadno zapomínají nastavit využití zdrojů nebo hackeři mohou nastavit požadavky a limity, které přesahují skutečné možnosti infrastruktury. Aby se předešlo takovým scénářům, je možné nastavit kvóty zdrojů ResourceQuota a rozsahy limitů LimitRange.
Po vytvoření jmenného prostoru je možné jej zablokovat pomocí kvót. Například, pokud máte jmenné prostory prod a dev, používá se šablona, kde kvóty na produkci nejsou vůbec, zatímco kvóty na vývoj jsou velmi přísné. To umožňuje prostředí prod v případě náhlého nárůstu provozu zabrat všechny dostupné zdroje a úplně zablokovat dev.
Kvóta zdrojů může vypadat takto. V tomto příkladu jsou zde 4 sekce – jde o 4 spodní řádky kódu.
Podívejme se na každou z nich. Requests.cpu představuje maximální počet kombinovaných požadavků na procesorový výkon, které mohou pocházet ze všech kontejnerů v jmenném prostoru. V tomto příkladu můžete mít 50 kontejnerů s požadavky po 10m, pět kontejnerů s požadavky po 100m nebo jednoduše jeden kontejner s požadavkem 500m. Dokud celkové množství requests.cpu tohoto jmenného prostoru bude menší než 500m, všechno bude v pořádku.
Požadovaná paměť requests.memory je maximální množství kombinovaných požadavků na paměť, které mohou mít všechny kontejnery v jmenném prostoru. Podobně jako v předchozím případě, můžete mít 50 kontejnerů po 2 MiB, pět kontejnerů po 20 MiB nebo jeden jediný kontejner s 100 MiB, dokud celkové množství požadované paměti v jmenném prostoru nebude menší než 100 mebibajtů.
Limits.cpu je maximální kombinovaná hodnota procesorového výkonu, kterou mohou použít všechny kontejnery v jmenném prostoru. Můžeme to považovat za strop požadavků na procesorový výkon.
Nakonec, limits.memory – maximální objem celkové paměti, který mohou používat všechna kontejnery ve jmenném prostoru. Toto omezení se týká souhrnných požadavků na paměť.
Takže ve výchozím nastavení kontejnery v klastru Kubernetes pracují s neomezenými výpočetními zdroji. Pomocí kvót zdrojů mohou administrátoři klastra omezit spotřebu zdrojů a jejich vytváření na základě jmenného prostoru. V jmenném prostoru může modul pod nebo kontejner spotřebovávat tolik CPU a paměti, kolik je definováno kvótou zdrojů jmenného prostoru. Existuje však obava, že jeden pod nebo kontejner může monopolizovat všechny dostupné zdroje. K zamezení takové situace se používá předlimitní rozsah limit Range – politika omezování přidělování zdrojů (pro pody nebo kontejnery) v jmenném prostoru.
Předlimitní rozsah poskytuje omezení, která mohou:
- zajistit minimální a maximální využití výpočetních zdrojů pro každý modul nebo kontejner v jmenném prostoru;
- vynutit minimální a maximální požadavek na úložiště Storage Request pro každý PersistentVolumeClaim v jmenném prostoru;
- vynutit nastavení poměru mezi požadavkem Request a omezením Limit pro zdroj v jmenném prostoru;
- nastavovat Requests/Limits ve výchozím nastavení pro výpočetní zdroje v jmenném prostoru a automaticky je zavádět do kontejnerů během provozu.
Takže můžete vytvořit předlimitní rozsah ve svém jmenném prostoru. Na rozdíl od kvóty, která se vztahuje na celý jmenný prostor, se Limit Range používá pro jednotlivé kontejnery. To může zabránit uživatelům vytvářet velmi malé nebo naopak obrovské kontejnery uvnitř jmenného prostoru. Předlimitní rozsah Limit Range může vypadat takto.
Stejně jako v předchozím případě, zde lze vyčlenit 4 sekce. Pojďme se podívat na každou z nich.
V sekci default se nastavují výchozí omezení pro kontejner v podu. Pokud tyto hodnoty určíte v předlimitním rozsahu, jakékoli kontejnery, pro které tyto hodnoty nebyly výslovně nastaveny, budou řízeny výchozími hodnotami.
V oddílu defaultRequest jsou nastaveny výchozí požadavky pro kontejnery v podu. Pokud tato nastavení umístíte do mezí, jakékoli kontejnery, pro které tyto parametry nejsou výslovně nastaveny, budou používat tyto výchozí hodnoty.
V oddílu max jsou uvedena maximální omezení, která mohou být nastavena pro kontejner v podu. Hodnoty v části default a omezení pro kontejnery nelze nastavit nad tento limit. Je důležité poznamenat, že pokud je nastavena hodnota max a oddíl default neexistuje, pak se maximální hodnota stává výchozí hodnotou.
V oddílu min jsou uvedeny minimální požadavky, které mohou být nastaveny pro kontejner v podu. Hodnoty v oddílu default a požadavky pro kontejnery nelze nastavit pod tento limit.
Je důležité poznamenat, že pokud je tato hodnota nastavena a hodnota default není, pak minimální hodnota se stává výchozím požadavkem.
Tyto požadavky na zdroje používá plánovač Kubernetes k provádění vašich pracovních zátěží. Abyste mohli správně nastavit své kontejnery, je velmi důležité pochopit, jak to funguje. Předpokládejme, že chcete spustit několik modulů ve svém clusteru. Předpokládající, že specifikace podu jsou platné, bude v plánování Kubernetes použito cyklické vyvážení zatížení k výběru uzlu pro vykonání pracovního zatížení.
Kubernetes zkontroluje, zda má uzel Node 1 dostatek prostředků na splnění požadavků kontejnerů podu, a pokud ne, přejde na další uzel. Pokud žádný z uzlů v systému není schopen splnit požadavky, přejdou pod postupně do stavu čekání Pending state. Díky takovým funkcím jako je automatické škálování uzlů v Google Kubernetes Engine (GKE) může GKE automaticky detekovat stav čekání a vytvořit další uzly.
Pokud pak dojde k nadměrné kapacitě uzlů, funkce automatického škálování sníží jejich počet, aby vám ušetřila peníze. Proto Kubernetes plánuje pody na základě požadavků. Limit může být vyšší než požadavky, a v některých případech může uzel skutečně vyčerpat zdroje. Tento stav nazýváme stavem overcommitment.
Jak jsem již zmínil, pokud jde o procesor, Kubernetes začne omezovat pody. Každý pod dostane tolik, kolik požádal, ale pokud nedosáhne limitu, začne se uplatňovat throttling.
Pokud jde o paměťové zdroje, Kubernetes je nucen rozhodnout, které pody odstranit a které zachovat, dokud neuvolníte systémové zdroje, jinak se celý systém zhroutí.
Představme si scénář, kdy máte stroj, který vyčerpal limit paměti – jak se Kubernetes v takovém případě zachová?
Kubernetes bude hledat pody, které využívají více zdrojů než požádaly. Takže pokud vaše kontejnery vůbec nemají žádné požadavky, znamená to, že defaultně používají více, než požádaly, jednoduše proto, že vůbec nic nepožádaly! Takové kontejnery se stávají hlavními kandidáty na vypnutí. Dalšími kandidáty jsou kontejnery, které splnily všechny své požadavky, ale stále zůstávají pod maximálním limitem.
Pokud Kubernetes najde několik podů, které překročily parametry svých požadavků, seřadí je podle priority a poté odstraní ty s nejnižší prioritou. Pokud mají všechny moduly stejnou prioritu, Kubernetes zastaví práci těch podů, které překročily své požadavky více než ostatní pody.
Ve velmi vzácných případech může Kubernetes přerušit práci podů, které stále zůstávají v rámci svých požadavků. K tomu může dojít, když takové kritické komponenty systému, jako je agent Kubelet nebo Docker, začnou spotřebovávat více zdrojů, než bylo pro ně rezervováno.
Takže v úvodních fázích fungování malých společností může klastr Kubernetes fungovat skvěle bez nastavování požadavků na zdroje a limitů, ale jakmile začnou vaše týmy a projekty růst, riskujete, že se setkáte s problémy v této oblasti. Přidání požadavků a limitů do vašich modulů a jmenných prostorů vyžaduje jen velmi málo dalších úsilí a může vás zbavit mnoha potíží.
Malá reklama 🙂
Děkujeme, že s námi zůstáváte. Líbí se vám naše články? Chcete vidět více zajímavých materiálů? Podpořte nás objednávkou nebo doporučením známým, , unikátní alternativa entry-level serverů, kterou jsme pro vás vymysleli: (k dispozici varianty s RAID1 a RAID10, až 24 jader a až 40GB DDR4).
Dell R730xd je dvakrát levnější v datovém centru Equinix Tier IV v Amsterdamu? Jen u nás v Nizozemsku! Dell R420 — 2x E5-2430 2.2GHz 6C 128GB DDR3 2x960GB SSD 1Gbps 100TB — od 99 $! Čtěte o tom
Zdroj: habr.com
