27. dubna na konferenci , v rámci sekce „DevOps“ byla vydána zpráva „Automatické škálování a správa zdrojů v Kubernetes“. Hovoří o tom, jak můžete pomocí K8 zajistit vysokou dostupnost vašich aplikací a zajistit špičkový výkon.
Tradičně rádi představujeme (44 minut, mnohem informativnější než článek) a hlavní shrnutí v textové podobě. Jít!
Rozeberme si téma reportáže slovo po slově a začněme od konce.
Kubernetes
Řekněme, že máme na hostiteli kontejnery Docker. Proč? Pro zajištění opakovatelnosti a izolace, což zase umožňuje jednoduché a dobré nasazení, CI/CD. Takových vozidel s kontejnery máme mnoho.
Co v tomto případě poskytuje Kubernetes?
- Přestáváme myslet na tyto stroje a začínáme pracovat s „cloudem“ shluk kontejnerů nebo lusky (skupiny nádob).
- Navíc ani nemyslíme na jednotlivé pody, ale spravujeme víceоvětší skupiny. Takový primitivové na vysoké úrovni dovolte nám říci, že existuje šablona pro spuštění určité zátěže a zde je požadovaný počet instancí pro její spuštění. Pokud následně změníme šablonu, změní se všechny instance.
- S deklarativní API Místo provádění sekvence konkrétních příkazů popisujeme „strukturu světa“ (v YAML), kterou vytváří Kubernetes. A znovu: když se změní popis, změní se i jeho skutečné zobrazení.
Управление ресурсами
procesor
Spusťte na serveru nginx, php-fpm a mysql. Tyto služby budou mít ve skutečnosti ještě více spuštěných procesů, z nichž každý vyžaduje výpočetní zdroje:
(čísla na snímku jsou „papoušci“, abstraktní potřeba každého procesu na výpočetní výkon)
Pro snazší práci s tím je logické spojovat procesy do skupin (například všechny procesy nginx do jedné skupiny „nginx“). Jednoduchý a zřejmý způsob, jak toho dosáhnout, je umístit každou skupinu do kontejneru:
Chcete-li pokračovat, musíte si zapamatovat, co je kontejner (v Linuxu). Jejich vzhled byl umožněn díky třem klíčovým funkcím v jádře, implementovaným před poměrně dlouhou dobou: , и . A další vývoj usnadnily další technologie (včetně pohodlných „skořápek“, jako je Docker):
V kontextu zprávy nás zajímá pouze skupiny, protože kontrolní skupiny jsou součástí funkčnosti kontejnerů (Docker atd.), která implementuje správu zdrojů. Procesy spojené do skupin, jak jsme chtěli, jsou kontrolní skupiny.
Vraťme se k požadavkům na CPU pro tyto procesy a nyní pro skupiny procesů:
(Opakuji, že všechna čísla jsou abstraktním vyjádřením potřeby zdrojů)
Přitom samotné CPU má určitý omezený zdroj (v příkladu je to 1000), která může každému chybět (součet potřeb všech skupin je 150+850+460=1460). Co se stane v tomto případě?
Jádro začne rozdělovat zdroje a dělá to „spravedlivě“, přičemž každé skupině dává stejné množství zdrojů. Ale v prvním případě je jich více, než je potřeba (333>150), takže přebytek (333-150=183) zůstává v záloze, který je také rovnoměrně rozdělen mezi dva další kontejnery:
Výsledkem bylo, že první kontejner měl dostatek zdrojů, druhý – neměl dostatek zdrojů, třetí – neměl dostatek zdrojů. Toto je výsledek akcí "poctivý" plánovač v Linuxu - . Jeho činnost lze upravit pomocí přiřazení závaží každý z kontejnerů. Například takto:
Podívejme se na případ nedostatku zdrojů v druhém kontejneru (php-fpm). Všechny prostředky kontejneru jsou rovnoměrně rozděleny mezi procesy. Výsledkem je, že hlavní proces funguje dobře, ale všichni pracovníci se zpomalí a dostanou méně než polovinu toho, co potřebují:
Takto funguje plánovač CFS. Dále budeme nazývat váhy, které kontejnerům přiřadíme žádosti. Proč tomu tak je - viz dále.
Podívejme se na celou situaci z druhé strany. Jak víte, všechny cesty vedou do Říma a v případě počítače k CPU. Jeden CPU, mnoho úkolů – potřebujete semafor. Nejjednodušší způsob, jak spravovat zdroje, je „semafor“: dali jednomu procesu pevný přístupový čas k CPU, pak dalšímu atd.
Tento přístup se nazývá tvrdé kvóty (tvrdé omezení). Pamatujme si to jednoduše jako limity. Pokud však rozdělíte limity na všechny kontejnery, nastává problém: mysql jel po silnici a v určitém okamžiku jeho potřeba CPU skončila, ale všechny ostatní procesy jsou nuceny čekat, až CPU líný.
Vraťme se k linuxovému jádru a jeho interakci s CPU – celkový obrázek je následující:
cgroup má dvě nastavení - v podstatě se jedná o dvě jednoduché "zvraty", které vám umožňují určit:
- hmotnost pro kontejner (požadavky) je sdílení;
- procento celkového času CPU pro práci na úlohách kontejneru (limity) je kvóta.
Jak měřit CPU?
Existují různé způsoby:
- Co je papoušci, nikdo neví – pokaždé je potřeba se domluvit.
- Zájem jasnější, ale relativní: 50 % serveru se 4 jádry a s 20 jádry jsou úplně jiné věci.
- Můžete použít již zmíněné závaží, které Linux zná, ale jsou také relativní.
- Nejvhodnější možností je měřit výpočetní zdroje v sekundy. Tito. v sekundách procesorového času ve vztahu k sekundám reálného času: 1 sekunda procesorového času byla dána za 1 skutečnou sekundu – to je jedno celé jádro CPU.
Aby bylo mluvení ještě jednodušší, začali měřit přímo dovnitř jádra, což jimi znamená stejný čas CPU vzhledem ke skutečnému. Vzhledem k tomu, že Linux rozumí vahám, ale ne tolik času procesoru/jádrům, bylo zapotřebí mechanismu pro překlad z jednoho do druhého.
Uvažujme jednoduchý příklad se serverem se 3 jádry CPU, kde třem podům budou přiděleny váhy (500, 1000 a 1500), které lze snadno převést na odpovídající části jader, která jim byla přidělena (0,5, 1 a 1,5).
Pokud vezmete druhý server, kde bude dvakrát tolik jader (6), a umístíte tam stejné pody, lze rozložení jader snadno vypočítat jednoduchým vynásobením 2 (1, 2 a 3). Důležitý moment ale nastává, když se na tomto serveru objeví čtvrtý modul, jehož hmotnost bude pro pohodlí 3000. Odebere část zdrojů CPU (polovinu jader) a pro zbývající moduly se přepočítávají (na polovinu):
Kubernetes a prostředky CPU
V Kubernetes se zdroje CPU obvykle měří v miliadrax, tj. Jako základní hmotnost se bere 0,001 jádra. (Totéž se v terminologii Linux/cgroups nazývá sdílení CPU, i když přesněji 1000 milicores = 1024 sdílení CPU.) K8s zajišťuje, že na server neumisťuje více modulů, než kolik je prostředků CPU pro součet vah všech modulů.
Jak se to stane? Když přidáte server do clusteru Kubernetes, bude hlášeno, kolik jader CPU má k dispozici. A při vytváření nového modulu plánovač Kubernetes ví, kolik jader bude tento modul potřebovat. Pod bude tedy přiřazena k serveru, kde je dostatek jader.
Co se stane, když ne je zadán požadavek (tj. modul nemá definovaný počet jader, která potřebuje)? Pojďme zjistit, jak Kubernetes obecně počítá zdroje.
Pro modul můžete zadat požadavky (plánovač CFS) i limity (pamatujete na semafor?):
- Pokud jsou zadány stejné, je podu přiřazena třída QoS garantováno. Tento počet jader, které má vždy k dispozici, je zaručen.
- Pokud je požadavek menší než limit - třída QoS prasklavý. Tito. Očekáváme, že například pod bude vždy používat 1 jádro, ale tato hodnota pro něj není omezení: někdy pod může využít více (pokud má server na to volné zdroje).
- Existuje také třída QoS nejlepší úsilí — zahrnuje právě ty lusky, pro které není požadavek specifikován. Prostředky se jim dávají jako poslední.
Vzpomínka
S pamětí je situace podobná, ale trochu jiná – ostatně povaha těchto zdrojů je jiná. Obecně platí, že analogie je následující:
Podívejme se, jak jsou požadavky implementovány v paměti. Nechte moduly žít na serveru a měňte spotřebu paměti, dokud se jeden z nich nezvětší natolik, že mu dojde paměť. V tomto případě se objeví zabiják OOM a zabije největší proces:
Ne vždy nám to vyhovuje, a tak je možné regulovat, které procesy jsou pro nás důležité a neměly by být zabity. K tomu použijte parametr oom_score_adj.
Vraťme se ke třídám QoS CPU a nakreslete analogii s hodnotami oom_score_adj, které určují priority spotřeby paměti pro moduly:
- Nejnižší hodnota oom_score_adj pro pod - -998 - znamená, že takový pod by měl být zabit jako poslední, garantováno.
- Nejvyšší - 1000 - je nejlepší úsilí, takové lusky jsou zabity jako první.
- Pro výpočet zbývajících hodnot (prasklavý) existuje vzorec, jehož podstata se scvrkává na skutečnost, že čím více zdrojů modul požaduje, tím menší je pravděpodobnost, že bude zabit.
Druhý "zákrut" - limit_in_bytes - pro limity. S ním je vše jednodušší: jednoduše přiřadíme maximální množství vydané paměti a zde (na rozdíl od CPU) není řeč o tom, jak ji (paměť) měřit.
Celkem
Každý modul v Kubernetes je dán requests и limits - oba parametry pro CPU a paměť:
- na základě požadavků funguje plánovač Kubernetes, který distribuuje pody mezi servery;
- na základě všech parametrů je určena třída QoS podu;
- Relativní váhy se vypočítávají na základě požadavků CPU;
- plánovač CFS je konfigurován na základě požadavků CPU;
- OOM zabiják je konfigurován na základě požadavků na paměť;
- „semafor“ je nakonfigurován na základě limitů CPU;
- Na základě limitů paměti je pro cgroup nakonfigurován limit.
Obecně platí, že tento obrázek odpovídá na všechny otázky o tom, jak probíhá hlavní část správy zdrojů v Kubernetes.
Automatické škálování
K8s cluster-autoscaler
Představme si, že celý cluster je již obsazen a je třeba vytvořit nový modul. I když se modul nemůže zobrazit, zůstává ve stavu Vyhledávání. Aby se objevil, můžeme ke clusteru připojit nový server nebo... nainstalovat cluster-autoscaler, který to udělá za nás: objednejte si virtuální stroj od poskytovatele cloudu (pomocí požadavku API) a připojte jej ke clusteru , načež se přidá lusk .
Jedná se o autoscaling clusteru Kubernetes, který funguje skvěle (podle našich zkušeností). Nicméně, stejně jako jinde, i zde existují určité nuance...
Dokud jsme zvětšili velikost clusteru, bylo vše v pořádku, ale co se stane, když cluster se začal osvobozovat? Problém je v tom, že migrace podů (pro uvolnění hostitelů) je velmi technicky náročná a nákladná z hlediska zdrojů. Kubernetes používá úplně jiný přístup.
Zvažte cluster 3 serverů, který má nasazení. Má 6 modulů: nyní jsou 2 pro každý server. Z nějakého důvodu jsme chtěli vypnout jeden ze serverů. K tomu použijeme příkaz kubectl drain, který:
- zakáže odesílání nových modulů na tento server;
- smaže existující moduly na serveru.
Vzhledem k tomu, že Kubernetes je zodpovědný za udržování počtu podů (6), je to jednoduše znovu vytvoří je na jiných uzlech, ale ne na tom, který je deaktivován, protože je již označen jako nedostupný pro hostování nových modulů. Toto je základní mechanika pro Kubernetes.
I zde však existuje nuance. V podobné situaci pro StatefulSet (místo Deployment) budou akce odlišné. Nyní již máme stavovou aplikaci – například tři moduly s MongoDB, z nichž jeden má nějaký problém (poškozená data nebo jiná chyba, která brání správnému spuštění modulu). A opět se rozhodneme deaktivovat jeden server. Co se bude dít?
MongoDB mohl zemřít, protože potřebuje kvorum: pro shluk tří instalací musí fungovat alespoň dvě. Nicméně, toto se neděje - díky PodDisruptionBudget. Tento parametr určuje minimální požadovaný počet pracovních modulů. Vědět, že jeden z modulů MongoDB již nefunguje, a vidět, že PodDisruptionBudget je nastaven pro MongoDB minAvailable: 2, Kubernetes vám nedovolí smazat pod.
Sečteno a podtrženo: aby pohyb (a vlastně i opětovné vytváření) podů po uvolnění clusteru fungoval správně, je nutné nakonfigurovat PodDisruptionBudget.
Horizontální škálování
Zvažme jinou situaci. V Kubernetes běží aplikace jako Deployment. Návštěvnost uživatelů přichází do jeho podů (například jsou tři) a měříme v nich určitý ukazatel (řekněme zatížení CPU). Když se zatížení zvýší, zaznamenáme to podle plánu a zvýšíme počet modulů pro distribuci požadavků.
Dnes to v Kubernetes není nutné provádět ručně: automatické zvýšení/snížení počtu podů je nakonfigurováno v závislosti na hodnotách naměřených indikátorů zatížení.
Hlavní otázky jsou zde: co přesně měřit и jak interpretovat získané hodnoty (pro rozhodnutí o změně počtu lusků). Můžete měřit hodně:
Jak to udělat technicky - sbírat metriky atd. — Podrobně jsem hovořil ve zprávě o . A hlavní rada pro výběr optimálních parametrů zní experiment!
K dispozici je (Sytost využití a chyby), jehož význam je následující. Na jakém základě má smysl škálovat např. php-fpm? Na základě skutečnosti, že pracovníci docházejí, je tomu tak využití. A pokud dělníci skončí a nová spojení nebudou přijata, už je to tak nasycení. Oba tyto parametry musí být měřeny a v závislosti na hodnotách musí být provedeno škálování.
Místo závěru
Zpráva má pokračování: o vertikálním škálování a jak vybrat správné zdroje. Budu o tom mluvit v budoucích videích - přihlaste se, ať vám nic neunikne!
Videa a diapozitivy
Video z představení (44 minut):
Prezentace zprávy:
PS
Další zprávy o Kubernetes na našem blogu:
- «» (Andrey Polovov; 8. dubna 2019 na Saint HighLoad++);
- «» (Dmitry Stolyarov; 8. listopadu 2018 na HighLoad++);
- «» (Dmitry Stolyarov; 28. května 2018 na RootConf);
- «» (Dmitry Stolyarov; 7. listopadu 2017 na HighLoad++);
- «» (Dmitry Stolyarov; 6. června 2017 na RootConf).
Zdroj: www.habr.com