Při vytváření Kubernetes clusteru se mohou vyskytovat otázky: kolik pracovních uzlů nastavit a jakého typu? Co je lepší pro on-premise cluster: koupit několik výkonných serverů, nebo zapojit desítku starých strojů ve vašem datovém centru? A v cloudu je lepší vzít osm jednoprocesorových nebo dva čtyřjádrové instance?
Odpovědi na tyto otázky naleznete v článku v překladu týmu .
Kapacita clusteru
Obecně se dá Kubernetes cluster považovat za velký "superuzel". Jeho celkový výpočetní výkon je součtem výkonů všech jednotlivých uzlů.
Existuje několik způsobů, jak dosáhnout požadované cílové 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ů. Potom je možné nastavit dva uzly s 16 GB paměti nebo čtyři uzly s 8 GB paměti, dva čtyřjádrové procesory nebo čtyři dvoujádrové.
Toto jsou pouze dva možné způsoby vytvoření clusteru:
Obě možnosti poskytují cluster se stejnou kapacitou, ale v dolní konfiguraci jsou čtyři menší uzly, zatímco v horní konfiguraci jsou dva větší.
Která varianta je lepší?
Abychom na tuto otázku odpověděli, podívejme se na výhody obou možností. Sepsali 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 on-premise)
Cena je velmi podobná (v cloudu)
Možnost spouštět náročné aplikace
Plnohodnotná replikace
Zdroje jsou efektivněji využívány (nižší režie na systémové démony)
Vyšší odolnost clusteru proti poruchám
Všimněte si, že se bavíme pouze o pracovních uzlech. Výběr počtu a velikosti hlavních uzlů je zcela jiné téma.
Pojďme se podívat podrobněji na každý bod z tabulky.
První varianta: několik velkých uzlů
Nejextrémnější varianta — jeden pracovní uzel na celou kapacitu clusteru. V uvedeném příkladu by to byl jeden pracovní uzel se 16 jádry CPU a 16 GB RAM.
Výhody
Plus číslo 1. Snadnější správa
Je snazší spravovat několik strojů než celý park. Aktualizace a opravy se aplikují rychleji a synchronizace je jednodušší. Absolutní čísla výpadků jsou také nižší.
Vezměte prosím na vědomí, že vše výše uvedené se vztahuje na vlastní hardware, vlastní servery, a nikoli na cloudové instance.
Ve cloudu je situace jiná. O správu se stará poskytovatel cloudových služeb. Tím pádem správa deseti uzlů v cloudu se od správy jednoho uzlu příliš neliší.
Směrování provozu a rozdělování zátěže mezi pody v cloudu : příchozí provoz z internetu je směrován na hlavní vyvážeč zátěže, který směruje provoz na port jednoho z uzlů (služba NodePort vystavuje port v rozmezí 30000-32767 na každém uzlu clusteru). Pravidla stanovená kube-proxy přesměrovávají provoz z uzlu na pod. Takto to vypadá pro deset podů na dvou uzlech:
Plus číslo 2. Nižší náklady na uzel
Výkonnější stroj je dražší, ale nárůst ceny není nutně lineární. Jinými slovy, jeden deseti jádrový server s 10 GB paměti je obvykle levnější než deset jednojádrových s tím stejným množstvím paměti.
Ale vezměte prosím na vědomí, že toto pravidlo obvykle neplatí u cloudových služeb. V aktuálních cenových modelech všech hlavních poskytovatelů cloudových služeb se ceny linearizují s rostoucí kapacitou.
Tím pádem ve cloudu obvykle nelze ušetřit na výkonnějších serverech.
Plus číslo 3. Můžete spouštět náročné aplikace
Některým aplikacím jsou zapotřebí výkonné servery v clusteru. Například, pokud systém strojového učení vyžaduje 8 GB paměti, nebudete jej moci spustit na uzlech s 1 GB, ale pouze při existenci alespoň jednoho velkého pracovního uzlu.
Nevýhody
Minus číslo 1. Hodně podů na uzel
Pokud je stejný úkol vykonáván na menším počtu uzlů, bude na každém z nich přirozeně více podů.
To může být problém.
Důvodem je, že každý modul přináší určité režijní náklady na prostředí kontejneru (např. Docker), stejně jako kubelet a cAdvisor.
Například kubelet pravidelně kontroluje životnost všech kontejnerů na uzlu — čím více kontejnerů, tím více práce má kubelet.
CAdvisor shromažďuje statistiky o využívání zdrojů všech kontejnerů na uzlu a kubelet pravidelně vyžaduje tyto informace a poskytuje je prostřednictvím API. Znovu, čím více kontejnerů, tím více práce pro cAdvisor i kubelet.
Pokud se počet modulů zvýší, může to zpomalit systém a dokonce ohrozit jeho spolehlivost.
V repozitáři Kubernetes někteří , že uzly skáčou mezi stavy Ready/NotReady, protože pravidelné kontroly kubeletu všech kontejnerů na uzlu trvají příliš dlouho.
Z tohoto důvodu Kubernetes . V závislosti na výkonu uzlu můžete na uzlu provozovat více podů, ale je těžké předpovědět, zda se objeví problémy, nebo zda vše bude fungovat dobře. Je dobré to nejprve otestovat.
Nevýhoda č. 2. Omezení replikace
Příliš malé množství uzlů omezuje efektivní míru replikace aplikací. Například, pokud máte vysoce dostupnou aplikaci s pěti replikami, ale pouze dva uzly, efektivní míra replikace aplikace se snižuje na dvě.
Pět replik lze rozdělit pouze na dva uzly, a pokud jeden z nich selže, okamžitě vyřadí několik replik.
Pokud máte pět uzlů nebo více, každá replikace bude běžet na samostatném uzlu a selhání jednoho uzlu odstraní nejvýše jednu repliku.
Tímto způsobem mohou požadavky na vysokou dostupnost vyžadovat určité minimální množství uzlů v klastru.
Nevýhoda č. 3. Horší následky selhání
Při malém počtu uzlů nese každé selhání závažnější důsledky. Například, pokud máte pouze dva uzly a jeden z nich selže, okamžitě zmizí polovina vašich modulů.
Samozřejmě, Kubernetes přesune pracovní zátěž ze selhávajícího uzlu na jiné. Ale pokud jich je málo, volné kapacity nemusí být dost. V důsledku toho bude část vašich aplikací nedostupná, dokud nezvednete selhávající uzel.
Tímto způsobem, čím více uzlů, tím menší dopad hardwarových selhání.
Nevýhoda č. 4. Větší kroky automatického škálování
V Kubernetes funguje systém automatického škálování cloudu, který umožňuje automaticky přidávat nebo odstraňovat uzly podle aktuálních potřeb. U větších uzlů se škálování stává razantnějším a neohrabaným. Například přidání dalšího uzlu na dvou uzlech okamžitě zvýší kapacitu cloudu o 50 %. A za tyto zdroje budete muset zaplatit, i když je nepotřebujete.
Pokud tedy plánujete využít automatické škálování cloudu, tím menší uzly budou, tím flexibilnější a ekonomičtější škálování získáte.
Nyní se podívejme na výhody a nevýhody velkého množství malých uzlů.
Druhá možnost: množství malých uzlů
Výhody tohoto přístupu v zásadě vyplývají z nevýhod opačné varianty se několika velkými uzly.
Výhody
Plus č. 1. Menší dopad na selhání
Čím více uzlů, tím méně podů na každém uzlu. Například pokud máte sto modulů na deseti uzlech, na každém uzlu bude průměrně deset modulů.
Pokud tedy jeden z uzlů selže, ztrácíte pouze 10 % pracovní zátěže. Existuje pravděpodobnost, že bude zasazena jen malá část replik a aplikace zůstanou funkční.
Kromě toho je pravděpodobné, že na zbývajících uzlech bude dostatek volných zdrojů pro pracovní zátěž selhávajícího uzlu, takže Kubernetes může svobodně přeplánovat pody a vaše aplikace se relativně rychle vrátí do funkčního stavu.
Plus č. 2. Dobrá replikace
Pokud je uzlů dostatek, může plánovač Kubernetes přiřadit všem replikám různé uzly. Takže v případě selhání uzlu bude zasazena pouze jedna replikace, a aplikace zůstane dostupná.
Nevýhody
Minus č. 1. Obtížnější správa
S větším počtem uzlů je obtížnější správa. Například každý uzel Kubernetes musí komunikovat se všemi ostatními, tedy počet vztahů roste kvadraticky a všechny tyto vztahy je třeba sledovat.
Kontrolér uzlů v řídicím správci Kubernetes pravidelně prochází všechny uzly v cloudu, aby zkontroloval jejich funkčnost — čím více uzlů, tím větší zátěž na kontrolér.
Zatížení roste také na databázi etcd — každý kubelet a kube-proxy volá pro etcd (přes API), který musí etcd přenášet aktualizace objektu.
Celkově každý pracovní uzel vytváří dodatečnou zátěž pro systémové komponenty hlavních uzlů.
Oficiálně Kubernetes podporuje clustery s . V praxi však již 500 uzlů .
Pro správu velkého počtu pracovních uzlů byste měli zvolit výkonnější hlavní uzly. Například kube-up odpovídající velikost VM pro hlavní uzel v závislosti na počtu pracovních uzlů. To znamená, že čím více pracovních uzlů, tím výkonnější by měly být hlavní uzly.
Pro řešení těchto specifických problémů existují speciální vývojové projekty, jako je . Tento systém umožňuje obejít omezení a vytvářet clustery s obrovským počtem pracovních uzlů.
Nevýhoda č. 2. Větší režijní náklady
Na každém pracovním uzlu Kubernetes běží sada systémových démonů — mezi ně patří runtime kontejneru (např. Docker), kube-proxy a kubelet, včetně cAdvisor. Všechny dohromady spotřebovávají určité pevné množství zdrojů.
Pokud máte mnoho malých uzlů, podíl těchto režijních nákladů na každém uzlu je větší. Například si představte, že všechny systémové démony jednoho uzlu společně používají 0,1 jádra CPU a 0,1 GB paměti. Pokud máte jeden deseti jádrový uzel s 10 GB paměti, pak démoni spotřebovávají 1% kapacity clusteru. Na druhé straně na deseti jedno jádrových uzlech s 1 GB paměti si démoni vezmou 10% kapacity clusteru.
Tím pádem, čím méně uzlů, tím efektivněji se využívá infrastruktura.
Nevýhoda č. 3. Neefektivní využívání zdrojů
Na malých uzlech může nastat situace, že zbývající fragmenty zdrojů jsou příliš malé na to, aby se jim mohla přiřadit nějaká pracovní zátěž, a proto zůstávají nevyužity.
Například každý pod potřebuje 0,75 GB paměti. Pokud máte deset uzlů a každý má 1 GB paměti, můžete spustit deset podů — nakonec na každém uzlu zbude 0,25 GB nevyužité paměti.
To znamená, že 25% paměti celého clusteru se plýtvá.
Na velkém uzlu s 10 GB paměti můžete spustit 13 takových modulů — a zbude pouze jeden nevyužitý fragment 0,25 GB.
V tomto případě se plýtvá pouze 2,5% paměti.
Takže na velkých uzlech jsou zdroje efektivněji využívány.
Několik velkých uzlů nebo mnoho malých?
Co je tedy lepší: několik velkých uzlů v clusteru nebo mnoho malých? Odpověď není jednoznačná. Mnoho závisí na typu aplikace.
Například, pokud aplikace vyžaduje 10 GB paměti, je jasnou volbou big nodes. A pokud aplikace vyžaduje desetinásobnou replikaci pro vysokou dostupnost, určitě nemá smysl riskovat a umísťovat repliky jen na dvou uzlech — v clusteru by mělo být minimálně deset uzlů.
Ve středních situacích se rozhodněte na základě výhod a nevýhod každé varianty. Možná jsou některé argumenty pro vaši situaci relevantnější než jiné.
A rozhodně není nezbytné mít všechny uzly stejné velikosti. Nic nebrání experimentovat nejprve s uzly jedné velikosti a poté k nim přidat uzly jiné velikosti, kombinující je v clusteru. Pracovní uzly clusteru Kubernetes mohou být zcela heterogenní. Můžete tedy vyzkoušet výhody obou přístupů.
Neexistuje žádný univerzální recept, každá situace má své nuance a pouze produkční prostředí ukáže pravdu.
Překlad připravila tým cloudové platformy .
Ještě více o Kubernetes: .
Zdroj: habr.com
