Pri ustvarjanju gruče Kubernetes se lahko pojavijo vprašanja: koliko delovnih vozlišč konfigurirati in kakšne vrste? Kaj je bolje za lokalno gručo: kupiti več zmogljivih strežnikov ali uporabiti ducat starih strojev v svojem podatkovnem centru? Ali je bolje vzeti osem enojedrnih ali dve štirijedrni instanci v oblaku?
Odgovori na ta vprašanja so v članku. v prevodu ukaza .
Zmogljivost grozda
Na splošno si lahko gručo Kubernetes predstavljamo kot veliko "supervozlišče". Njegova skupna računalniška moč je vsota moči vseh njegovih sestavnih vozlišč.
Obstaja več načinov za doseganje želene ciljne zmogljivosti gruče. Na primer, potrebujemo gručo s skupno zmogljivostjo 8 procesorskih jeder in 32 GB RAM-a, ker nabor aplikacij zahteva toliko virov. Nato lahko namestite dve vozlišči s 16 GB pomnilnika ali štiri vozlišča z 8 GB pomnilnika, dva štirijedrna procesorja ali štiri dvojedrne.
Tu sta samo dva možna načina za ustvarjanje gruče:
Obe možnosti ustvarita gručo z enako zmogljivostjo, vendar ima spodnja konfiguracija štiri manjša vozlišča, zgornja konfiguracija pa dve večji vozlišči.
Katera možnost je boljša?
Za odgovor na to vprašanje si poglejmo prednosti obeh možnosti. Strnili smo jih v tabelo.
Več velikih vozlišč
Veliko majhnih vozlov
Lažje upravljanje gruče (če je na mestu uporabe)
Gladko samodejno skaliranje
Ceneje (če je na mestu uporabe)
Cena je malo drugačna (v oblaku)
Lahko izvaja aplikacije, ki zahtevajo veliko virov
Popolna replikacija
Viri se uporabljajo učinkoviteje (manj obremenitev sistemskih demonov
Višja toleranca napak gruče
Upoštevajte, da govorimo samo o delovnih vozliščih. Izbira števila in velikosti glavnih vozlišč je povsem druga tema.
Torej, poglejmo podrobneje vsako točko iz tabele.
Prva možnost: več velikih vozlišč
Najbolj skrajna možnost je eno delovno vozlišče za celotno zmogljivost gruče. V zgornjem primeru bi bilo to eno samo delovno vozlišče s 16 jedri CPU in 16 GB RAM-a.
Pros
Plus št. 1. Lažje upravljanje
Проще управлять несколькими машинами, чем целым парком. Быстрее накатывать обновления и исправления, проще синхронизировать. Количество сбоев в абсолютных цифрах тоже меньше.
Upoštevajte, da vse zgoraj navedeno velja za vašo strojno opremo, vaše strežnike in ne za primerke v oblaku.
V oblaku je situacija drugačna. Tam za upravljanje skrbi ponudnik storitev v oblaku. Tako se upravljanje desetih vozlišč v oblaku ne razlikuje veliko od upravljanja enega vozlišča.
Usmerjanje prometa in porazdelitev obremenitve med sklopi v oblaku : promet, ki prihaja iz interneta, se pošlje glavnemu izenačevalniku obremenitve, ki posreduje promet na vrata enega od vozlišč (storitev NodePort nastavi vrata v območju 30000-32767 v vsakem vozlišču gruče). Pravila, ki jih nastavi kube-proxy, preusmerjajo promet iz vozlišča v blok. Tako je videti za deset podov na dveh vozliščih:
Pro #2: Manjši stroški na vozlišče
Zmogljiv avto je dražji, ni pa nujno, da je rast cene linearna. Z drugimi besedami, en desetjedrni strežnik z 10 GB pomnilnika je običajno cenejši od desetih enojedrnih strežnikov z enako količino pomnilnika.
Vendar upoštevajte, da to pravilo običajno ne deluje v storitvah v oblaku. V trenutnih cenovnih shemah vseh večjih ponudnikov oblaka cene rastejo linearno z zmogljivostjo.
Tako v oblaku običajno ne morete varčevati na zmogljivejših strežnikih.
Pro #3: Zaženete lahko aplikacije, ki zahtevajo veliko virov
Nekatere aplikacije zahtevajo zmogljive strežnike v gruči. Na primer, če sistem za strojno učenje zahteva 8 GB pomnilnika, ga ne boste mogli zagnati na 1 GB vozliščih, ampak le z vsaj enim velikim delovnim vozliščem.
Proti
Pomanjkljivost št. 1. Veliko podov na vozlišče
Če se ista naloga izvaja na manj vozliščih, bo vsako od njih seveda imelo več podov.
To bi lahko bila težava.
Razlog je v tem, da vsak modul uvaja nekaj dodatnih stroškov za izvajalno okolje vsebnika (npr. Docker), pa tudi za kubelet in cAdvisor.
Na primer, kubelet redno preverja vse vsebnike na vozlišču za preživetje – več kot je vsebnikov, več dela mora opraviti kubelet.
CAdvisor zbira statistične podatke o uporabi virov za vse vsebnike na vozlišču, kubelet pa redno poizveduje po teh informacijah in jih zagotavlja prek API-ja. Še enkrat, več vsebnikov pomeni več dela za cAdvisor in kubelet.
Če se število modulov poveča, lahko upočasni sistem in celo zmanjša njegovo zanesljivost.
V repozitoriju Kubernetes nekaj da vozlišča skačejo med stanjema Ready/NotReady, ker redna preverjanja kubelet vseh vsebnikov na vozlišču trajajo predolgo.
Iz tega razloga Kubernetes . Odvisno od zmogljivosti vozlišča lahko zaženete več podov na vozlišče, vendar je težko predvideti, ali bodo težave ali bo vse delovalo v redu. Delo je vredno preizkusiti vnaprej.
Pomanjkljivost št. 2. Omejitev replikacije
Premalo vozlišč omejuje učinkovit obseg podvajanja aplikacije. Na primer, če imate aplikacijo z visoko razpoložljivostjo s petimi replikami, vendar samo dvema vozliščema, se efektivna stopnja podvajanja aplikacije zmanjša na dve.
Pet replik je mogoče porazdeliti samo med dvema vozliščema in če eno od njih odpove, bo odstranilo več replik hkrati.
Če imate pet vozlišč ali več, se bo vsaka replika izvajala na ločenem vozlišču in napaka enega vozlišča bo odstranila največ eno repliko.
Tako lahko zahteve glede visoke razpoložljivosti zahtevajo določeno minimalno število vozlišč v gruči.
Slabost št. 3. Hujše posledice neuspeha
Pri majhnem številu vozlišč ima vsaka okvara resnejše posledice. Na primer, če imate samo dve vozlišči in eno od njiju odpove, polovica vaših modulov takoj izgine.
Seveda bo Kubernetes delovno obremenitev prenesel iz okvarjenega vozlišča na druga. Če pa jih je malo, potem morda ne bo dovolj prostih zmogljivosti. Posledično nekatere vaše aplikacije ne bodo na voljo, dokler ne prikažete neuspešnega vozlišča.
Torej, več kot je vozlišč, manjši je vpliv okvar strojne opreme.
Pomanjkljivost #4: Več korakov samodejnega skaliranja
Kubernetes ima sistem za samodejno skaliranje gruče za infrastrukturo v oblaku, ki vam omogoča samodejno dodajanje ali odstranjevanje vozlišč glede na vaše trenutne potrebe. Z večjimi vozlišči postane samodejno skaliranje bolj nenadno in okorno. Na primer, na dveh vozliščih bo dodajanje dodatnega vozlišča takoj povečalo zmogljivost gruče za 50 %. In za ta sredstva boste morali plačati, tudi če jih ne potrebujete.
Če torej nameravate uporabiti samodejno skaliranje gruče, manjša kot so vozlišča, bolj prilagodljivo in stroškovno učinkovito skaliranje boste dobili.
Zdaj pa si poglejmo prednosti in slabosti velikega števila majhnih vozlišč.
Druga možnost: veliko majhnih vozlišč
Prednosti tega pristopa v bistvu izhajajo iz slabosti nasprotne možnosti z več velikimi vozlišči.
Pros
Плюс № 1. Меньше последствия сбоя
Več vozlišč, manj podov na vsakem vozlišču. Na primer, če imate sto modulov na deset vozlišč, bo imelo vsako vozlišče povprečno deset modulov.
Na ta način, če eno od vozlišč odpove, izgubite le 10 % delovne obremenitve. Verjetno bo prizadeto le majhno število replik in bo celotna aplikacija ostala delujoča.
Poleg tega bodo preostala vozlišča verjetno imela dovolj prostih virov za obvladovanje delovne obremenitve okvarjenega vozlišča, tako da lahko Kubernetes prosto prerazporedi pode in vaše aplikacije se bodo relativno hitro vrnile v funkcionalno stanje.
Pro #2: Dobra replikacija
Če je dovolj vozlišč, lahko razporejevalnik Kubernetes dodeli različna vozlišča vsem replikam. Na ta način, če vozlišče odpove, bo prizadeta samo ena replika in aplikacija bo ostala na voljo.
Proti
Pomanjkljivost št. 1. Težko nadzorovati
Veliko število vozlišč je težje upravljati. Na primer, vsako vozlišče Kubernetes mora komunicirati z vsemi drugimi, to pomeni, da število povezav raste kvadratno in vsem tem povezavam je treba slediti.
Krmilnik vozlišč v Kubernetes Controller Managerju redno hodi skozi vsa vozlišča v gruči, da preveri zdravje – več vozlišč, večja je obremenitev krmilnika.
Narašča tudi obremenitev podatkovne baze etcd - kliče vsak kubelet in kube-proxy za etcd (preko API-ja), ki naj bi mu etcd oddajal posodobitve objektov.
Na splošno vsako delovno vozlišče dodatno obremeni sistemske komponente glavnih vozlišč.
Kubernetes uradno podpira grozde z . Vendar pa je v praksi že 500 vozlišč .
Za upravljanje velikega števila delovnih vozlišč bi morali izbrati močnejša glavna vozlišča. Na primer kube-up pravilna velikost VM za glavno vozlišče glede na število delovnih vozlišč. To pomeni, da več kot je delovnih vozlišč, bolj produktivna morajo biti glavna vozlišča.
Za reševanje teh specifičnih problemov obstajajo posebni dogodki, kot je npr . Ta sistem vam omogoča, da obidete omejitve in zgradite gruče z ogromnim številom delovnih vozlišč.
Slabost št. 2: Več režijskih stroškov.
Na vsakem delovnem vozlišču Kubernetes izvaja nabor sistemskih demonov - ti vključujejo izvajalno okolje vsebnika (kot je Docker), kube-proxy in kubelet, vključno s cAdvisor. Skupaj porabijo določeno fiksno količino virov.
Če imate veliko majhnih vozlišč, je delež teh režijskih stroškov na vsakem vozlišču večji. Na primer, predstavljajte si, da vsi sistemski demoni na enem vozlišču skupaj uporabljajo 0,1 jedra CPU in 0,1 GB pomnilnika. Če imate eno desetjedrno vozlišče z 10 GB pomnilnika, potem demoni porabijo 1 % zmogljivosti gruče. Po drugi strani pa bodo na desetih enojedrnih vozliščih z 1 GB pomnilnika demoni zavzeli 10 % zmogljivosti gruče.
Torej, manj vozlišč, bolj učinkovito se uporablja infrastruktura.
Pomanjkljivost št. 3. Neučinkovita poraba virov
Na majhnih vozliščih se lahko zgodi, da so preostali kosi virov premajhni, da bi jim lahko dodelili kakršno koli delovno obremenitev, zato ostanejo neuporabljeni.
Na primer, vsak pod zahteva 0,75 GB pomnilnika. Če imate deset vozlišč, od katerih ima vsako 1 GB pomnilnika, lahko zaženete deset sklopov, pri čemer bo vsakemu vozlišču ostalo 0,25 GB neuporabljenega pomnilnika.
To pomeni, da je izgubljenih 25 % celotnega pomnilnika gruče.
Na velikem vozlišču z 10 GB pomnilnika lahko zaženete 13 teh modulov - in ostal bo le en neuporabljen fragment velikosti 0,25 GB.
V tem primeru se porabi le 2,5 % pomnilnika.
Tako se viri uporabljajo bolj optimalno na večjih vozliščih.
Več velikih vozlišč ali veliko majhnih?
Torej, kaj je bolje: nekaj velikih vozlišč v gruči ali veliko majhnih? Kot vedno ni jasnega odgovora. Veliko je odvisno od vrste aplikacije.
Na primer, če aplikacija zahteva 10 GB pomnilnika, so večja vozlišča očitna izbira. In če aplikacija za visoko razpoložljivost zahteva desetkratno replikacijo, ni vredno tvegati postavitve replik na samo dve vozlišči – v gruči mora biti vsaj deset vozlišč.
V vmesnih situacijah se odločite na podlagi prednosti in slabosti vsake možnosti. Morda so nekateri argumenti bolj pomembni za vašo situacijo kot drugi.
In sploh ni potrebno, da so vsa vozlišča enake velikosti. Nič vam ne preprečuje, da najprej eksperimentirate z vozlišči enake velikosti, nato pa jim dodate vozlišča drugačne velikosti in jih združite v gručo. Delovna vozlišča v gruči Kubernetes so lahko popolnoma heterogena. Tako lahko poskusite združiti prednosti obeh pristopov.
Enotnega recepta ni in vsaka situacija ima svoje nianse in šele produkcija bo pokazala resnico.
Prevod je pripravila ekipa platforme v oblaku .
Več o Kubernetesu: .
Vir: www.habr.com