Poznámka. preklad.: tento materiál je zo vzdelávacieho projektu je odpoveďou na obľúbenú otázku pri navrhovaní infraštruktúry založenej na Kubernetes. Dúfame, že pomerne podrobné popisy kladov a záporov každej možnosti vám pomôžu urobiť tú najlepšiu voľbu pre váš projekt.
TL; DR: tú istú množinu úloh možno spustiť na niekoľkých veľkých klastroch (každý klaster bude mať veľký počet úloh) alebo na mnohých malých (s malým počtom úloh v každom klastri).
Nižšie je uvedená tabuľka, ktorá hodnotí výhody a nevýhody každého prístupu:
Pri používaní Kubernetes ako platformy na spúšťanie aplikácií sa často vynára niekoľko základných otázok o zložitosti nastavenia klastrov:
- Koľko klastrov by som mal použiť?
- Aké veľké ich mám urobiť?
- Čo by mal obsahovať každý klaster?
V tomto článku sa pokúsim odpovedať na všetky tieto otázky analýzou výhod a nevýhod každého prístupu.
Vyjadrenie otázky
Ako vývojár softvéru pravdepodobne vyvíjate a prevádzkujete veľa aplikácií súčasne.
Okrem toho je pravdepodobné, že mnohé inštancie týchto aplikácií budú bežať v rôznych prostrediach – napríklad tieto môžu byť dev, test и prod.
Výsledkom je celá matica aplikácií a prostredí:
Aplikácie a prostredia
Vyššie uvedený príklad predstavuje 3 aplikácie a 3 prostredia, výsledkom čoho je celkovo 9 možných možností.
Každá inštancia aplikácie je samostatná jednotka nasadenia, s ktorou možno pracovať nezávisle od ostatných.
Vezmite prosím na vedomie, že inštancia aplikácie môže pozostávať z mnohých komponenty, ako je frontend, backend, databáza atď. V prípade aplikácie mikroslužieb bude inštancia zahŕňať všetky mikroslužby.
V dôsledku toho majú používatelia Kubernetes niekoľko otázok:
- Mali by byť všetky inštancie aplikácie umiestnené v jednom klastri?
- Oplatí sa mať samostatný klaster pre každú inštanciu aplikácie?
- Alebo možno použiť kombináciu vyššie uvedených prístupov?
Všetky tieto možnosti sú celkom životaschopné, pretože Kubernetes je flexibilný systém, ktorý neobmedzuje možnosti používateľa.
Tu sú niektoré z možných spôsobov:
- jeden veľký spoločný zhluk;
- mnoho malých vysoko špecializovaných zoskupení;
- jeden klaster na aplikáciu;
- jeden klaster na prostredie.
Ako je uvedené nižšie, prvé dva prístupy sú na opačných koncoch škály možností:
Od niekoľkých veľkých zhlukov (vľavo) po veľa malých (vpravo)
Vo všeobecnosti sa jeden zhluk považuje za „väčší“ ako iný, ak má väčší súčet uzlov a strukov. Napríklad klaster s 10 uzlami a 100 modulmi je väčší ako klaster s 1 uzlom a 10 modulmi.
Nuž, začnime!
1. Jeden veľký spoločný zhluk
Prvou možnosťou je umiestniť všetky pracovné zaťaženia do jedného klastra:
Jeden veľký zhluk
V rámci tohto prístupu sa klaster používa ako univerzálny platforma infraštruktúry — jednoducho nasadíte všetko, čo potrebujete, v existujúcom klastri Kubernetes.
Kubernetes umožňuje logické oddelenie častí klastra od seba, takže každá inštancia aplikácie môže mať svoj vlastný menný priestor.
Pozrime sa na výhody a nevýhody tohto prístupu.
+ Efektívne využívanie zdrojov
S jedným klastrom potrebujete iba jednu kópiu všetkých prostriedkov potrebných na spustenie a správu klastra Kubernetes.
Platí to napríklad pre hlavné uzly. Každý klaster Kubernetes má zvyčajne 3 hlavné uzly, takže pre jeden klaster ich počet zostane rovnaký (na porovnanie, 10 klastrov bude potrebovať 30 hlavných uzlov).
Vyššie uvedená jemnosť sa vzťahuje aj na ďalšie služby fungujúce naprieč celým klastrom, ako sú vyrovnávače záťaže, kontroléry Ingress, autentifikačné, protokolovacie a monitorovacie systémy.
V jednom klastri je možné všetky tieto služby využívať naraz pre všetky pracovné záťaže (nie je potrebné vytvárať ich kópie, ako je to pri viacerých klastroch).
+ Lacné
V dôsledku vyššie uvedeného je menej klastrov zvyčajne lacnejších, pretože nevznikajú žiadne režijné náklady.
To platí najmä pre hlavné uzly, ktoré môžu stáť značné množstvo peňazí bez ohľadu na to, ako sú hosťované (on-premises alebo v cloude).
Niektoré spravovali služby Kubernetes, ako napr alebo , poskytovať riadiacu vrstvu zadarmo. V tomto prípade je otázka nákladov menej akútna.
Existujú aj spravované služby, ktoré účtujú fixný poplatok za prevádzku každého klastra Kubernetes (napr. ).
+ Efektívna administratíva
Správa jedného klastra je jednoduchšia ako správa niekoľkých.
Správa môže zahŕňať tieto úlohy:
- Aktualizácia verzie Kubernetes;
- zriadenie CI/CD potrubia;
- inštalácia doplnku CNI;
- nastavenie systému overovania používateľov;
- inštalácia prístupového ovládača;
a veľa ďalších…
V prípade jedného klastra budete musieť toto všetko urobiť iba raz.
Pre mnohé klastre sa operácie budú musieť mnohokrát opakovať, čo si pravdepodobne vyžiada určitú automatizáciu procesov a nástrojov na zabezpečenie konzistentnosti a konzistentnosti v procese.
A teraz pár slov o nevýhodách.
− Jediný bod zlyhania
V prípade odmietnutia jediný klaster okamžite prestane fungovať všetko pracovné zaťaženie!
Existuje mnoho spôsobov, ako sa veci môžu pokaziť:
- aktualizácia Kubernetes vedie k neočakávaným vedľajším účinkom;
- Komponent na úrovni klastra (napríklad zásuvný modul CNI) začne nefungovať podľa očakávania;
- jeden z komponentov klastra nie je správne nakonfigurovaný;
- zlyhanie v základnej infraštruktúre.
Jeden takýto incident môže spôsobiť vážne poškodenie všetkých pracovných zaťažení hostených v zdieľanom klastri.
- Žiadna pevná izolácia
Spustenie v zdieľanom klastri znamená, že aplikácie zdieľajú hardvér, sieťové možnosti a operačný systém na uzloch klastra.
V istom zmysle sú dva kontajnery s dvoma rôznymi aplikáciami bežiacimi na rovnakom uzle ako dva procesy bežiace na rovnakom počítači s rovnakým jadrom operačného systému.
Linuxové kontajnery poskytujú určitú formu izolácie, ale nie je ani zďaleka taká silná ako tá, ktorú poskytujú napríklad virtuálne stroje. Proces v kontajneri je v podstate ten istý proces, ktorý beží na hostiteľskom operačnom systéme.
Môže to byť bezpečnostný problém: toto usporiadanie teoreticky umožňuje vzájomne nesúvisiacim aplikáciám komunikovať (či už úmyselne alebo náhodne).
Okrem toho všetky pracovné zaťaženia v klastri Kubernetes zdieľajú niektoré služby pre celý klaster, ako napr - to umožňuje aplikáciám nájsť služby iných aplikácií v klastri.
Všetky vyššie uvedené body môžu mať rôzny význam v závislosti od bezpečnostných požiadaviek aplikácie.
Kubernetes poskytuje rôzne nástroje na predchádzanie bezpečnostným problémom ako napr и . Ich správne nastavenie si však vyžaduje určité skúsenosti, navyše nedokážu uzavrieť úplne všetky bezpečnostné diery.
Je dôležité si vždy pamätať, že Kubernetes bol pôvodne navrhnutý pre zdieľanie, nie pre izolácia a bezpečnosť.
− Nedostatok prísneho multiprenájmu
Vzhľadom na množstvo zdieľaných zdrojov v klastri Kubernetes existuje mnoho spôsobov, ako si rôzne aplikácie môžu navzájom šliapať na nohy.
Napríklad aplikácia môže monopolizovať zdieľaný prostriedok (ako je CPU alebo pamäť) a odoprieť k nemu prístup iným aplikáciám bežiacim na rovnakom uzle.
Kubernetes poskytuje rôzne mechanizmy na kontrolu tohto správania, ako napr (pozri aj článok „" - približne. preklad.), и . Rovnako ako v prípade bezpečnosti je však ich konfigurácia celkom netriviálna a nedokážu zabrániť absolútne všetkým nepredvídaným vedľajším účinkom.
− Veľký počet používateľov
V prípade jedného klastra musíte k nemu otvoriť prístup mnohým ľuďom. A čím väčší je ich počet, tým vyššie je riziko, že niečo „rozbijú“.
V rámci klastra môžete ovládať, kto môže čo robiť (pozri článok “" - približne. preklad.). Nezabráni však používateľom niečo „rozbiť“ v rámci hraníc ich oblasti zodpovednosti.
− Klastre nemôžu rásť donekonečna
Klaster, ktorý sa používa pre všetky pracovné zaťaženia, bude pravdepodobne dosť veľký (pokiaľ ide o počet uzlov a modulov).
Tu však vzniká ďalší problém: klastre v Kubernetes nemôžu rásť donekonečna.
Existuje teoretický limit veľkosti klastra. V Kubernetes je to približne .
V reálnom živote však môžu problémy začať oveľa skôr – napríklad práve s .
Faktom je, že veľké klastre kladú vysokú záťaž na kontrolnú vrstvu Kubernetes. Inými slovami, udržanie efektívneho fungovania klastra si vyžaduje starostlivé ladenie.
Tento problém je skúmaný v súvisiacom článku na pôvodnom blogu s názvom „".
Ale zvážme opačný prístup: veľa malých zhlukov.
2. Mnoho malých, špecializovaných zoskupení
S týmto prístupom používate samostatný klaster pre každý prvok, ktorý nasadíte:
Veľa malých zhlukov
Na účely tohto článku, pod nasaditeľný prvok odkazuje na inštanciu aplikácie – napríklad na dev verziu samostatnej aplikácie.
Táto stratégia využíva Kubernetes ako špecializovaný beh programu pre jednotlivé inštancie aplikácie.
Pozrime sa na výhody a nevýhody tohto prístupu.
+ Obmedzený „polomer výbuchu“
Keď klaster zlyhá, negatívne dôsledky sa obmedzia len na tie pracovné zaťaženia, ktoré boli nasadené v tomto klastri. Všetky ostatné úlohy zostávajú nedotknuté.
+ Izolácia
Pracovné zaťaženia hosťované v jednotlivých klastroch nezdieľajú prostriedky, ako je procesor, pamäť, operačný systém, sieť alebo iné služby.
Výsledkom je tesná izolácia medzi nesúvisiacimi aplikáciami, čo môže byť prospešné pre ich bezpečnosť.
+ Malý počet používateľov
Vzhľadom na to, že každý klaster obsahuje iba obmedzenú množinu úloh, počet používateľov s prístupom k nemu je znížený.
Čím menej ľudí má prístup do klastra, tým menšie je riziko, že sa niečo „rozbije“.
Pozrime sa na nevýhody.
− Neefektívne využívanie zdrojov
Ako už bolo spomenuté, každý klaster Kubernetes vyžaduje špecifickú sadu zdrojov správy: hlavné uzly, komponenty riadiacej vrstvy, riešenia monitorovania a protokolovania.
V prípade veľkého počtu malých klastrov musí byť na manažment alokovaný väčší podiel zdrojov.
− Drahé
Neefektívne využívanie zdrojov so sebou automaticky prináša vysoké náklady.
Napríklad udržiavanie 30 hlavných uzlov namiesto troch s rovnakým výpočtovým výkonom nevyhnutne ovplyvní náklady.
− Ťažkosti pri podávaní
Správa viacerých klastrov Kubernetes je oveľa náročnejšia ako správa jedného.
Napríklad budete musieť nakonfigurovať autentifikáciu a autorizáciu pre každý klaster. Verzia Kubernetes bude tiež musieť byť niekoľkokrát aktualizovaná.
Na zefektívnenie všetkých týchto úloh budete pravdepodobne musieť použiť automatizáciu.
Teraz sa pozrime na menej extrémne scenáre.
3. Jeden klaster na aplikáciu
V tomto prístupe vytvoríte samostatný klaster pre všetky inštancie konkrétnej aplikácie:
Klaster na aplikáciu
Túto cestu možno považovať za zovšeobecnenie princípu „samostatný klaster na tím“, pretože zvyčajne tím inžinierov vyvíja jednu alebo viac aplikácií.
Pozrime sa na výhody a nevýhody tohto prístupu.
+ Klaster je možné prispôsobiť aplikácii
Ak má aplikácia špeciálne potreby, môžu byť implementované v klastri bez ovplyvnenia iných klastrov.
Takéto potreby môžu zahŕňať pracovníkov GPU, určité doplnky CNI, sieť služieb alebo inú službu.
Každý klaster je možné prispôsobiť aplikácii, ktorá v ňom beží, tak, aby obsahoval len to, čo je potrebné.
− Rôzne prostredia v jednom klastri
Nevýhodou tohto prístupu je, že inštancie aplikácií z rôznych prostredí koexistujú v rovnakom klastri.
Napríklad prod verzia aplikácie beží v rovnakom klastri ako dev verzia. To tiež znamená, že vývojári pôsobia v rovnakom klastri, v ktorom je prevádzkovaná produkčná verzia aplikácie.
Ak v dôsledku krokov vývojárov alebo závad vo verzii pre vývojárov dôjde k zlyhaniu v klastri, potom môže potenciálne trpieť aj verzia prod – obrovská nevýhoda tohto prístupu.
A nakoniec posledný scenár na našom zozname.
4. Jeden klaster na prostredie
Tento scenár zahŕňa pridelenie samostatného klastra pre každé prostredie:
Jeden klaster na prostredie
Môžete mať napríklad klastre dev, test и prod, v ktorom budete spúšťať všetky inštancie aplikácie venované konkrétnemu prostrediu.
Tu sú výhody a nevýhody tohto prístupu.
+ Izolácia výrobného prostredia
V rámci tohto prístupu sú všetky prostredia od seba izolované. V praxi je to však obzvlášť dôležité v prostredí výroby.
Produkčné verzie aplikácie sú teraz nezávislé od toho, čo sa deje v iných klastroch a prostrediach.
Týmto spôsobom, ak sa náhle vyskytne problém v klastri dev, prod verzie aplikácií budú naďalej fungovať, ako keby sa nič nestalo.
+ Klaster je možné prispôsobiť prostrediu
Každý klaster je možné prispôsobiť svojmu prostrediu. Môžete napríklad:
- nainštalovať nástroje na vývoj a ladenie v klastri pre vývojárov;
- nainštalovať testovacie rámce a nástroje v klastri test;
- používať výkonnejší hardvér a sieťové kanály v klastri prod.
To vám umožní zvýšiť efektivitu vývoja a prevádzky aplikácií.
+ Obmedzenie prístupu do produkčného klastra
Potreba pracovať priamo s prod clusterom vzniká len zriedka, takže môžete výrazne obmedziť okruh ľudí, ktorí k nemu majú prístup.
Môžete ísť ešte ďalej a úplne zakázať ľuďom prístup k tomuto klastru a vykonávať všetky nasadenia pomocou automatizovaného nástroja CI/CD. Takýto prístup minimalizuje riziko ľudských chýb presne tam, kde je to najrelevantnejšie.
A teraz pár slov o nevýhodách.
− Žiadna izolácia medzi aplikáciami
Hlavnou nevýhodou tohto prístupu je nedostatok izolácie hardvéru a zdrojov medzi aplikáciami.
Nesúvisiace aplikácie zdieľajú prostriedky klastra: jadro systému, procesor, pamäť a niektoré ďalšie služby.
Ako už bolo spomenuté, môže to byť potenciálne nebezpečné.
− Neschopnosť lokalizovať závislosti aplikácií
Ak má aplikácia špeciálne požiadavky, musia byť splnené vo všetkých klastroch.
Napríklad, ak aplikácia vyžaduje GPU, potom každý klaster musí obsahovať aspoň jedného pracovníka s GPU (aj keď ho používa iba daná aplikácia).
V dôsledku toho riskujeme vyššie náklady a neefektívne využívanie zdrojov.
Záver
Ak máte špecifickú sadu aplikácií, môžu byť umiestnené v niekoľkých veľkých klastroch alebo v mnohých malých.
Článok rozoberá výhody a nevýhody rôznych prístupov, od jedného globálneho klastra po niekoľko malých a vysoko špecializovaných:
- jeden veľký všeobecný zhluk;
- mnoho malých vysoko špecializovaných zoskupení;
- jeden klaster na aplikáciu;
- jeden klaster na prostredie.
Aký prístup by ste teda mali zvoliť?
Ako vždy, odpoveď závisí od prípadu použitia: musíte zvážiť klady a zápory rôznych prístupov a vybrať si najoptimálnejšiu možnosť.
Výber sa však neobmedzuje len na vyššie uvedené príklady – môžete použiť akúkoľvek ich kombináciu!
Môžete napríklad zorganizovať niekoľko klastrov pre každý tím: vývojový klaster (v ktorom budú prostredia dev и test) a zoskupiť pre výroba (kde sa bude nachádzať produkčné prostredie).
Na základe informácií v tomto článku môžete podľa toho optimalizovať klady a zápory pre konkrétny scenár. Veľa štastia!
PS
Prečítajte si aj na našom blogu:
- «»;
- «»;
- «»;
- «".
Zdroj: hab.com