Při vytváření clusteru Kubernetes mohou vyvstat otázky: kolik pracovních uzlů nakonfigurovat a jaký typ? Co je lepší pro on-premise cluster: koupit několik výkonných serverů nebo použít tucet starých strojů ve vašem datovém centru? Je lepší vzít osm jednojádrových nebo dvě čtyřjádrové instance v cloudu?
Odpovědi na tyto otázky jsou v článku. v překladu příkazu .
Kapacita clusteru
Obecně lze cluster Kubernetes považovat za velký „supernode“. Jeho celkový výpočetní výkon je součtem mocnin všech jeho uzlů.
Existuje několik způsobů, jak dosáhnout požadovaného cíle kapacity clusteru. Například potřebujeme cluster s celkovou kapacitou 8 procesorových jader a 32 GB RAM, protože sada aplikací vyžaduje tolik zdrojů. Pak můžete nainstalovat dva uzly s pamětí 16 GB nebo čtyři uzly s pamětí 8 GB, dva čtyřjádrové procesory nebo čtyři dvoujádrové.
Zde jsou pouze dva možné způsoby, jak vytvořit cluster:
Obě možnosti vytvářejí cluster se stejnou kapacitou, ale spodní konfigurace má čtyři menší uzly a horní konfigurace má dva větší uzly.
Která je nejlepší volba?
Abychom na tuto otázku odpověděli, podívejme se na výhody obou možností. Shrnuli jsme je do tabulky.
Několik velkých uzlů
Mnoho malých uzlů
Jednodušší správa clusteru (pokud je on-premise)
Plynulé automatické škálování
Levnější (pokud je na místě)
Cena je trochu jiná (v cloudu)
Může spouštět aplikace náročné na zdroje
Plná replikace
Prostředky jsou využívány efektivněji (méně režie na systémových démonech
Vyšší odolnost proti chybám clusteru
Upozorňujeme, že mluvíme pouze o pracovních uzlech. Volba počtu a velikosti hlavních uzlů je úplně jiné téma.
Pojďme si tedy probrat každý bod z tabulky podrobněji.
První možnost: několik velkých uzlů
Nejextrémnější možností je jeden pracovní uzel pro celou kapacitu clusteru. Ve výše uvedeném příkladu by se jednalo o jeden pracovní uzel s 16 jádry CPU a 16 GB RAM.
Pros
Plus č. 1. Jednodušší správa
Je snazší spravovat několik strojů než celý vozový park. Je rychlejší zavádět aktualizace a opravy a je snazší synchronizovat. Menší je i počet poruch v absolutních číslech.
Vezměte prosím na vědomí, že vše výše uvedené platí pro váš hardware, vaše servery, nikoli pro cloudové instance.
V cloudu je situace jiná. Tam se o správu stará poskytovatel cloudových služeb. Správa deseti uzlů v cloudu se tedy příliš neliší od správy jednoho uzlu.
Směrování provozu a rozložení zátěže mezi moduly v cloudu : provoz přicházející z internetu je odesílán do hlavního nástroje pro vyrovnávání zatížení, který přesměruje provoz na port jednoho z uzlů (služba NodePort nastavuje port v rozsahu 30000-32767 v každém uzlu clusteru). Pravidla nastavená kube-proxy přesměrovávají provoz z uzlu na pod. Takto to vypadá pro deset modulů na dvou uzlech:
Pro #2: Nižší náklady na uzel
Výkonné auto je dražší, ale nárůst ceny nemusí být nutně lineární. Jinými slovy, jeden desetijádrový server s 10 GB paměti je obvykle levnější než deset jednojádrových serverů se stejným množstvím paměti.
Všimněte si však, že toto pravidlo obvykle nefunguje v cloudových službách. V současných cenových schématech všech hlavních cloudových poskytovatelů ceny rostou lineárně s kapacitou.
V cloudu tak většinou nelze ušetřit na výkonnějších serverech.
Pro #3: Můžete spouštět aplikace náročné na zdroje
Některé aplikace vyžadují výkonné servery v clusteru. Pokud například systém strojového učení vyžaduje 8 GB paměti, nebudete jej moci provozovat na 1 GB uzlech, ale pouze s alespoň jedním velkým pracovním uzlem.
Zápory
Nevýhoda č. 1. Mnoho lusků na uzel
Pokud je stejný úkol proveden na méně uzlech, pak každý z nich bude mít přirozeně více podů.
To může být problém.
Důvodem je, že každý modul zavádí určitou režii do běhového prostředí kontejneru (např. Docker), stejně jako do kubelet a cAdvisor.
Například kubelet pravidelně testuje všechny kontejnery na uzlu na přežití – čím více kontejnerů, tím více práce musí kubelet udělat.
CAdvisor shromažďuje statistiky využití zdrojů pro všechny kontejnery v uzlu a kubelet tyto informace pravidelně zjišťuje a poskytuje je prostřednictvím rozhraní API. Opět více kontejnerů znamená více práce pro cAdvisor i kubelet.
Pokud se počet modulů zvýší, může to zpomalit systém a dokonce podkopat jeho spolehlivost.
V úložišti Kubernetes některé že uzly přeskakují mezi stavy Ready/NotReady, protože pravidelné kontroly kubelet všech kontejnerů v uzlu trvají příliš dlouho.
Z tohoto důvodu Kubernetes . V závislosti na výkonu uzlu můžete spustit více modulů na uzel, ale je těžké předvídat, zda nastanou problémy nebo bude vše fungovat dobře. Vyplatí se práci předem vyzkoušet.
Nevýhoda č. 2. Omezení replikace
Příliš málo uzlů omezuje efektivní rozsah replikace aplikací. Máte-li například aplikaci s vysokou dostupností s pěti replikami, ale pouze dvěma uzly, pak se efektivní stupeň replikace aplikace sníží na dva.
Pět replik lze distribuovat pouze mezi dva uzly, a pokud jeden z nich selže, odstraní více replik najednou.
Pokud máte pět nebo více uzlů, každá replika poběží na samostatném uzlu a selhání jednoho uzlu odstraní maximálně jednu repliku.
Požadavky na vysokou dostupnost tedy mohou vyžadovat určitý minimální počet uzlů v clusteru.
Nevýhoda č. 3. Horší následky selhání
S malým počtem uzlů má každá porucha vážnější následky. Pokud máte například pouze dva uzly a jeden z nich selže, polovina vašich modulů okamžitě zmizí.
Kubernetes samozřejmě migruje zátěž z neúspěšného uzlu na ostatní. Pokud jich je ale málo, pak nemusí být dostatek volné kapacity. V důsledku toho budou některé vaše aplikace nedostupné, dokud nevyvoláte neúspěšný uzel.
Čím více uzlů, tím menší dopad selhání hardwaru.
Nevýhoda č. 4: Více kroků automatického škálování
Kubernetes má systém automatického škálování clusteru pro cloudovou infrastrukturu, který vám umožňuje automaticky přidávat nebo odebírat uzly v závislosti na vašich aktuálních potřebách. S většími uzly se automatické škálování stává prudší a neohrabanější. Například na dvou uzlech přidání dalšího uzlu okamžitě zvýší kapacitu clusteru o 50 %. A za tyto zdroje budete muset zaplatit, i když je nepotřebujete.
Pokud tedy plánujete používat automatické škálování clusteru, čím menší jsou uzly, tím flexibilnější a nákladově efektivnější škálování získáte.
Nyní se podívejme na výhody a nevýhody velkého počtu malých uzlů.
Druhá možnost: mnoho malých uzlů
Výhody tohoto přístupu v podstatě vyplývají z nevýhod opačné varianty s několika velkými uzly.
Pros
Pro #1: Menší dopad selhání
Čím více uzlů, tím méně podů na každém uzlu. Pokud máte například sto modulů na deset uzlů, pak každý uzel bude mít v průměru deset modulů.
Pokud tedy jeden z uzlů selže, ztratíte pouze 10 % zátěže. Je pravděpodobné, že bude ovlivněn pouze malý počet replik a celková aplikace zůstane funkční.
Zbývající uzly budou mít navíc pravděpodobně dostatek volných zdrojů, aby zvládly zátěž neúspěšného uzlu, takže Kubernetes může libovolně přeplánovat pody a vaše aplikace se relativně rychle vrátí do funkčního stavu.
Pro #2: Dobrá replikace
Pokud je dostatek uzlů, plánovač Kubernetes může všem replikám přiřadit různé uzly. Tímto způsobem, pokud uzel selže, bude ovlivněna pouze jedna replika a aplikace zůstane dostupná.
Zápory
Nevýhoda č. 1. Náročné na ovládání
Velké množství uzlů je obtížnější spravovat. Například každý uzel Kubernetes musí komunikovat se všemi ostatními, to znamená, že počet připojení roste kvadraticky a všechna tato připojení je třeba sledovat.
Řadič uzlů v Kubernetes Controller Manager pravidelně prochází všemi uzly v clusteru, aby zkontroloval stav – čím více uzlů, tím větší zatížení řadiče.
Roste také zatížení databáze etcd – volání každého kubeletu a kube-proxy pro etcd (prostřednictvím API), do kterého má etcd vysílat aktualizace objektů.
Obecně platí, že každý pracovní uzel vytváří dodatečné zatížení na systémové komponenty hlavních uzlů.
Kubernetes oficiálně podporuje clustery s . V praxi je však již 500 uzlů .
Chcete-li spravovat velký počet pracovních uzlů, měli byste zvolit výkonnější hlavní uzly. Například kube-up správnou velikost virtuálního počítače pro hlavní uzel v závislosti na počtu pracovních uzlů. To znamená, že čím více pracovních uzlů, tím produktivnější by měly být hlavní uzly.
K řešení těchto specifických problémů existují speciální vývojové postupy, jako je např . Tento systém umožňuje obejít omezení a vytvořit clustery s velkým počtem pracovních uzlů.
Nevýhoda č. 2: Vyšší režijní náklady.
Na každém pracovním uzlu spouští Kubernetes sadu systémových démonů – mezi ně patří runtime kontejneru (jako je Docker), kube-proxy a kubelet, včetně cAdvisor. Společně spotřebovávají určité fixní množství zdrojů.
Pokud máte mnoho malých uzlů, podíl této režie na každém uzlu je větší. Představte si například, že všichni systémoví démoni na jednom uzlu společně využívají 0,1 jádra CPU a 0,1 GB paměti. Pokud máte jeden desetijádrový uzel s 10 GB paměti, pak démoni spotřebují 1 % kapacity clusteru. Na druhou stranu na deseti jednojádrových nodech s 1 GB paměti si démoni vezmou 10 % kapacity clusteru.
Tedy čím méně uzlů, tím efektivněji je infrastruktura využívána.
Nevýhoda č. 3. Neefektivní využívání zdrojů
Na malých uzlech se může stát, že zbývající části prostředků jsou příliš malé na to, aby jim bylo možné přiřadit jakoukoli pracovní zátěž, takže zůstanou nevyužity.
Například každý modul vyžaduje 0,75 GB paměti. Pokud máte deset uzlů, každý s 1 GB paměti, můžete spustit deset modulů, přičemž každému uzlu zůstane 0,25 GB nevyužité paměti.
To znamená, že 25 % paměti celého clusteru je promarněno.
Na velkém uzlu s 10 GB paměti můžete spustit 13 těchto modulů – a zbude jen jeden nevyužitý fragment o velikosti 0,25 GB.
V tomto případě je promarněno pouze 2,5 % paměti.
Na větších uzlech jsou tedy zdroje využívány optimálněji.
Několik velkých uzlů nebo mnoho malých?
Co je tedy lepší: několik velkých uzlů ve shluku nebo mnoho malých? Jako vždy neexistuje jednoznačná odpověď. Hodně záleží na typu aplikace.
Pokud například aplikace vyžaduje 10 GB paměti, větší uzly jsou jasnou volbou. A pokud aplikace vyžaduje desetinásobnou replikaci pro vysokou dostupnost, sotva se vyplatí riskovat umístění replik jen na dva uzly – v clusteru musí být minimálně deset uzlů.
V přechodných situacích proveďte výběr na základě výhod a nevýhod každé možnosti. Možná jsou některé argumenty pro vaši situaci relevantnější než jiné.
A není vůbec nutné, aby byly všechny uzly stejně velké. Nic vám nebrání nejprve experimentovat s uzly stejné velikosti, poté k nim přidat uzly jiné velikosti a zkombinovat je do shluku. Pracovní uzly v clusteru Kubernetes mohou být zcela heterogenní. Můžete tedy zkusit spojit výhody obou přístupů.
Neexistuje jediný recept a každá situace má své vlastní nuance a pouze výroba ukáže pravdu.
Překlad připravil tým cloudové platformy .
Více o Kubernetes: .
Zdroj: www.habr.com