Pozn. prekl.: tento materiál z vzdelávacieho projektu — odpoveď na bežnú otázku pri navrhovaní infraštruktúry založenej na Kubernetes. Dúfame, že dostatočne podrobné opisy výhod a nevýhod každého z variantov pomôžu pri optimálnom rozhodovaní aj pre váš projekt.
TL;DR: ten istý súbor pracovných záťaží možno spustiť na niekoľkých veľkých clusteroch (na každý cluster pripadá značné množstvo workloadov) alebo na množstve malých (s nízkym počtom záťaží v každom clustri).
Nižšie je uvedená tabuľka, v ktorej sú hodnotené výhody a nevýhody každého prístupu:
Pri používaní Kubernetes ako platformy pre prevádzku aplikácií sa často objavujú niekoľko základných otázok o jemnostiach nastavenia clustrov:
- Aký počet clustrov použiť?
- Aké veľké by mali byť?
- Čo by mal každý cluster obsahovať?
V tomto článku sa pokúsim odpovedať na všetky tieto otázky, analyzujúc výhody a nevýhody každého prístupu.
Formulácia otázky
Ako vytvoriteľ softvéru pravdepodobne súčasne vyvíjate a prevádzkujete množstvo aplikácií.
Okrem toho sa množstvo exemplárov týchto aplikácií určite spúšťa v rôznych prostrediach — napríklad to môžu byť dev, test a produkcia.
Výsledkom je celá matica aplikácií a prostredí:
Aplikácie a prostredia
V uvedenom príklade sú zobrazené 3 aplikácie a 3 prostredia, čo v konečnom dôsledku dáva 9 možných variantov.
Každý exemplár aplikácie predstavuje samostatnú deployment jednotku, s ktorou sa dá pracovať nezávisle od ostatných.
Všimnite si, že exemplár aplikácie môže pozostávať z množstva komponentov, ako sú frontend, backend, databáza atď. V prípade mikroslužobnej aplikácie bude exemplár zahŕňať všetky mikroslužby.
Ako výsledok majú používatelia Kubernetes niekoľko otázok:
- Je rozumné umiestniť všetky exempláre aplikácie do jedného clustra?
- Malo by sa zakladať samostatný cluster pre každý exemplár aplikácie?
- Alebo možno by sa mala využiť kombinácia vyššie uvedených prístupov?
Všetky tieto varianty sú celkom životaschopné, pretože Kubernetes je flexibilný systém, ktorý neobmedzuje používateľa v možnostiach.
Tu je niekoľko možných prístupov:
- jeden veľký spoločný cluster;
- množstvo malých špecializovaných klastrov;
- jeden klaster pre každú aplikáciu;
- jeden klaster pre každé prostredie.
Ako je znázornené nižšie, prvé dva prístupy sú na opačných koncoch škály možností:
Od niekoľkých veľkých klastrov (vľavo) po množstvo malých (vpravo)
Všeobecne sa považuje, že jeden klaster je 'väčší' ako druhý, ak má väčší súčet uzlov a podov. Napríklad, klaster s 10 uzlami a 100 podmi je väčší ako klaster s 1 uzlom a 10 podmi.
No, poďme začať!
1. Jeden veľký spoločný klaster
Prvý variant — umiestniť všetky pracovné zaťaženia do jedného klastera:
Jeden veľký klaster
V rámci tohto prístupu sa klaster používa ako univerzálna infrastruktúrna platforma — všetko potrebné jednoducho rozbaľujete v existujúcom klasteri Kubernetes.
Kubernetes umožňuje logicky oddeliť časti klastera jednu od druhej, takže pre každý inštanciu aplikácie môžete využiť svoje vlastné meno priestoru.
Poďme sa pozrieť na plusy a mínusy tohto prístupu.
+ Efektívne využívanie zdrojov
V prípade jediného klastera bude potrebná len jedna kópia všetkých zdrojov potrebných na spustenie a správu klastera Kubernetes.
Napríklad, to platí pre hlavné uzly. Zvyčajne na každý klaster Kubernetes pripadá 3 hlavné uzly, takže pre jeden jediný klaster ich počet ostáva rovnaký (pre porovnanie, 10 klastrov bude potrebovať 30 hlavných uzlov).
Uvedená nuansa sa týka aj iných služieb, ktoré fungujú v rámci celého klastera, ako sú vyrovnávače zaťaženia, kontroléry Ingress, autentifikačné, logovacie a monitorovacie systémy.
V jednom klasteri je možné využiť všetky tieto služby okamžite pre všetky pracovné zaťaženia (nie je potrebné vytvárať ich kópie, ako je to v prípade viacerých klastrov).
+ Lacnosť
Ako dôsledok uvedeného, menší počet klastrov obvykle vychádza lacnejšie, pretože chýbajú náklady na nadbytočné zdroje.
To platí najmä pre hlavné uzly, ktoré môžu stáť značné peniaze, bez ohľadu na to, ako sú umiestnené (on-premises alebo v cloude).
Niektoré spravované služby Kubernetes, ako sú alebo , poskytujú bezplatnú správu vrstvy. V tomto prípade nie je otázka nákladov taká naliehavá.
Existujú aj spravované služby, ktoré účtujú pevnú sumu za fungovanie každého klastra Kubernetes (napríklad, ).
+ Efektívna správa
Spravovať jeden klaster je jednoduchšie, ako spravovať viacero.
Správa môže zahŕňať nasledujúce úlohy:
- aktualizácia verzie Kubernetes;
- nastavenie CI/CD pipeline;
- inštalácia CNI pluginu;
- nastavenie autentifikačného systému pre používateľov;
- inštalácia prístupového kontroléra;
a mnoho ďalších…
V prípade jedného klastra sa tomu všetkému treba venovať len raz.
Pri viacerých klastra bude potrebné tieto operácie opakovať viackrát, čo pravdepodobne bude vyžadovať nejakú automatizáciu procesov a nástrojov na zabezpečenie systematickosti a jednotnosti procesu.
A teraz niekoľko slov o nevýhodách.
− Jediný bod zlyhania
V prípade zlyhania jediného klastra okamžite prestanú fungovať všetky pracovné záťaže!
Existuje množstvo scenárov, kedy sa môže niečo pokaziť:
- aktualizácia Kubernetes môže spôsobiť neočakávané vedľajšie účinky;
- komponenty klastra (napríklad, CNI plugin) prestanú fungovať tak, ako sa očakávalo;
- jeden z komponentov klastra je nesprávne nakonfigurovaný;
- zlyhanie v základnej infraštruktúre.
Jeden taký incident môže vážne poškodiť všetky pracovné záťaže umiestnené v spoločnom klastri.
− Nedostatok prísnej izolácie
Práca v spoločnom 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 tom istom uzle podobné dvom procesom bežiacim na tom istom stroji s rovnakým jadrom OS.
Linuxové kontajnery poskytujú určitú formu izolácie, ale tá nie je taká silná ako tá, ktorú poskytujú napríklad virtuálne stroje. V podstate je proces v kontajneri rovnaký proces, ktorý beží v operačnom systéme hostiteľa.
To môže predstavovať problém z hľadiska bezpečnosti: takáto organizácia teoreticky umožňuje nesúvisiacim aplikáciám interagovať navzájom (úmyselne alebo náhodne).
Okrem toho všetky pracovné záťaže v clustre Kubernetes zdieľajú niektoré spoločné klastrové služby, ako napríklad — to umožňuje aplikáciám nájsť služby iných aplikácií v clustri.
Všetky vyššie uvedené body môžu mať rôznu hodnotu v závislosti od požiadaviek kladených na bezpečnosť aplikácií.
Kubernetes poskytuje rôzne nástroje na prevenciu problémov v systéme bezpečnosti, ako sú a . Na ich správne nastavenie je však potrebná určitá odborná znalosť, navyše nie sú schopné úplne zakryť všetky medzery v bezpečnosti.
Je dôležité vždy pamätať na to, že Kubernetes bol pôvodne navrhnutý na spoločné používanie, nie na izoláciu a bezpečnosť.
− Absencia prísnej multi-tenancy
Vzhľadom na množstvo spoločných zdrojov v clustri Kubernetes existuje mnoho spôsobov, ktorými si rôzne aplikácie môžu "stúpiť na päty".
Napríklad, aplikácia môže monopolizovať nejaký spoločný zdroj (ako procesor alebo pamäť) a odoprieť ostatným aplikáciám pracujúcim na tom istom uzle prístup k nemu.
Kubernetes poskytuje rôzne mechanizmy kontroly tohto správania, ako sú (pozri tiež článok "“ — pozn. prekl.), a . Avšak ako v prípade bezpečnosti, aj ich nastavenie je dosť zložité a nie sú schopné zabrániť všetkým neočakávaným vedľajším efektom.
− Veľké množstvo používateľov
V prípade jediného clustra je potrebné sprístupniť ho mnohým ľuďom. A čím je ich počet väčší, tým je vyššie riziko, že niečo "pokazia".
Vnútri clustra je možné kontrolovať, kto a čo môže robiť pomocou (pozri článok "“ — pozn. prekl.). Avšak to nezabráni používateľom "pokaziť" niečo vo svojej zóne zodpovednosti.
− Klustre nemôžu rásť do nekonečna
Cluster, ktorý sa používa pre všetky pracovné záťaže, pravdepodobne bude veľmi veľký (počet uzlov a podov).
Ale tu nastáva iný problém: klustre v Kubernetes nemôžu rásť do nekonečna.
Existuje teoretický limit na veľkosť clustra. V Kubernetes je to približne .
Avšak v skutočnom živote môžu problémy začať oveľa skôr — napríklad už pri .
Ide o to, že veľké klastre vyvíjajú vysoké zaťaženie na riadiacu vrstvu Kubernetes. Inými slovami, na udržanie klastru v prevádzke a efektívne využívanie zdrojov je potrebná podrobná konfigurácia.
Tento problém je podrobne rozobraný v príslušnom článku v pôvodnom blogu s názvom „».
Ale poďme sa pozrieť na opačný prístup: množstvo malých klastrov.
2. Množstvo malých, špecializovaných klastrov
Pri tomto prístupe používate samostatný klaster pre každý nasadzovaný prvok:
Množstvo malých klastrov
Na účely tohto článku sa pod nasadzovaným prvkom rozumie inštancia aplikácie — napríklad dev-verzia jednotlivého aplikačného prvku.
V tejto stratégii sa Kubernetes používa ako špecializované prostriedie na spúšťanie pre jednotlivé inštancie aplikácie.
Poďme sa pozrieť na plusy a mínusy tohto prístupu.
+ Obmedzený „rádius výbuchu“
Pri „poruche“ klastru sú negatívne následky obmedzené iba na tie pracovné zaťaženia, ktoré boli nasadené v tomto klastre. Všetky ostatné workloady zostávajú nedotknuté.
+ Izolácia
Pracovné zaťaženia umiestnené v individuálnych klastra nemajú spoločné zdroje, ako sú procesor, pamäť, operačný systém, sieť alebo iné služby.
Výsledkom je pevná izolácia medzi nesúvisiacimi aplikáciami, čo môže pozítivne ovplyvniť ich bezpečnosť.
+ Malý počet užívateľov
Vzhľadom na to, že v každom klastri je iba obmedzená sada pracovných zaťaženia, znižuje sa počet užívateľov s prístupom k nemu.
Čím menej ľudí má prístup k klastru, tým nižšie je riziko, že niečo „zhavaruje“.
Pozrime sa na nevýhody.
− Neefektívne využívanie zdrojov
Ako už bolo spomenuté, každému klastru Kubernetes je potrebný určitý súbor riadiacich zdrojov: master uzly, komponenty kontrolnej vrstvy, riešenia na monitorovanie a logovanie.
V prípade veľkého počtu malých klastrov je potrebné vyčleniť väčšiu časť zdrojov na správu.
− Nákladnosť
Neefektívne využívanie zdrojov automaticky prináša vysoké náklady.
Napríklad, existencia 30 master uzlov namiesto troch pri tej istej výpočtovej sile nepochybne ovplyvní náklady.
− Zložitosti správy
Spravovať množstvo Kubernetes klastrov je oveľa zložitejšie ako pracovať s jedným.
Napríklad, bude potrebné nastaviť autentifikáciu a autorizáciu pre každý klaster. Aktualizáciu verzie Kubernetes bude tiež potrebné vykonať niekoľkokrát.
Pravdepodobne bude potrebné aplikovať automatizáciu na zvýšenie účinnosti všetkých týchto úloh.
Teraz sa pozrime na menej extrémne scenáre.
3. Jeden klaster pre každú aplikáciu
V rámci tohto prístupu vytvárate samostatný klaster pre všetky inštancie konkrétnej aplikácie:
Klaster pre aplikáciu
Tento prístup možno považovať za generalizáciu princípu „samostatný klaster pre tím“, pretože zvyčajne tím inžinierov vyvíja jednu alebo niekoľko aplikácií.
Poďme sa pozrieť na plusy a mínusy tohto prístupu.
+ Klaster možno prispôsobiť aplikácii
Ak má aplikácia špeciálne požiadavky, môžu byť implementované v klastri, pričom sa iné klastre netýkajú.
Takéto požiadavky môžu zahŕňať workery s GPU, určité CNI pluginy, service mesh alebo nejakú inú službu.
Každý klaster môže byť prispôsobený podľa aplikácie, ktorá v ňom beží, aby obsahoval iba 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 jednom klastri.
Napríklad, produkčná verzia aplikácie beží v tom istom klastri ako verzia pre vývoj. To tiež znamená, že vývojári pracujú v tom istom klastri, v ktorom je nasadená produkčná verzia aplikácie.
Ak kvôli činnosti vývojárov alebo chybám vo verzii pre vývoj v klastri dôjde k zlyhaniu, môže to potenciálne ovplyvniť aj produkčnú verziu — čo je obrovská nevýhoda tohto prístupu.
A nakoniec, posledný scenár v našom zozname.
4. Jeden klaster pre každé prostredie
Tento scenár predpokladá vyčlenenie samostatného klastra pre každé prostredie:
Jeden klaster pre prostredie
Napríklad, môžete mať klastre dev, test a produkcia, v ktorých budete spúšťať všetky inštancie aplikácie určené pre konkrétne prostredie.
Tu sú výhody a nevýhody takéhoto prístupu.
+ Izolácia produkčného prostredia
V rámci tohto prístupu sú všetky prostredia izolované od seba. Avšak v praxi je to obzvlášť dôležité pre prod-prostredie.
Produkčné verzie aplikácií teraz nie sú závislé od toho, čo sa deje v iných klastroch a prostrediach.
Takže ak v dev-klastre náhle nastane problém, produkčné verzie aplikácií budú naďalej fungovať, ako keby sa nič nestalo.
+ Klaster sa dá prispôsobiť prostrediu
Každý klaster sa dá prispôsobiť jeho prostrediu. Napríklad je možné:
- nainštalovať v dev-klastre nástroje na vývoj a ladenie;
- nainštalovať testovacie frameworky a nástroje v klastri test;
- použiť výkonnejšie zariadenia a sieťové kanály v klastri produkcia.
To umožňuje zvýšiť efektivitu ako vývoja, tak aj prevádzky aplikácií.
+ Obmedzenie prístupu k produkčnému klastromu
Potrebnosť pracovať priamo s prod-klastrom sa vyskytuje zriedkavo, takže je možné značne obmedziť okruh osôb, ktoré majú k nemu prístup.
Môžete ísť ešte ďalej a úplne odňať prístup ľuďom k tomuto klastromu, pričom všetky nasadenia vykonávať pomocou automatizovaného nástroja CI/CD. Takýto prístup maximalizuje zníženie rizika ľudských chýb presne tam, kde to má najväčší význam.
A teraz niekoľko slov o nevýhodách.
− Absencia izolácie medzi aplikáciami
Hlavnou nevýhodou prístupu je absencia hardvérovej a zdrojovej izolácie medzi aplikáciami.
Nesúvisiace aplikácie spoločně využívajú zdroje klastra: systémové jadro, procesor, pamäť a niektoré iné služby.
Ako už bolo spomenuté, to môže byť potenciálne nebezpečné.
− Nemožnosť lokalizovať závislosti aplikácií
Ak má aplikácia špeciálne požiadavky, musí ich splniť vo všetkých klastroch.
Napríklad, ak aplikácii je potrebný GPU, každý klaster musí obsahovať aspoň jeden worker s GPU (aj keď sa používa len touto aplikáciou).
V dôsledku toho riskujeme vyššie náklady a neefektívne využívanie zdrojov.
Záver
Pri prítomnosti určitého súboru aplikácií ich môžeme umiestniť do niekoľkých veľkých klastrov alebo do mnohých malých.
V článku sú rozobrané výhody a nevýhody rôznych prístupov, od jedného globálneho klastra až po niekoľko malých a špecializovaných:
- jeden veľký spoločný klaster;
- množstvo malých špecializovaných klastrov;
- jeden klaster pre každú aplikáciu;
- jeden klaster pre každé prostredie.
Aký prístup si teda vybrať?
Ako obvykle, odpoveď závisí od scenára použitia: je potrebné zvážiť výhody a nevýhody rôznych prístupov a vybrať ten najoptimálnejší variant.
Avšak výber nie je obmedzený len na uvedené príklady — môžete využiť akúkoľvek ich kombináciu!
Napríklad, môžete usporiadať po dvojici klastrov pre každý tím: klaster pre vývoj (v ktorom budú prostredia dev a test) a klaster pre produkciu (kde sa bude nachádzať produkčné prostredie).
Na základe informácií z tohto článku budete môcť príslušne optimalizovať výhody a nevýhody podľa konkrétneho scenára. Veľa šťastia!
P.S.
Prečítajte si tiež na našom blogu:
- «»;
- «»;
- «»;
- «».
Zdroj: habr.com
