Kubernetes'i töönode: palju väikeseid või paar suurt?

Kubernetes klastrit luues võivad tekkida küsimused: kui palju tööjärgseid sõlmi seadistada ja millisest tüübist? Mis on parem on-premise klastrile: osta mitu võimsat serverit või kasutada oma andmekeskuses tosin vanemat masinat? Pilves on parem valida kahe neljatuumalise eksemplari asemel kaheksa ühetuumalist?

Nendele küsimustele leiate vastused artiklist Daniel Weibelilt, insenerilt ja koolitajalt Learnk8s koolitusprojekti tõlginud meeskond Mail.ru Kubernetes aaS.

Klastri maht

Üldiselt võib Kubernetes klastrit pidada suureks 'super sõlmeks'. Selle koguvõimekus on kõigi komponentide sõlmede võimsuse summa.

On mitu viisi, kuidas soovitud klastrimahtu saavutada. Näiteks vajame klastrit, mille koguvõimsus on 8 protsessorituuma ja 32 GB mälu, kuna rakenduste komplekt nõuab nii palju ressursse. Seega võib installida kaks 16 GB mäluga sõlme või neli 8 GB mäluga sõlme, kaks neljatuumalist protsessorit või neli kahetuumalist.

Siin on ainult kaks võimalikku viisi klastrite loomiseks:

Mõlemad valikud pakuvad sama suure mahutavusega klastreid, kuid allosas on neli väiksemat sõlme, samas kui ülas on kaks suuremat.

Milline variant on parem?

Sellele küsimusele vastamiseks vaatame mõlema variandi eeliseid. Oleme need kokku võtnud tabelisse.

Mõned suured sõlmed

Palju väikeseid sõlmi

Lihtsam klastrihalduse korraldamine (kui see on on-premise)

Suumimine sujuvalt

Odavam (kui on-premise)

Hind on pilves vähe erinev

Saab käivitada ressursimahukaid rakendusi

Täielik replikatsioon

Ressursse kasutatakse efektiivsemalt (vähem overhead'i süsteemide demonitele)
Klastri talitluspüsivus on kõrgem

Pange tähele, et räägime ainult töösõlmedest. Peamiste sõlmede arvu ja suuruse valik on täiesti teine teema.

Nii et arutame iga tabelis olevaid punkte lähemalt.

Esimene variant: mõned suured sõlmed

Kõige äärmuslikum variant — üks töösõlm kogu klastrime mahutavuse jaoks. Ülalpool oli see üks töösõlm 16 CPU tuuma ja 16 GB RAM-iga.

Plussid

Pluss № 1. Lihtsam haldamine
Korraga mitmete masinate haldamine on lihtsam kui terve pargi. Uuenduste ja paranduste rakendamine on kiirem ning sünkroniseerimine lihtsam. Kahtlemata on ka tõrgete arv madalam.

Pange tähele, et kõik eelnevalt öeldu kehtib teie enda riistvara ja serverite kohta, mitte pilvandmetöötluse instantside kohta.

Pilves on olukord teine. Seal haldab seda pilvandmeteenuse pakkuja. Seega ei erine kümne sõlme haldamine pilves kuigi palju ühe sõlme haldamisest.

Liikluse suunamine ja koormuse jaotamine pilve podide vahel toimub automaatselt: internetist tulev liiklus suunatakse põhikoormuse tasakaalustajale, mis suunab liikluse ühe sõlme portsjoni peale (NodePort teenus määrab sadama vahemikus 30000-32767 igas klastri sõlmes). Kube-proxy kehtestatud reeglid suunavad liikluse sõlme podi. Nii näeb see välja kümne podi puhul kahel sõlmel:

Plusspunkt Nr 2. Madalamad kulud sõlme kohta
Tugev masin on kallim, kuid hinna tõus ei ole tingimata lineaarne. Teisisõnu, kümme tuumaga serverit, millel on 10 GB mälu, on tavaliselt odavam kui kümme ühetuumalist sama mälu mahuga serverit.

Kuid pidage meeles, et see reegel ei kehti tavaliselt pilveteenuste puhul. Tõsiseltvõetavate pilveteenuse pakkujate hindade jaotuses tõusevad hinnad mahutavuse suurenemisega sageli lineaarset rada pidi.

Seega ei saa loota, et pilves oleks odavamate serverite osas sääste.

Pluss nr 3. Saate käivitada ressursinõudlikke rakendusi.
Mõned rakendused vajavad klastris jõulisi servereid. Näiteks, kui masinõppe süsteem nõuab 8 GB mälu, ei saa te seda käivitada 1 GB sõlmedel, vaid ainult juhul, kui vähemalt üks suur töö sõlm on olemas.

Miinused

Miinus nr 1. Palju pod’e iga sõlme kohta.
Kui sama ülesanne täidetakse väiksema sõlmede arvuga, on igas neist loomulikult rohkem pod’e.

See võib osutuda probleemiks.

Põhjus on selles, et iga moodul toob kaasa teatud overheadid konteinerikeskkonda (nt Docker), samuti kubelet’i ja cAdvisor’i.

Näiteks kubelet kontrollib pidevalt kõikide sõlmes olevate konteinerite elujõudlust — mida rohkem konteinereid, seda suurem on kubeleti töökoormus.

CAdvisor kogub kõigi sõlmes olevate konteinerite ressursside kasutamise statistikat, samas kui kubelet küsib seda teavet regulaarselt ja edastab selle API kaudu. Ehkki, mida rohkem konteinereid, seda rohkem tööd on nii cAdvisoril kui ka kubelet'il.

Kui moodulite arv suureneb, võib see süsteemi aeglustada ja isegi kahjustada selle usaldusväärsust.

Kubernetes'i hoidlas on mõned kaebanud, et sõlmed hüplevad olekute vahel Ready/NotReady, kuna kubeleti regulaarne kontrollimine kõigi sõlmes olevate konteinerite osas võtab liiga kaua aega.
Seetõttu soovitab Kubernetes paigutada sõlme mitte rohkem kui 110 pod'i. Sõlme jõudlusest sõltuvalt saate käivitada rohkem pod'e, kuid on keeruline ennustada, kas tekivad probleemid või kõik töötab hästi. Töökorraldust on mõistlik eelnevalt testida.

Miinus nr 2. Replikatsiooni piirang
Liigne väike sõlmede arv piirab rakenduste tõhusat replikatsiooni. Näiteks, kui teil on kõrge kättesaadavuse rakendus viie replikaga, kuid ainult kaks sõlme, siis rakenduse efektiivne replikatsiooni tase väheneb kahele.

Viit replikat saab jaotada vaid kahe sõlme vahel, ja kui üks neist ei tööta, rikutakse kokku mitu replikat.

Kui teil on viis või rohkem sõlme, käitatakse iga replika eraldi sõlmel, ja ühe sõlme tõrge eemaldab mitte rohkem kui ühe replika.

Seega võivad kõrge kättesaadavuse nõuded nõuda klastris teatud minimaalset sõlmede arvu.

Miinus № 3. Tõrgete halvemad tagajärjed
Väikese sõlmede arvu korral toob iga tõrge kaasa tõsisemaid tagajärgi. Näiteks, kui teil on vaid kaks sõlme ja üks neist ebaõnnestub, kaob kohe pool teie moodulitest.

Muidugi, Kubernetes kannab koormuse ebaõnnestunud sõlme teistesse üle. Kuid kui sõlmi on vähe, võib vabast kapasiteetest puududa. Selle tulemusena on osa teie rakendustest kättesaamatud, kuni tõrget taastatakse.

Nii et, mida rohkem sõlmesid on, seda väiksem on riistvaravigade mõju.

Miinus № 4. Suurem automaatne skaleerimine
Kuberneteses töötab pilvinfrastruktuuri automaatse skaleerimise süsteem, mis võimaldab automaatselt lisada või eemaldada sõlmi vastavalt praegustele vajadustele. Suuremate sõlmedega muutub automaatne skaleerimine järsemaks ja kohmakamaks. Näiteks kahel sõlmel uusi sõlmi lisades suureneb klastri maht kohe 50%. Ja peate nende ressursside eest maksma, isegi kui need pole teile vajalikud.

Seetõttu, kui plaanite kasutada klastri automaatset skaleerimist, siis mida vähem sõlmi on, seda paindlikumat ja odavamat skaleerimist saate.

Vaadakem nüüd väikeste sõlmede hulga eelised ja puudused.

Teine variant: palju väikeseid sõlmi

Selle lähenemise eelised tulenevad sisuliselt vastupidiste suuremate sõlmede puudustest.

Plussid

Pluss № 1. Vähem tõrke tagajärgi
Mida rohkem sõlmi, seda vähem pod'e on iga sõlme peal. Näiteks, kui teil on sada moodulit kümne sõlme peal, siis on keskmiselt kümme moodulit iga sõlme peal.

Seega, kui üks sõlm peab tõrke, kaotate vaid 10% tööhõivest. On tõenäoline, et ainult väike hulk koopiaid on mõjutatud ning rakendused jäävad üldiselt töövõimeliseks.

Lisaks on tõenäoline, et ülejäänud sõlmedel on piisavalt vabu ressursse tõrkunud sõlme tööhõive jaoks, nii et Kubernetes saab vabalt ümber planeerida pod'e ja teie rakendused naasevad suhteliselt kiiresti töötavasse olekusse.

Pluss № 2. Hea replikatsioon
Kui sõlmi on piisavalt, saavad Kubernetes'i planeerijad määrata kõikidele koopiaile erinevad sõlmed. Seega, kui sõlm kukub välja, mõjutatakse vaid ühte koopiat ja rakendus jääb kätte saadavaks.

Miinused

Miinus № 1. Raskem juhtimine
Suure hulga sõlmede juhtimine on keerulisem. Näiteks peab iga Kubernetes'i sõlm suhtlema kõikide teistega, mis tähendab, et ühenduste arv kasvab ruudselt ning kõiki neid ühendusi tuleb jälgida.

Kubernetesi kontrolleri kontrollib regulaarselt kõiki klastris olevaid sõlmi töökindluse osas — mida rohkem sõlmi, seda suurem on koormus kontrollerile.

Koormus kasvab ka etcd andmebaasile — iga kubelet ja kube-proxy kutsub esile watcher etcd jaoks (API kaudu), millele etcd peab objekti uuendusi edastama.

Kokkuvõttes koormab iga töötav sõlm süsteemi komponente peamistel sõlmedel.

Kubernetes toetab ametlikult klastreid, millel on kuni 5000 sõlme. Praktikas võivad aga juba 500 sõlme tekitada märkimisväärseid probleeme. Suurte arvu töötavate sõlmede haldamiseks tuleks valida tootlikumad peamised sõlmed. Näiteks installib kube-up.

automaatsete seadistuste kaudu õige VM suuruse peamise sõlme jaoks vastavalt töötavate sõlmede arvule. Seega, mida rohkem töötavaid sõlmi, seda tootlikumad peavad olema peamised sõlmed. Nende konkreetsete probleemide lahendamiseks on spetsiaalsed lahendused, nagu

Virtual Kubelet . See süsteem võimaldab ületada piiranguid ja luua klastreid, kus on tohutult palju töötavaid sõlmi.. See süsteem võimaldab ületada piire ja luua klastreid, milles on tohutul hulgal töönode.

Miinus nr 2. Suuremad kulutused
Iga Kubernetes'i tööjaam käivitab rikka süsteemide deemonite komplekti — nende hulka kuuluvad konteinerite töötluskeskkond (nt Docker), kube-proxy ja kubelet, sealhulgas cAdvisor. Koos tarbivad nad kindla hulga ressursse.

Kui teil on palju väikeseid tööjaamu, siis on nende kulutuste osakaal igas tööjaamas suurem. Näiteks kujutage ette, et üks tööjaam tarbib kokku 0,1 CPU südamikku ja 0,1 GB mälu. Kui teil on üks kümneaastane tööjaam, millel on 10 GB mälu, siis deemonid tarbivad 1% klastrist. Teisalt, kümnel ühesüdamikul tööjaamal, kus igaühel on 1 GB mälu, võtavad deemonid kokku 10% klastrist.

Seega, mida vähem tööjaamu, seda tõhusamalt kasutatakse infrastruktuuri.

Miinus nr 3. Ebaefektiivne ressursside kasutamine
Väikestes tööjaamades võivad ressursijäägid olla liiga väikesed, et neid mingiks töökoormuseks määrata, seetõttu jäävad nad kasutamata.

Näiteks vajab iga pod 0,75 GB mälu. Kui teil on kümme sõlme ja igas 1 GB mälu, saate käivitada kümme pod’i — seega jääb igasse sõlmesse 0,25 GB kasutamata mälu.

See tähendab, et 25% kogu klastri mälu raisatakse niisama.

Suurel sõlmel, millel on 10 GB mälu, saate käivitada 13 sellist moodulit — ja jääb alles vaid üks kasutamata 0,25 GB osa.

Sel juhul raisatakse ainult 2,5% mälu.

Seega on suurte sõlmede korral ressursid optimaalsemad.

Mõned suured sõlmed või palju väikeseid?

Nii et, mis on parem: mõned suured sõlmed klastris või palju väikeseid? Nagu alati, pole üheselt vastust. Palju sõltub rakenduse tüübist.

Näiteks, kui rakendusele on vajalik 10 GB mälu, on selge valik suurte sõlmede kasuks. Kuid kui rakendus vajab kümnekordset kopeerimist kõrge saadavuse saavutamiseks, siis ei tasu riskida, paigutades koopiad vaid kahele sõlmele — klastris peab olema vähemalt kümme sõlme.

Vaheolukordades tehke valik, lähtudes iga variandi eeliste ja puuduste kaalumisest. Võibolla on mõned argumendid teie olukorra jaoks asjakohasemad kui teised.

Ja pole sugugi vajalik, et kõik sõlmed oleksid sama suurusega. Pole midagi, mis takistaks alguses katsetamast sama suurusega sõlmedega ja seejärel lisamast erineva suurusega sõlmi, ühendades neid klastris. Kubernetes klastrite töö sildmed võivad olla täielikult heterogeensed. Seega võite proovida kombineerida mõlema lähenemise eeliseid.

Ühtset retsepti ei eksisteeri, iga olukord on eriline ja ainult tootmine näitab tõde.

Tõlge on koostatud pilveplatvormi meeskonna poolt Mail.ru Cloud Solutions.

Veel Kubernetesest: 25 kasulikku tööriista klastrite haldamiseks ja juurutamiseks.

Allikas: habr.com