Poznámka. přel.: tento materiál je ze vzdělávacího projektu - odpověď na oblíbenou otázku při navrhování infrastruktury založené na Kubernetes. Doufáme, že dostatečně podrobné popisy kladů a záporů každé z možností vám pomohou vybrat tu nejlepší volbu pro váš projekt.
TL, DR: stejnou sadu úloh lze spustit na několika velkých clusterech (každý cluster bude mít velký počet úloh) nebo na mnoha malých (s malým počtem úloh v každém clusteru).
Níže je uvedena tabulka, která hodnotí klady a zápory každého přístupu:
Při používání Kubernetes jako platformy pro spouštění aplikací se často objevuje několik zásadních otázek ohledně složitosti konfigurace clusterů:
- Kolik clusterů použít?
- Jak velké je udělat?
- Co by měl každý cluster obsahovat?
V tomto článku se pokusím odpovědět na všechny tyto otázky analýzou výhod a nevýhod každého přístupu.
Vyjádření otázky
Jako vývojář softwaru budete pravděpodobně vyvíjet a provozovat mnoho aplikací paralelně.
Navíc mnoho instancí těchto aplikací pravděpodobně poběží v různých prostředích – například to může být dev, test и prod.
Výsledkem je celá matice aplikací a prostředí:
Aplikace a prostředí
Ve výše uvedeném příkladu jsou 3 aplikace a 3 prostředí, což má za následek celkem 9 možných možností.
Každá instance aplikace je samostatná jednotka nasazení, se kterou můžete pracovat nezávisle na ostatních.
Vezměte prosím na vědomí, že instance aplikace se může skládat z mnoha komponentyjako je frontend, backend, databáze atd. V případě aplikace mikroslužby bude instance zahrnovat všechny mikroslužby.
V důsledku toho mají uživatelé Kubernetes několik otázek:
- Měly by být všechny instance aplikací hostovány ve stejném clusteru?
- Vyplatí se spustit samostatný cluster pro každou instanci aplikace?
- Nebo by se možná měla použít kombinace výše uvedených přístupů?
Všechny tyto možnosti jsou životaschopné, protože Kubernetes je flexibilní systém, který neomezuje možnosti uživatele.
Zde jsou některé z možných způsobů:
- jeden velký společný shluk;
- mnoho malých vysoce specializovaných klastrů;
- jeden cluster na aplikaci;
- jeden cluster na prostředí.
Jak je ukázáno níže, první dva přístupy jsou na opačných koncích škály možností:
Od několika velkých shluků (vlevo) po mnoho malých (vpravo)
Obecně se má za to, že jeden shluk je „větší“ než jiný, pokud má více než součet uzlů a podů. Například shluk s 10 uzly a 100 pody je větší než shluk s 1 uzlem a 10 pody.
No, pojďme začít!
1. Jeden velký sdílený cluster
První možností je umístit všechny úlohy do jednoho clusteru:
Jeden velký shluk
V rámci tohoto přístupu je cluster používán jako univerzální infrastrukturní platforma - jednoduše nasadíte vše, co potřebujete, do existujícího clusteru Kubernetes.
Kubernetes umožňuje logicky oddělit části clusteru od sebe, takže každá instance aplikace může používat svůj vlastní jmenný prostor.
Podívejme se na výhody a nevýhody tohoto přístupu.
+ Efektivní využití zdrojů
V případě jednoho clusteru bude potřeba pouze jedna kopie všech prostředků potřebných ke spuštění a správě clusteru Kubernetes.
To platí například pro hlavní uzly. Obvykle jsou 3 hlavní uzly na cluster Kubernetes, takže u jednoho clusteru jejich počet zůstane stejný (pro srovnání, 10 clusterů by potřebovalo 30 hlavních uzlů).
Výše uvedená jemnost platí také pro další služby, které fungují napříč celým clusterem, jako jsou load balancery, Ingress controllery, autentizační, logovací a monitorovací systémy.
V jednom clusteru lze všechny tyto služby využívat pro všechny zátěže najednou (není třeba vytvářet jejich kopie, jako v případě více clusterů).
+ levné
V důsledku výše uvedeného je méně klastrů obvykle levnějších, protože neexistují žádné náklady na přebytečné zdroje.
To platí zejména pro masternody, které mohou stát značné množství peněz, ať už jsou hostované on-premise nebo v cloudu.
Některé spravovaly služby Kubernetes jako např nebo , poskytují řídicí vrstvu zdarma. V tomto případě je otázka nákladů méně akutní.
Existují také spravované služby, které účtují fixní poplatek za provoz každého clusteru Kubernetes (např. ).
+ Efektivní administrativa
Je jednodušší spravovat jeden cluster než několik.
Administrace může zahrnovat následující úkoly:
- aktualizace verze Kubernetes;
- konfigurace potrubí CI/CD;
- instalace pluginu CNI;
- nastavení systému ověřování uživatelů;
- instalace řadiče vstupu;
a mnoho dalších…
V případě jednoho clusteru budete muset toto vše udělat pouze jednou.
U mnoha klastrů se budou muset operace mnohokrát opakovat, což bude pravděpodobně vyžadovat určitou automatizaci procesů a nástrojů pro zajištění systematického a jednotného procesu.
A teď pár slov o nevýhodách.
− Jediný bod selhání
V případě odmítnutí jediný clustery okamžitě přestanou fungovat vše pracovní zátěže!
Existuje mnoho možností, kdy se může něco pokazit:
- Upgrade Kubernetes vede k neočekávaným vedlejším účinkům
- komponenta pro celý cluster (například zásuvný modul CNI) nezačne fungovat podle očekávání;
- jedna ze součástí clusteru je nesprávně nakonfigurována;
- selhání v základní infrastruktuře.
Jeden takový incident může způsobit vážné poškození všech úloh hostovaných ve společném clusteru.
− Nedostatek pevné izolace
Spuštění ve sdíleném clusteru znamená, že aplikace sdílejí hardware, síťové možnosti a operační systém na uzlech clusteru.
V jistém smyslu jsou dva kontejnery se dvěma různými aplikacemi běžícími na stejném hostiteli jako dva procesy běžící na stejném počítači se stejným jádrem operačního systému.
Linuxové kontejnery poskytují určitou formu izolace, ale zdaleka není tak silná jako to, co poskytují například virtuální stroje. Proces v kontejneru je v podstatě stejný proces běžící na hostitelském operačním systému.
To může být bezpečnostní problém: tato organizace teoreticky umožňuje vzájemně nesouvisejícím aplikacím komunikovat (záměrně nebo náhodně).
Kromě toho všechny úlohy v clusteru Kubernetes sdílejí některé služby pro celý cluster, jako je např - to umožňuje aplikacím najít Služby jiných aplikací v clusteru.
Všechny výše uvedené body mohou mít různý význam v závislosti na požadavcích na zabezpečení aplikace.
Kubernetes poskytuje různé nástroje pro předcházení problémům se zabezpečením, jako je např и . Ke správné konfiguraci však vyžadují určité zkušenosti a nejsou schopny uzavřít absolutně všechny bezpečnostní díry.
Je důležité si vždy pamatovat, že Kubernetes byl původně navržen pro sdílení, ne pro izolace a bezpečí.
− Nedostatek tvrdého vícenásobného pronájmu
Vzhledem k množství sdílených zdrojů v clusteru Kubernetes existuje mnoho způsobů, jak si různé aplikace mohou navzájem šlápnout na nohy.
Aplikace může například monopolizovat sdílený prostředek (jako je procesor nebo paměť) a odepřít ostatním aplikacím běžícím na stejném hostiteli přístup k němu.
Kubernetes poskytuje různé mechanismy pro ovládání tohoto chování, jako např (viz také článek ""- Cca. překlad.), и . Stejně jako v případě bezpečnosti je však jejich konfigurace spíše netriviální a nedokážou zabránit absolutně všem nepředvídatelným vedlejším efektům.
− Velký počet uživatelů
V případě jednoho clusteru k němu musíte otevřít přístup mnoha lidem. A čím větší je jejich počet, tím vyšší je riziko, že něco „rozbijí“.
Uvnitř clusteru můžete ovládat, kdo s čím může dělat (viz článek""- Cca. překlad.). Nezabrání však uživatelům něco „rozbít“ v oblasti jejich odpovědnosti.
− Shluky nemohou růst donekonečna
Cluster, který se používá pro všechny úlohy, bude pravděpodobně poměrně velký (co do počtu uzlů a modulů).
Zde ale nastává další problém: clustery v Kubernetes nemohou růst donekonečna.
Existuje teoretický limit velikosti clusteru. V Kubernetes je to přibližně .
V reálném životě však mohou problémy začít mnohem dříve – například právě kdy .
Faktem je, že velké clustery velmi zatěžují řídicí vrstvu Kubernetes. Jinými slovy, k udržení efektivního provozu clusteru je nutné pečlivé vyladění.
Tento problém je prozkoumán v souvisejícím článku na původním blogu s názvem „".
Zvažme však opačný přístup: mnoho malých shluků.
2. Mnoho malých, specializovaných shluků
S tímto přístupem používáte samostatný cluster pro každou položku, kterou nasadíte:
Mnoho malých shluků
Pro účely tohoto článku pod rozmístitelný prvek je chápána jako instance aplikace - například dev verze samostatné aplikace.
V této strategii se Kubernetes používá jako specializovaný runtime pro jednotlivé instance aplikací.
Podívejme se na výhody a nevýhody tohoto přístupu.
+ Omezený "poloměr exploze"
Když se cluster "rozbije", negativní důsledky jsou omezeny pouze na ty úlohy, které byly nasazeny v tomto clusteru. Všechny ostatní úlohy zůstávají nedotčeny.
+ Izolace
Pracovní zátěže hostované v jednotlivých clusterech nesdílejí společné prostředky, jako je procesor, paměť, operační systém, síť nebo jiné služby.
Výsledkem je silná izolace mezi nesouvisejícími aplikacemi, což může být výhodné pro jejich bezpečnost.
+ Malý počet uživatelů
Vzhledem k tomu, že každý cluster obsahuje pouze omezenou sadu úloh, je počet uživatelů s přístupem k němu snížen.
Čím méně lidí má do clusteru přístup, tím menší je riziko, že se něco „rozbije“.
Podívejme se na nevýhody.
− Neefektivní využívání zdrojů
Jak již bylo zmíněno dříve, každý cluster Kubernetes vyžaduje určitou sadu prostředků pro správu: hlavní uzly, komponenty řídicí vrstvy, řešení pro monitorování a protokolování.
V případě velkého počtu malých klastrů musí být na management alokován větší podíl zdrojů.
− Drahé
Neefektivní využívání zdrojů s sebou automaticky nese vysoké náklady.
Například udržování 30 masternodů místo tří se stejným výpočetním výkonem rozhodně ovlivní náklady.
− Potíže s administrací
Správa více clusterů Kubernetes je mnohem obtížnější než správa jednoho.
Například budete muset nakonfigurovat ověřování a autorizaci pro každý cluster. Upgrade verze Kubernetes bude také nutné provést několikrát.
S největší pravděpodobností budete muset použít automatizaci, abyste zvýšili efektivitu všech těchto úkolů.
Nyní zvažte méně extrémní scénáře.
3. Jeden cluster na aplikaci
Pomocí tohoto přístupu vytvoříte samostatný cluster pro všechny instance konkrétní aplikace:
Cluster na aplikaci
Tento způsob lze považovat za zobecnění principu „samostatný cluster na tým”, protože na vývoji jedné nebo více aplikací se obvykle podílí tým inženýrů.
Podívejme se na výhody a nevýhody tohoto přístupu.
+ Cluster lze přizpůsobit aplikaci
Pokud má aplikace speciální potřeby, lze je implementovat v clusteru, aniž by to ovlivnilo ostatní clustery.
Takové potřeby mohou zahrnovat pracovníky GPU, určité zásuvné moduly CNI, síť služeb nebo nějakou jinou službu.
Každý cluster lze přizpůsobit aplikaci, která na něm běží, aby obsahoval pouze to, co je potřeba.
− Různá prostředí v jednom clusteru
Nevýhodou tohoto přístupu je, že instance aplikací z různých prostředí koexistují ve stejném clusteru.
Například prod verze aplikace běží na stejném clusteru jako dev verze. To také znamená, že vývojáři pracují ve stejném clusteru jako produkční verze aplikace.
Pokud cluster selže kvůli akcím vývojářů nebo závadám ve verzi pro vývojáře, pak může potenciálně trpět i verze prod – obrovská nevýhoda tohoto přístupu.
A nakonec poslední scénář na našem seznamu.
4. Jeden klastr na prostředí
Tento scénář poskytuje přidělení samostatného clusteru pro každé prostředí:
Jeden cluster na prostředí
Můžete mít například shluky dev, test и prod, ve kterém budete spouštět všechny instance aplikace, které jsou určeny pro konkrétní prostředí.
Zde jsou výhody a nevýhody tohoto přístupu.
+ Izolace prod-prostředí
V rámci tohoto přístupu jsou všechna prostředí od sebe izolována. V praxi je to však důležité zejména pro prostředí výroby.
Produkční verze aplikace jsou nyní nezávislé na tom, co se děje v jiných clusterech a prostředích.
Pokud se tedy v dev clusteru náhle objeví problém, prod verze aplikací budou nadále fungovat, jako by se nic nestalo.
+ Cluster lze přizpůsobit prostředí
Každý cluster může být přizpůsoben svému prostředí. Můžete například:
- nainstalovat nástroje pro vývoj a ladění do dev clusteru;
- nainstalovat testovací rámce a nástroje na cluster test;
- používat výkonnější hardware a síťová propojení v clusteru prod.
To zvyšuje efektivitu jak vývoje aplikací, tak provozu.
+ Omezení přístupu k produkčnímu clusteru
Potřeba pracovat přímo s prod clusterem nevzniká často, takže můžete výrazně omezit okruh lidí, kteří k němu mají přístup.
Můžete jít ještě dále a zcela připravit lidi o přístup k tomuto clusteru a všechna nasazení provádět pomocí automatizovaného nástroje CI/CD. Takový přístup minimalizuje riziko lidských chyb přesně tam, kde je to nejrelevantnější.
A teď pár slov o nevýhodách.
− Nedostatek izolace mezi aplikacemi
Hlavní nevýhodou tohoto přístupu je nedostatek izolace hardwaru a zdrojů mezi aplikacemi.
Nesouvisející aplikace sdílejí prostředky clusteru: jádro systému, procesor, paměť a některé další služby.
Jak již bylo zmíněno, může to být potenciálně nebezpečné.
− Neschopnost lokalizovat závislosti aplikací
Pokud má aplikace speciální požadavky, musí být splněny ve všech clusterech.
Pokud například aplikace potřebuje GPU, pak každý cluster musí obsahovat alespoň jednoho pracovníka s GPU (i když jej používá pouze tato aplikace).
V důsledku toho riskujeme vyšší náklady a neefektivní využívání zdrojů.
Závěr
Pokud máte určitou sadu aplikací, mohou být umístěny v několika velkých clusterech nebo v mnoha malých.
Článek pojednává o výhodách a nevýhodách různých přístupů, od jednoho globálního klastru po několik malých a vysoce specializovaných:
- jeden velký společný shluk;
- mnoho malých vysoce specializovaných klastrů;
- jeden cluster na aplikaci;
- jeden cluster na prostředí.
Jaký přístup tedy zvolit?
Jako obvykle, odpověď závisí na případu použití: musíte zvážit klady a zápory různých přístupů a vybrat tu nejlepší možnost.
Výběr se však neomezuje pouze na výše uvedené příklady – můžete použít libovolnou jejich kombinaci!
Můžete například uspořádat pár klastrů pro každý tým: klastr pro vývoj (který bude mít prostředí dev и test) a shluk pro výroba (kde bude produkční prostředí).
Na základě informací v tomto článku budete schopni odpovídajícím způsobem optimalizovat klady a zápory pro konkrétní scénář. Hodně štěstí!
PS
Přečtěte si také na našem blogu:
- «";
- «";
- «";
- «".
Zdroj: www.habr.com