Pro každý zdroj Kubernetes je možné nakonfigurovat dva typy požadavků – Požadavky a Limity. První popisuje minimální požadavky na volné zdroje uzlů potřebné ke spuštění kontejneru nebo podu, druhý výrazně omezuje zdroje dostupné pro kontejner.
Když Kubernetes plánuje pody, je velmi důležité, aby kontejnery měly dostatek prostředků pro normální provoz. Pokud plánujete nasadit velkou aplikaci na hostitele s omezenými prostředky, je možné, že se nespustí, protože hostiteli dochází paměť nebo dochází výkon procesoru. V tomto článku se podíváme na to, jak můžete vyřešit problémy s nedostatkem výpočetního výkonu pomocí požadavků na zdroje a limitů.
Požadavky a limity jsou mechanismy, které Kubernetes používá ke správě zdrojů, jako je CPU a paměť. Požadavky jsou to, co zajišťuje, že kontejner získá požadovaný zdroj. Pokud kontejner požaduje zdroj, Kubernetes jej naplánuje pouze na uzlu, který jej může poskytnout. Omezení řídí, že zdroje požadované kontejnerem nikdy nepřekročí určitou hodnotu.
Kontejner může růst výpočetního výkonu pouze do určité hranice, po jejímž překročení bude omezen. Podívejme se, jak to funguje. Existují tedy dva typy zdrojů – procesor a paměť. Plánovač Kubernetes používá tyto prostředky k tomu, aby zjistil, kde spustit vaše pody. Typická specifikace zdroje pro modul vypadá takto.
Každý kontejner v podu může nastavit své vlastní požadavky a limity, to vše je aditivní. Zdroje procesoru jsou definovány v milicorech. Pokud váš kontejner potřebuje ke svému provozu dvě plná jádra, nastavte hodnotu na 2000 m. Pokud kontejner potřebuje pouze 1/4 výkonu jádra, hodnota bude 250 m. Uvědomte si, že pokud přiřadíte hodnotu prostředku CPU větší, než je počet jader největšího uzlu, nebude spuštění vašeho modulu vůbec naplánováno. Podobná situace nastane, pokud máte pod, který potřebuje čtyři jádra, a cluster Kubernetes se skládá pouze ze dvou hlavních virtuálních strojů.
Pokud vaše aplikace není speciálně navržena tak, aby využívala výhody více jader (takže přicházejí na mysl programy, jako jsou složité vědecké výpočty a databázové operace), pak je nejlepším postupem nastavit požadavky CPU na 1 nebo nižší a poté spustit více replik pro škálovatelnost. Toto řešení poskytne systému větší flexibilitu a spolehlivost.
Pokud jde o omezení CPU, věci jsou zajímavější, protože je považován za komprimovatelný zdroj. Pokud se vaše aplikace začne blížit limitu CPU, Kubernetes začne omezovat váš kontejner pomocí CPU Throttling. To znamená, že procesor bude uměle omezen, což aplikaci poskytne potenciálně horší výkon, ale proces nebude ukončen ani vykreslen.
Paměťové prostředky jsou definovány v bajtech. Obvykle se hodnota v nastavení měří v mebibajtech Mib, ale můžete ji nastavit na libovolnou hodnotu, od bajtů po petabajty. Situace je zde stejná jako u CPU – pokud zadáte požadavek na množství paměti, které překračuje velikost paměti na vašich uzlech, provedení tohoto modulu nebude naplánováno. Ale na rozdíl od prostředků CPU není paměť komprimována, protože neexistuje způsob, jak omezit její využití. Proto bude provádění kontejneru zastaveno, jakmile mu dojde paměť, která je mu přidělena.
Je důležité si uvědomit, že nemůžete konfigurovat požadavky, které překračují množství zdrojů, které mohou poskytnout vaše uzly. Specifikace sdílení pro virtuální počítače GKE najdete v odkazech pod tímto videem.
V ideálním světě by výchozí nastavení kontejneru stačilo k udržení hladkého chodu pracovních postupů. Ale skutečný svět takový není, lidé mohou snadno zapomenout upravit využití zdrojů nebo hackeři nastaví požadavky a limity, které přesahují skutečné možnosti infrastruktury. Chcete-li takovým scénářům předejít, můžete nakonfigurovat kvóty prostředků ResourceQuota a rozsahy LimitRange.
Jakmile je jmenný prostor vytvořen, lze je uzamknout pomocí kvót. Například, pokud máte jmenné prostory prod a dev, vzorec je takový, že neexistují vůbec žádné produkční kvóty a kvóty pro vývoj jsou velmi přísné. To umožňuje produktu využít všechny dostupné zdroje v případě prudkého nárůstu provozu a zcela zablokovat vývoj.
Kvóta zdrojů může vypadat takto. V tomto příkladu jsou 4 sekce – to jsou 4 spodní řádky kódu.
Podívejme se na každou z nich. Requests.cpu je maximální počet kombinovaných požadavků na výkon CPU, které mohou pocházet ze všech kontejnerů jmenného prostoru. V tomto příkladu můžete mít 50 kontejnerů s 10 mil. požadavky, pět kontejnerů se 100 mil. požadavky nebo pouze jeden kontejner s 500 mil. požadavky. Dokud bude celkový počet request.cpu daného jmenného prostoru menší než 500 m, bude vše v pořádku.
Requested memory requirements.memory je maximální množství kombinovaných požadavků na paměť, které mohou mít všechny kontejnery v oboru názvů. Stejně jako v předchozím případě můžete mít 50 kontejnerů 2 mib, pět kontejnerů 20 mib nebo jeden kontejner 100 mib, pokud je celkové množství paměti požadované ve jmenném prostoru menší než 100 mebibajtů.
Limits.cpu je maximální kombinované množství výkonu procesoru, které mohou využívat všechny kontejnery jmenného prostoru. Můžeme předpokládat, že jde o limit požadavků na výkon procesoru.
A konečně, limity.paměť je maximální množství sdílené paměti, kterou mohou používat všechny kontejnery v jmenném prostoru. Toto je limit celkových požadavků na paměť.
Ve výchozím nastavení tedy kontejnery v clusteru Kubernetes běží s neomezenými výpočetními prostředky. Pomocí kvót prostředků mohou správci clusteru omezit spotřebu prostředků a vytváření prostředků na základě jmenného prostoru. Ve jmenném prostoru může pod nebo kontejner spotřebovat tolik výkonu CPU a paměti, jak je definováno kvótou prostředků jmenného prostoru. Existuje však obava, že jeden modul nebo kontejner může monopolizovat všechny dostupné zdroje. Aby se této situaci zabránilo, používá se limit Range - politika pro omezení alokace zdrojů (pro pody nebo kontejnery) ve jmenném prostoru.
Limitní rozsah poskytuje limity, 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 Starage pro každý PersistentVolumeClaim ve jmenném prostoru;
- vynutit vztah mezi Požadavkem a Limitem pro zdroj ve jmenném prostoru;
- nastavit výchozí požadavky/limity pro výpočetní zdroje ve jmenném prostoru a automaticky je vložit do kontejnerů za běhu.
Takže můžete vytvořit limitní rozsah ve svém jmenném prostoru. Na rozdíl od kvóty, která platí pro celý jmenný prostor, se Limitní rozsah používá pro jednotlivé kontejnery. To může uživatelům zabránit ve vytváření malých nebo obřích kontejnerů v rámci jmenného prostoru. Limitní rozsah může vypadat takto.
Stejně jako v předchozím případě zde lze rozlišit 4 sekce. Pojďme se na každý podívat.
Výchozí sekce nastavuje výchozí omezení pro kontejner v podu. Pokud nastavíte tyto hodnoty v extrémním rozsahu, pak všechny kontejnery, pro které tyto hodnoty nebyly explicitně nastaveny, budou následovat výchozí hodnoty.
V sekci defaultRequest jsou pro kontejner v podu nakonfigurovány výchozí požadavky. Opět, pokud nastavíte tyto hodnoty na extrémní rozsah, pak všechny kontejnery, pro které nejsou tyto parametry explicitně nastaveny, budou tyto hodnoty standardně používat.
Část max určuje maximální limity, které lze nastavit pro kontejner v podu. Hodnoty ve výchozí sekci a limity kontejneru nelze nastavit nad tento limit. Je důležité si uvědomit, že pokud je nastaveno max a neexistuje žádná výchozí sekce, pak se maximální hodnota stane výchozí hodnotou.
Část min určuje minimální požadavky, které lze nastavit pro kontejner v podu. Hodnoty ve výchozí sekci a požadavky na kontejner však nelze nastavit pod tento limit.
Opět je důležité poznamenat, že pokud je tato hodnota nastavena a výchozí není, pak se minimální hodnota stane výchozím dotazem.
Nakonec tyto požadavky na prostředky používá plánovač Kubernetes k provádění vašich úloh. Abyste mohli své kontejnery správně nastavit, je velmi důležité pochopit, jak to funguje. Řekněme, že chcete v clusteru spustit více modulů. Za předpokladu, že jsou specifikace podu platné, plán Kubernetes použije kruhový způsob k výběru uzlu pro spuštění úlohy.
Kubernetes zkontroluje, zda má uzel 1 dostatek zdrojů ke splnění požadavků kontejnerů pod, a pokud ne, přejde na další uzel. Pokud žádný z uzlů v systému není schopen uspokojit požadavky, moduly přejdou do stavu Nevyřízeno. Pomocí funkcí enginu Google Kubernetes, jako je automatické škálování uzlů, může GKE automaticky detekovat nevyřízený stav a vytvořit několik dalších uzlů.
Pokud později dojde k nadměrné kapacitě uzlů, automatické škálování sníží počet uzlů, abyste ušetřili peníze. To je důvod, proč Kubernetes naplánuje Pody na základě požadavků. Limit však může být vyšší než požadavky a v některých případech může hostiteli skutečně docházet zdroje. Tento stav nazýváme stavem nadměrného závazku.
Jak jsem řekl, pokud jde o CPU, Kubernetes začne omezovat Pody. Každý modul dostane tolik, o kolik požádal, ale pokud nedosáhne limitu, začne platit omezení.
Pokud jde o paměťové prostředky, zde musí Kubernetes rozhodovat o tom, které moduly smazat a které si ponechat, dokud neuvolníte systémové prostředky, jinak se celý systém zhroutí.
Představme si scénář, kdy máte stroj bez paměti – jak by to Kubernetes zvládl?
Kubernetes vyhledá Pody, které využívají více zdrojů, než bylo požadováno. Pokud tedy vaše kontejnery požadavky vůbec nemají, znamená to, že ve výchozím nastavení používají více, než o co požádaly, jednoduše proto, že nepožadovaly vůbec nic! Takové kontejnery se stávají hlavními kandidáty na odstavení. Dalšími kandidáty jsou kontejnery, které splnily všechny jejich požadavky, ale stále jsou pod maximálním limitem.
Pokud tedy Kubernetes najde několik podů, které překročily své parametry požadavku, seřadí je podle priority a poté odstraní pody s nejnižší prioritou. Pokud mají všechny pody stejnou prioritu, Kubernetes vypne ty pody, které překročily své požadavky o více než ostatní pody.
Ve velmi vzácných případech může Kubernetes ukončit Pody, které jsou stále v rámci jejich požadavků. To se může stát, když kritické systémové komponenty, jako je Kubelet agent nebo Docker, začnou spotřebovávat více zdrojů, než pro ně bylo vyhrazeno.
Takže v raných fázích malých podniků může cluster Kubernetes fungovat dobře bez nastavování požadavků na zdroje a limitů, ale jak se vaše týmy a projekty začnou zvětšovat, riskujete, že v této oblasti narazíte na problémy. Přidání dotazů a omezení do vašich modulů a jmenných prostorů vyžaduje velmi málo úsilí navíc a může vám ušetřit spoustu potíží.
Nějaké inzeráty 🙂
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ého obsahu? Podpořte nás objednávkou nebo doporučením přátelům, , jedinečný analog serverů základní úrovně, který jsme pro vás vymysleli: (k dispozici s RAID1 a RAID10, až 24 jader a až 40 GB DDR4).
Dell R730xd 2krát levnější v datovém centru Equinix Tier IV v Amsterdamu? Pouze zde V Nizozemsku! Dell R420 – 2x E5-2430 2.2 GHz 6C 128 GB DDR3 2 x 960 GB SSD 1 Gb/s 100 TB – od 99 $! Číst o
Zdroj: www.habr.com