Pri vytváraní klastra Kubernetes sa môžu objaviť otázky: koľko nastaviť pracovných uzlov a akého typu? Čo je lepšie pre on-premise klaster: kúpiť niekoľko výkonných serverov, alebo využiť desiatku starších strojov vo vašom dátovom centre? A v cloude je lepšie vziať osem jednojadrových alebo dva štvrojadrové inštancie?
Odpovede na tieto otázky sú v článku v preklade tímu .
Kapacita klastrov
Celkovo sa klaster Kubernetes dá považovať za veľký „superuzol“. Jeho celkový výpočtový výkon je súčtom výkonov všetkých zložených uzlov.
Existuje niekoľko spôsobov, ako dosiahnuť požadovanú cieľovú kapacitu klastra. Napríklad potrebujeme klaster s celkovou kapacitou 8 CPU jadier a 32 GB RAM, pretože súbor aplikácií vyžaduje takýto počet zdrojov. Potom je možné nainštalovať dva uzly s 16 GB pamäte alebo štyri uzly s 8 GB pamäte, dva štvrojadrové procesory alebo štyri dvojjadrové.
Tu sú len dva možné spôsoby vytvorenia klastra:
Obe možnosti dávajú klaster s rovnakou kapacitou, ale v spodnej konfigurácii sú nainštalované štyri menšie uzly, zatiaľ čo v hornej konfigurácii sú dva veľké.
Ktorá možnosť je lepšia?
Aby sme na túto otázku odpovedali, pozrime sa na výhody oboch možností. Dali sme ich do tabuľky.
Niekoľko veľkých uzlov
Veľa malých uzlov
Jednoduchšie spravovanie klastra (ak je on-premise)
Plynulé automatické škálovanie
Lepšie cenové možnosti (ak je on-premise)
Cena sa málo líši (v cloude)
Je možné spúšťať náročné aplikácie
Úplná replikácia
Zdroje sa využívajú efektívnejšie (menší overhead na systémové démony)
Vyššia odolnosť voči zlyhaniu klastra
Všimnite si, že hovoríme len o pracovných uzloch. Výber počtu a veľkosti hlavných uzlov je úplne iná téma.
Takže sa podrobne pozrime na každý bod z tabuľky.
Prvá možnosť: niekoľko veľkých uzlov
Najextrémnejšia možnosť — jeden pracovný uzol na celú kapacitu klastra. V uvedenom príklade to bol jeden pracovný uzol s 16 CPU jadrami a 16 GB RAM.
Výhody
Plus č. 1. Jednoduchšie spravovanie
Je jednoduchšie spravovať niekoľko strojov ako celý park. Rýchlejšie aplikovať aktualizácie a opravy, jednoduchšie synchronizovať. Počet výpadkov v absolútnych číslach je tiež nižší.
Upozorňujeme, že všetko vyššie uvedené sa vzťahuje na vlastný hardvér, vlastné servery, nie na cloudové instance.
V cloude je situácia iná. O riadenie sa stará poskytovateľ cloudových služieb. Tým pádom sa správa desiatich uzlov v cloude významne nelíši od správy jedného uzla.
Routovanie prevádzky a rozdeľovanie zaťaženia medzi podmi v cloude : prichádzajúca prevádzka z internetu je smerovaná na hlavný vyvažovač zaťaženia, ktorý potom smeruje prevádzku na port jedného z uzlov (služba NodePort vyžaduje port v rozsahu 30000-32767 na každom uzle klastera). Pravidlá nastavené kube-proxy presmerovávajú prevádzku z uzla na pod. Takto to vyzerá pre desať podov na dvoch uzloch:
Plus č. 2. Nižšie náklady na uzol
Výkonný stroj je drahší, ale rast ceny nie je nevyhnutne lineárny. Inými slovami, jeden desaťjadrový server s 10 GB pamäte je zvyčajne lacnejší ako desať jednojadrových s rovnakým množstvom pamäte.
Ale všimnite si, že toto pravidlo zvyčajne neplatí v cloudových službách. V súčasných cenových schémach všetkých hlavných poskytovateľov cloudových služieb ceny rastú lineárne s rastom kapacity.
Tým pádom v cloude sa zvyčajne nedá ušetriť na výkonnejších serveroch.
Plus č. 3. Môžete spúšťať náročné aplikácie
Niektoré aplikácie potrebujú výkonné servery v klastri. Napríklad, ak systém strojového učenia vyžaduje 8 GB pamäte, nemôžete ho spustiť na uzloch s 1 GB, ale iba ak máte aspoň jeden veľký pracovný uzol.
Nevýhody
Minus č. 1. Mnoho podov na uzol
Ak sa tá istá úloha vykonáva na menšom počte uzlov, tak na každom z nich bude prirodzene viac podov.
To môže byť problém.
Dôvodom je, že každý modul prináša určité režijné náklady na prostredie kontajnerov (napríklad Docker), ako aj kubelet a cAdvisor.
Napríklad, kubelet pravidelne kontroluje živosť všetkých kontajnerov na uzle — čím viac kontajnerov, tým viac práce má kubelet.
CAdvisor zhromažďuje štatistiky využívania zdrojov všetkých kontajnerov na uzle a kubelet pravidelne túto informáciu vyžaduje a poskytuje ju cez API. Opäť, čím viac kontajnerov, tým viac práce má cAdvisor aj kubelet.
Ak počet modulov vzrastie, môže to spomaliť systém a dokonca ohroziť jeho spoľahlivosť.
V repozitári Kubernetes niektorí , že uzly sa skáču medzi stavmi Ready/NotReady, pretože pravidelné kontroly kubeletu všetkých kontajnerov na uzle zaberajú priveľa času.
Z tohto dôvodu Kubernetes . V závislosti od výkonu uzla môžete spustiť viac podov na uzol, ale ťažko predpokladať, či vzniknú problémy alebo všetko bude fungovať dobre. Je dobré to vopred otestovať.
Nevýhoda č. 2. Obmedzenie replikačného výkonu
Príliš nízky počet uzlov obmedzuje účinné stupne replikačného výkonu aplikácií. Napríklad, ak máte aplikáciu s vysokou dostupnosťou s piatimi replikami, ale len dva uzly, účinná miera replikačného výkonu aplikácie sa znižuje na dva.
Päť replik sa dá rozložiť len na dva uzly, a ak jeden z nich prestane fungovať, okamžite vyradí niekoľko replik.
Ak máte päť uzlov alebo viac, každá replika sa vykonáva na samostatnom uzle a zlyhanie jedného uzla odstráni maximálne jednu repliku.
Preto požiadavky na vysokú dostupnosť môžu vyžadovať určitý minimálny počet uzlov v klusteri.
Nevýhoda č. 3. Zhoršené následky zlyhania
Pri menšom počte uzlov nesie každé zlyhanie vážnejšie dôsledky. Napríklad, ak máte len dva uzly a jeden z nich zlyhá, polovica vašich modulov zmizne.
Samozrejme, Kubernetes presunie záťaž z nefunkčného uzla na ostatné. Ale ak ich je málo, môže chýbať voľná kapacita. V dôsledku toho budú niektoré vaše aplikácie nedostupné, kým neobnovíte nefunkčný uzol.
Takže čím viac uzlov, tým menší dopad hardvérových zlyhaní.
Nevýhoda č. 4. Viac krokov automatického škálovania.
V Kubernetes funguje systém automatického škálovania klastra pre cloudovú infraštruktúru, ktorý umožňuje automaticky pridávať alebo odoberať uzly podľa aktuálnych potrieb. S väčšími uzlami sa škálovanie stáva výraznejším a menej obratným. Napríklad, ak pridáte ďalší uzol na dvoch uzloch, kapacita klastra sa okamžite zvýši o 50 %. A budete musieť za tieto zdroje zaplatiť, aj keď ich nepotrebujete.
Takže, ak plánujete používať automatické škálovanie klastra, čím menšie sú uzly, tým flexibilnejšie a hospodárnejšie škálovanie dostanete.
Teraz sa pozrime na výhody a nevýhody veľkého množstva malých uzlov.
Druhá možnosť: množstvo malých uzlov
Výhody tohto prístupu v podstate vyplývajú z nevýhod opačnej možnosti s niekoľkými veľkými uzlami.
Výhody
Plus č. 1. Menšie následky výpadku
Čím viac uzlov, tým menej pod’ov na každom uzle. Napríklad, ak máte sto modulov na desiatich uzloch, na každom uzle bude v priemere desať modulov.
Ak teda jeden z uzlov zlyhá, stratíte len 10 % pracovnej záťaže. Existuje pravdepodobnosť, že sa dotkne len malého počtu replik, a aplikácie v celku zostanú v prevádzke.
Okrem toho, na zostávajúcich uzloch pravdepodobne zostanú voľné zdroje na pracovnú záťaž zlyhaného uzla, takže Kubernetes môže slobodne preplánovať pod’y a vaše aplikácie sa relatívne rýchlo vrátia do funkčného stavu.
Plus č. 2. Dobrá replikácia
Ak je uzlov dostatočne, plánovač Kubernetes môže priradiť všetkým replikám rôzne uzly. Takže v prípade zlyhania uzla bude ovplyvnená len jedna replika a aplikácia zostane dostupná.
Nevýhody
Minus č. 1. Ťažšie riadenie
S veľkým počtom uzlov je ťažšie spravovať. Napríklad každý uzol Kubernetes musí komunikovať so všetkými ostatnými, to znamená, že počet spojení rastie kvadraticky a všetky tieto spojenia treba sledovať.
Kontrolér uzlov v manažéri kontrolérov Kubernetes pravidelne obchádza všetky uzly v klastri na kontrolu funkčnosti — čím viac uzlov, tým väčšia záťaž na kontrolér.
Zväčšuje sa aj záťaž na databázach etcd — každý kubelet a kube-proxy vykonáva pre et cetera (cez API), na ktorý by mal etcd prenášať aktualizácie objektu.
Celkovo každý pracovný uzol zaťažuje systémové komponenty hlavných uzlov.
Oficiálne Kubernetes podporuje klastry s . V praxi už 500 uzlov .
Na správu veľkého počtu pracovných uzlov je potrebné vybrať výkonnnejšie hlavné uzly. Napríklad, kube-up správnu veľkosť VM pre hlavný uzol v závislosti od počtu pracovných uzlov. To znamená, že čím viac pracovných uzlov, tým výkonnejšie musia byť hlavné uzly.
Na riešenie týchto špecifických problémov existujú špeciálne vývojové nástroje, ako napríklad . Tento systém umožňuje obísť obmedzenia a vytvárať klastry s obrovským počtom pracovných uzlov.
Nevýhoda č. 2. Vyššie režijné náklady
Na každom pracovnom uzle Kubernetes spúšťa súbor systémových démonov — medzi nimi sú prostredie na vykonávanie kontajnerov (napríklad Docker), kube-proxy a kubelet, vrátane cAdvisor. Všetky spolu spotrebovávajú určité fixné množstvo zdrojov.
Ak máte veľa malých uzlov, podiel týchto režijných nákladov na každom uzle je väčší. Napríklad si predstavte, že všetci systémoví démoni jedného uzla spolu používajú 0,1 jadra CPU a 0,1 GB pamäte. Ak máte jeden desajaderný uzol s 10 GB pamäte, démoni spotrebujú 1% kapacity klastra. Na druhej strane, na desiatich jednojadrových uzloch s 1 GB pamäte, démoni zoberú 10% kapacity klastra.
Tým pádom, čím menej uzlov, tým efektívnejšie sa využíva infraštruktúra.
Nevýhoda č. 3. Neefektívne využitie zdrojov
Na malých uzloch môže nastať situácia, že zvyšné fragmenty zdrojov sú príliš malé na to, aby sa im pridelila nejaká pracovná záťaž, ale ostávajú nevyužité.
Napríklad, každý pod vyžaduje 0,75 GB pamäte. Ak máte desať uzlov, a na každom je 1 GB pamäte, môžete spustiť desať podov — nakoniec na každom uzle ostane 0,25 GB nevyužitej pamäte.
To znamená, že 25% pamäte celého klastra sa míňa zbytočne.
Na veľkom uzle s 10 GB pamäte môžete spustiť 13 takých modulov — a ostane len jeden nevyužitý fragment 0,25 GB.
V tomto prípade sa míňa zbytočne len 2,5% pamäte.
Týmto spôsobom sa na veľkých uzloch optimálnejšie využívajú zdroje.
Niekoľko veľkých uzlov alebo mnoho malých?
Čo je teda lepšie: niekoľko veľkých uzlov v klastri alebo veľa malých? Ako vždy, jednoznačná odpoveď neexistuje. Mnoho závisí od typu aplikácie.
Napríklad, ak aplikácia vyžaduje 10 GB pamäte, voľba vo väčších uzloch je jasná. A ak aplikácia vyžaduje desaťnásobnú replikáciu pre vysokú dostupnosť, sotva by stálo za to riskovať a umiestniť repliky len na dvoch uzloch — v klastri by malo byť minimálne desať uzlov.
V medzičase sa rozhodujte na základe výhod a nevýhod každého variantu. Možno niektoré argumenty sú pre vašu situáciu aktuálnejšie ako iné.
A vôbec nie je nutné, aby všetky uzly mali rovnakú veľkosť. Nič vám nebráni experimentovať najprv s uzlami jednej veľkosti a potom pridať uzly inej veľkosti, kombinujúc ich v klastri. Pracovné uzly klastra Kubernetes môžu byť úplne heterogénne. Takže môžete vyskúšať výhody oboch prístupov.
Neexistuje jediný recept, každá situácia má svoje nuansy a pravdu ukáže len produkcia.
Preklad pripravila tím cloudovej platformy .
Ešte o Kubernetes: .
Zdroj: habr.com
