Pri vytváraní klastra Kubernetes môžu vzniknúť otázky: koľko pracovných uzlov nakonfigurovať a aký typ? Čo je lepšie pre lokálny klaster: kúpiť niekoľko výkonných serverov alebo použiť tucet starých strojov vo svojom dátovom centre? Je lepšie vziať osem jednojadrových alebo dve štvorjadrové inštancie v cloude?
Odpovede na tieto otázky sú v článku. v preklade príkazu .
Kapacita klastra
Vo všeobecnosti možno klaster Kubernetes považovať za veľký „supernode“. Jeho celkový výpočtový výkon je súčtom výkonov všetkých jeho základných uzlov.
Existuje niekoľko spôsobov, ako dosiahnuť požadovaný cieľ kapacity klastra. Potrebujeme napríklad klaster s celkovou kapacitou 8 procesorových jadier a 32 GB RAM, pretože súbor aplikácií vyžaduje toľko zdrojov. Potom môžete nainštalovať dva uzly s pamäťou 16 GB alebo štyri uzly s pamäťou 8 GB, dva štvorjadrové procesory alebo štyri dvojjadrové.
Tu sú len dva možné spôsoby vytvorenia klastra:
Obe možnosti vytvárajú klaster s rovnakou kapacitou, ale spodná konfigurácia má štyri menšie uzly a horná konfigurácia má dva väčšie uzly.
Ktorá možnosť je lepšia?
Aby sme na túto otázku odpovedali, pozrime sa na výhody oboch možností. Zhrnuli sme ich do tabuľky.
Niekoľko veľkých uzlov
Veľa malých uzlov
Jednoduchšia správa klastra (ak je lokálna)
Plynulé automatické škálovanie
Lacnejšie (ak je na mieste)
Cena je trochu iná (v cloude)
Môže spúšťať aplikácie náročné na zdroje
Úplná replikácia
Prostriedky sa využívajú efektívnejšie (menšia réžia na systémových démonoch
Vyššia tolerancia chýb klastra
Upozorňujeme, že hovoríme len o pracovných uzloch. Výber počtu a veľkosti hlavných uzlov je úplne iná téma.
Poďme teda diskutovať o každom bode z tabuľky podrobnejšie.
Prvá možnosť: niekoľko veľkých uzlov
Najkrajnejšou možnosťou je jeden pracovný uzol pre celú kapacitu klastra. Vo vyššie uvedenom príklade by to bol jeden pracovný uzol so 16 jadrami CPU a 16 GB RAM.
Pros
Plus č. 1. Jednoduchšie ovládanie
Je jednoduchšie spravovať niekoľko strojov ako celú flotilu. Zavádzanie aktualizácií a opráv je rýchlejšie a synchronizácia je jednoduchšia. Menší je aj počet porúch v absolútnych číslach.
Upozorňujeme, že všetko vyššie uvedené sa vzťahuje na váš hardvér, servery a nie na cloudové inštancie.
V cloude je situácia iná. Tam sa o správu stará poskytovateľ cloudových služieb. Správa desiatich uzlov v cloude sa teda príliš nelíši od správy jedného uzla.
Smerovanie premávky a distribúcia zaťaženia medzi modulmi v cloude : prevádzka prichádzajúca z internetu sa posiela do hlavného vyrovnávača zaťaženia, ktorý preposiela prevádzku na port jedného z uzlov (služba NodePort nastavuje port v rozsahu 30000-32767 v každom uzle klastra). Pravidlá nastavené kube-proxy presmerujú prevádzku z uzla na modul. Takto to vyzerá pre desať modulov na dvoch uzloch:
Pro #2: Nižšie náklady na uzol
Výkonné auto je drahšie, no nárast ceny nemusí byť nutne lineárny. Inými slovami, jeden desaťjadrový server s 10 GB pamäte je zvyčajne lacnejší ako desať jednojadrových serverov s rovnakým množstvom pamäte.
Upozorňujeme však, že toto pravidlo zvyčajne nefunguje v cloudových službách. V súčasných cenových schémach všetkých hlavných cloudových poskytovateľov ceny rastú lineárne s kapacitou.
V cloude teda zvyčajne nemôžete ušetriť na výkonnejších serveroch.
Pro #3: Môžete spúšťať aplikácie náročné na zdroje
Niektoré aplikácie vyžadujú výkonné servery v klastri. Ak napríklad systém strojového učenia vyžaduje 8 GB pamäte, nebudete ho môcť spustiť na uzloch s veľkosťou 1 GB, ale iba s aspoň jedným veľkým pracovným uzlom.
Zápory
Nevýhoda č. 1. Veľa strukov na uzol
Ak sa rovnaká úloha vykonáva na menšom počte uzlov, potom každý z nich bude mať prirodzene viac podov.
To môže byť problém.
Dôvodom je, že každý modul zavádza určitú réžiu do prostredia kontajnera (napr. Docker), ako aj do kubelet a cAdvisor.
Napríklad kubelet pravidelne testuje všetky kontajnery na uzle na prežitie – čím viac kontajnerov, tým viac práce musí kubelet urobiť.
CAdvisor zhromažďuje štatistiky využívania zdrojov pre všetky kontajnery v uzle a kubelet pravidelne vyhľadáva tieto informácie a poskytuje ich prostredníctvom rozhrania API. Opäť viac kontajnerov znamená viac práce pre cAdvisor aj kubelet.
Ak sa počet modulov zvýši, môže to spomaliť systém a dokonca podkopať jeho spoľahlivosť.
V úložisku Kubernetes niektoré že uzly preskakujú medzi stavmi Ready/NotReady, pretože pravidelné kontroly kubeletov všetkých kontajnerov v uzle trvajú príliš dlho.
Z tohto dôvodu Kubernetes . V závislosti od výkonu uzla môžete spustiť viac modulov na uzol, ale je ťažké predpovedať, či sa vyskytnú problémy alebo všetko bude fungovať dobre. Stojí za to vyskúšať prácu vopred.
Nevýhoda č. 2. Obmedzenie replikácie
Príliš málo uzlov obmedzuje efektívny rozsah replikácie aplikácie. Napríklad, ak máte aplikáciu s vysokou dostupnosťou s piatimi replikami, ale iba dvoma uzlami, potom sa efektívny stupeň replikácie aplikácie zníži na dva.
Päť replík môže byť distribuovaných iba cez dva uzly a ak jeden z nich zlyhá, odstráni viacero replík naraz.
Ak máte päť alebo viac uzlov, každá replika sa spustí na samostatnom uzle a zlyhanie jedného uzla odstráni najviac jednu repliku.
Požiadavky na vysokú dostupnosť teda môžu vyžadovať určitý minimálny počet uzlov v klastri.
Nevýhoda č.3. Horšie následky zlyhania
Pri malom počte uzlov má každé zlyhanie vážnejšie následky. Napríklad, ak máte iba dva uzly a jeden z nich zlyhá, polovica vašich modulov okamžite zmizne.
Samozrejme, Kubernetes migruje pracovné zaťaženie z neúspešného uzla na iné. Ale ak ich je málo, tak nemusí byť dostatok voľnej kapacity. V dôsledku toho budú niektoré z vašich aplikácií nedostupné, kým nevyvoláte neúspešný uzol.
Čím viac uzlov, tým menší vplyv zlyhania hardvéru.
Nevýhoda č. 4: Viac krokov automatického škálovania
Kubernetes má systém automatického škálovania klastrov pre cloudovú infraštruktúru, ktorý vám umožňuje automaticky pridávať alebo odstraňovať uzly v závislosti od vašich aktuálnych potrieb. S väčšími uzlami sa automatické škálovanie stáva prudším a neohrabanejším. Napríklad na dvoch uzloch pridanie ďalšieho uzla okamžite zvýši kapacitu klastra o 50 %. A za tieto zdroje budete musieť zaplatiť, aj keď ich nepotrebujete.
Ak teda plánujete použiť automatické škálovanie klastrov, čím menšie sú uzly, tým flexibilnejšie a nákladovo efektívnejšie škálovanie získate.
Teraz sa pozrime na výhody a nevýhody veľkého počtu malých uzlov.
Druhá možnosť: veľa 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.
Pros
Pro #1: Menší dopad zlyhania
Čím viac uzlov, tým menej strukov na každom uzle. Napríklad, ak máte sto modulov na desať uzlov, potom každý uzol bude mať v priemere desať modulov.
Týmto spôsobom, ak jeden z uzlov zlyhá, stratíte iba 10% pracovného zaťaženia. Je pravdepodobné, že bude ovplyvnený iba malý počet replík a celková aplikácia zostane funkčná.
Okrem toho zostávajúce uzly budú mať pravdepodobne dostatok voľných zdrojov na zvládnutie pracovného zaťaženia neúspešného uzla, takže Kubernetes môže voľne preplánovať moduly a vaše aplikácie sa relatívne rýchlo vrátia do funkčného stavu.
Pro #2: Dobrá replikácia
Ak je dostatok uzlov, plánovač Kubernetes môže priradiť rôzne uzly všetkým replikám. Týmto spôsobom, ak uzol zlyhá, bude ovplyvnená iba jedna replika a aplikácia zostane dostupná.
Zápory
Nevýhoda č.1. Ťažko ovládateľný
Veľké množstvo 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 je potrebné sledovať.
Radič uzla v Kubernetes Controller Manager pravidelne prechádza všetkými uzlami v klastri, aby skontroloval stav – čím viac uzlov, tým väčšia záťaž na radič.
Rastie aj zaťaženie databázy etcd – každý hovor kubelet a kube-proxy pre etcd (cez API), do ktorého by mal etcd vysielať aktualizácie objektov.
Vo všeobecnosti každý pracovný uzol zaťažuje systémové komponenty hlavných uzlov.
Kubernetes oficiálne podporuje klastre s . V praxi je však už 500 uzlov .
Ak chcete spravovať veľký počet pracovných uzlov, mali by ste zvoliť výkonnejš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 produktívnejšie by mali byť hlavné uzly.
Na vyriešenie týchto špecifických problémov existuje špeciálny vývoj, ako napr . Tento systém vám umožňuje obchádzať obmedzenia a vytvárať klastre s obrovským počtom pracovných uzlov.
Nevýhoda č. 2: Väčšie režijné náklady.
Na každom pracovnom uzle Kubernetes spúšťa sadu systémových démonov – medzi ne patrí runtime kontajnera (napríklad Docker), kube-proxy a kubelet vrátane cAdvisor. Spoločne spotrebúvajú určité fixné množstvo zdrojov.
Ak máte veľa malých uzlov, podiel tejto réžie na každom uzle je väčší. Predstavte si napríklad, že všetky systémové démony na jednom uzle spolu využívajú 0,1 jadra CPU a 0,1 GB pamäte. Ak máte jeden desaťjadrový uzol s 10 GB pamäte, potom démoni spotrebujú 1 % kapacity klastra. Na druhej strane, na desiatich jednojadrových uzloch s 1 GB pamäte si démoni zoberú 10 % kapacity klastra.
Teda čím menej uzlov, tým efektívnejšie sa infraštruktúra využíva.
Nevýhoda č.3. Neefektívne využívanie zdrojov
Na malých uzloch sa môže stať, že zostávajúce časti prostriedkov sú príliš malé na to, aby sa im priradilo akékoľvek pracovné zaťaženie, takže zostanú nevyužité.
Napríklad každý modul vyžaduje 0,75 GB pamäte. Ak máte desať uzlov, každý s 1 GB pamäte, môžete spustiť desať modulov, pričom každému uzlu zostane 0,25 GB nevyužitej pamäte.
To znamená, že 25 % pamäte celého klastra je premrhaných.
Na veľkom uzle s 10 GB pamäte môžete spustiť 13 týchto modulov – a zostane len jeden nevyužitý fragment 0,25 GB.
V tomto prípade sa stratí iba 2,5 % pamäte.
Na väčších uzloch sa teda zdroje využívajú optimálnejšie.
Niekoľko veľkých uzlov alebo veľa 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. Veľa závisí od typu aplikácie.
Napríklad, ak aplikácia vyžaduje 10 GB pamäte, väčšie uzly sú jasnou voľbou. A ak aplikácia vyžaduje desaťnásobnú replikáciu pre vysokú dostupnosť, sotva sa oplatí riskovať umiestnenie replík len na dva uzly – v klastri musí byť minimálne desať uzlov.
V prechodných situáciách si vyberte na základe výhod a nevýhod každej možnosti. Možno sú niektoré argumenty pre vašu situáciu relevantnejšie ako iné.
A vôbec nie je potrebné, aby všetky uzly mali rovnakú veľkosť. Nič vám nebráni najskôr experimentovať s uzlami rovnakej veľkosti, potom k nim pridať uzly inej veľkosti a spojiť ich do klastra. Pracovné uzly v klastri Kubernetes môžu byť úplne heterogénne. Môžete sa teda pokúsiť spojiť výhody oboch prístupov.
Neexistuje jediný recept a každá situácia má svoje vlastné nuansy a iba výroba ukáže pravdu.
Preklad pripravil tím cloudovej platformy .
Viac o Kubernetes: .
Zdroj: hab.com