Kubernetes'i töönode: palju väikesi või mõned suured?

Kubernetes klastrit luues võivad tekkida küsimused: kui palju töökohti ja millist tüüpi seadmeid seadistada? Mis on parem on-premise klastrile: osta mitu võimsat serverit või kasutada kümmet vana masinat oma andmekeskuses? Ja pilves on parem juuda kahe neljatuumalise instantsi või kaheksa ühetuumalist?

Nendele küsimustele leiate vastused artiklist Daniel Wybel, insener ja õpetaja õppeprojektis Learnk8s tõlgib meeskond Kubernetes aaS Mail.ru-lt.

Klastri võimekus

Üldiselt võib Kubernetes klastrit pidada suureks "super-sõlmeks". Selle kogu arvutusvõimsus on kõikide komponentide sõlmede võimsuste summa.

On mitmeid viise soovitud klastrivõimekuse saavutamiseks. Näiteks, kui me vajame klastrit, mille koguvõimsus on 8 protsessorituuma ja 32 GB RAM-i, kuna rakenduste komplekt nõuab selliseid ressursse. Siis võiksime paigaldada kaks sõlme, millel on 16 GB mälu, või neli sõlme, millel on 8 GB mälu, kaks neljatuumalist protsessorit või neli kahetuumalist.

Siin on ainult kaks võimalikku viisi klastri loomiseks:

Mõlemad valikud annavad sama võimekusega klastrit, kuid allosas on neli väiksemat sõlme, samas kui ülalosas on kaks suuremat.

Milline variant on parem?

Küsimuse vastamiseks vaatame mõlema variandi eeliseid. Oleme need kokku pannud tabelisse.

Mitu suurt sõlme

Palju väikseid sõlme

Klastri haldamine on lihtsam (kui see on on-premise)

Suumimine on sujuvam

Odavam (kui see on on-premise)

Hind ei erine palju (pilves)

Võib käitada ressursinõudlikke rakendusi

Täielik replikatsioon

Ressursse kasutatakse efektiivsemalt (vähem üleliigset süsteemide demonite peale)
Klastri talitluspüsivus on kõrgem

Pange tähele, et räägime ainult töökohti. Pea-sõlmede arvu ja suuruse valimine on täiesti teine teema.

Nii et arutame iga punkti tabelist lähemalt.

Esimene variant: mitu suurt sõlme

Kõige ekstreemsem variant on üks töökohta kogu klastrivõimekuse jaoks. Ülaltoodud näites oleks see üks töökohta, millel on 16 protsessori tuuma ja 16 GB RAM-i.

Plussid

Pluss № 1. Halduse lihtsus
Mitme masina juhtimine on lihtsam kui terve pargi. Kiiremini on võimalik rakendada uuendusi ja parandusi, lihtsam on sünkroniseerida. Absoluutarvudes on ka tõrkeid vähem.

Pange tähele, et kõik eelnevalt öeldu kehtib teie riistvara, teie serverite kohta, mitte pilveinstantside kohta.

Pilves on olukord teine. Seal tegeleb haldusega pilveteenuse pakkuja. Seega ei erine kümne sõlme haldamine pilves eriti ühe sõlme haldamisest.

Liiklustee suunamine ja koormuse jaotamine pod'ide vahel pilves toimub automaatselt: internetist tulev liiklus suunatakse peamise koormuse tasakaalustajani, mis suunab liikluse ühe sõlme pordile (NodePort teenus määrab pordi vahemikus 30000-32767 igas klastri sõlmest). Kube-proxy'de seadistatud reeglid suunavad liikluse sõlmest pod'i. Nii näeb see välja kümne pod'i jaoks kahes sõlmes:

Pluss № 2. Vähem kulutusi sõlme kohta
Võimas masin on kallim, kuid hinna tõus ei ole tingimata lineaarne. Teisisõnu, üks kümne tuumaga server, millel on 10 GB mälu, on tavaliselt odavam kui kümme ühesüdamikku, millel on sama palju mälu.

Kuid pidage meeles, et see reegel ei kehti tavaliselt pilveteenustes. Aktuaalsetes hinnakujundusskeemides tõusevad kõikide peamiste pilveteenuse pakkujate hinnad lineaarsete hindadega koos mahutavuse suurendamisega.

Seega ei saa pilves tavaliselt säästa võimsamate serverite arvelt.

Pluss № 3. Saate käivitada ressursimahukaid rakendusi
Mõned rakendused vajavad klastris võimsaid servereid. Näiteks kui masinõppe süsteem vajab 8 GB mälu, ei saa te seda käivitada 1 GB sõlmedes, vaid ainult siis, kui teil on vähemalt üks suur töö sõlm.

Miinused

Miinus № 1. Palju pod'e sõlme kohta
Kui sama ülesanne täidetakse väiksemas sõlmede arvus, siis on igas neist loomulikult rohkem pod'e.

See võib muutuda probleemiks.

Põhjus on selles, et iga moodul toob kaasa teatud kulud konteinerite töötluskeskkonnale (näiteks Docker), samuti kubelet'ile ja cAdvisor'ile.

Näiteks uurib kubelet regulaarselt kõiki sõlmes olevaid konteinerite elujõulisust — mida rohkem konteinerid, seda rohkem tööd on kubelet'il.

CAdvisor kogub ressursside kasutamise statistikat kõikide konteinerite kohta sõlmes, samas kui kubelet küsib regulaarselt neid andmeid ning põhipunktena edastab selle läbi API. Jällegi, mida rohkem on konteinerite, seda rohkem tööd on nii cAdvisoril kui kubelet'il.

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

Kubernetes'e repositooriumis on mõned kaebanud, et sõlmed hüppavad Ready/NotReady staatuste vahel, kuna kubelet'i regulaarne kontrollimine kõigi sõlmes olevate konteinerite üle võtab liiga palju aega.
Sel põhjusel soovitab Kubernetes paigutada mitte rohkem kui 110 pod'i sõlme. Sõlme jõudlusest sõltuvalt võite sõlmes käitada rohkem pod'e, kuid on raske ennustada, kas tekivad probleemid või kõik töötab hästi. Soovitav on eelnevalt testida tööprotsessi.

Miinus nr 2. Replikatsiooni piirang
Liiga 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 tõhus replikatsiooni määr väheneb kaheks.

Viit replikat saab jaotada ainult kahele sõlmeks ja kui üks neist ei tööta, hävitab see korraga mitu replikat.

Kui teil on viis või enam sõlme, siis igat replikat töötatakse eraldi sõlmes, ja ühe sõlme rike eemaldab maksimaalselt ühe replikat.

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

Miinus nr 3. Paigaldamise tagajärjed halvenevad
Väikese sõlmede arvu puhul toob iga rike kaasa tõsisemaid tagajärgi. Näiteks kui teil on ainult kaks sõlme ja üks neist ebaõnnestub, kaob korraga pool teie moodulitest.

Loomulikult viib Kubernetes töökoormuse ebaõnnestunud sõlmest üle teistele. Kuid kui neid on vähe, ei pruugi piisavat vaba mahtu olla. Selle tulemusena jäävad mõned teie rakendustest kättesaamatuks, kuni te ei käivita ebaõnnestunud sõlme.

Nii et mida rohkem sõlmesid on, seda vähem on riistvara rikete mõju.

Miinus nr 4. Rohkem sammude automaatne skaleerimine
Kubernetes'is töötab automaatne klastrite skaleerimise süsteem pilveinfrastruktuuris, mis võimaldab automaatselt lisada või eemaldada sõlmi vastavalt hetke vajadustele. Suuremate sõlmede puhul muutub skaleerimine järsemaks ja kohmakamaks. Näiteks kahe sõlmega, lisades ühe lisasõlme, suurendatakse klastrimahtu kohe 50% võrra. Ja peate nende ressursside eest maksma, isegi kui need teile ei ole vajalikud.

Seega, kui plaanite kasutada klastrite automaatset skaleerimist, siis mida väiksemad on sõlmed, seda paindlikum ja ökonoomsem skaleerimine te saavutate.

Nüüd vaatame üles väikeste sõlmede arvu eeliseid ja puudusi.

Teine variant: hulk väikeseid sõlmi

Selle lähenemise eelised tulenevad põhimõtteliselt vastupidise variandi, st väheste suurte sõlmede, puudustest.

Plussid

Plusspunkt № 1. Vähem katkestamise tagajärgi
Mida rohkem on sõlmi, seda vähem pod'e on igas sõlmes. Näiteks, kui teil on sada moodulit kümnes sõlmes, siis keskmiselt on igas sõlmes kümme moodulit.

Seega, kui üks sõlm ebaõnnestub, kaotate vaid 10% töökoormusest. On tõenäoline, et mõjutatud on vaid väike arv replikaate ja rakendused jäävad üldiselt töökindlaks.

Lisaks on tõenäoliselt ülejäänud sõlmedes piisavalt vabu ressursse katkise sõlme töökoormuse jaoks, nii et Kubernetes võib vabalt ümber planeerida pod’e ja teie rakendused naasevad suhteliselt kiiresti funktsionaalsesse olekusse.

Plusspunkt № 2. Hea replikatsioon
Kui on piisavalt sõlmi, siis Kubernetes'i ajakava saab määrata kõigile replikatele erinevad sõlmed. Seega, kui sõlm ebaõnnestub, mõjutatakse vaid üht replikat ja rakendus jääb kergesti kätte saadavaks.

Miinused

Miinuspunkt № 1. Raskem juhtimine
Suure hulga sõlmede haldamine on keerulisem. Näiteks peab iga Kubernetes'i sõlm suhtlema kõigi teistega, seega kasvab seoste arv ruudus ja kõik need seosed tuleb jälgida.

Sõlme kontrollija Kubernetes'i kontrollijate halduris kontrollib regulaarselt kõiki klastris oleva sõlmi nende toimivuse kontrollimiseks — mida rohkem sõlmi, seda suurem on koormus kontrollijale.

Koormus suurendab ka andmebaasi etcd — iga kubelet ja kube-proxy kutsub watcher etcd (API kaudu), millele etcd peab objekti värskendusi edastama.

Üldiselt koormab iga töönode süsteemikomponente peamistel nodidel.

Ametlikult toetab Kubernetes klastreid, millel on kuni 5000 nodi.Praktiliselt võivad aga juba 500 nodi tekitada mitte­triviaalsetes probleemides..

Suurte töönode arvu haldamiseks tuleks valida võimekamad peanodid. Näiteks kube-up paigaldab automaatselt õige VM suuruse peanodile sõltuvalt töönode arvust. See tähendab, et mida rohkem on töönode, seda võimekamad peanodid peavad olema.

Nende spetsiifiliste probleemide lahendamiseks on olemas spetsiaalsed lahendused, nagu Virtual Kubelet.See süsteem võimaldab mööda minna piirangutest ja luua klastreid, millel on tohutu hulk töönode.

Miinus nr 2. Suurem ülekandeteenus.
Igal töönode'l käivitab Kubernetes komplekti süsteemideemoone - nende hulka kuuluvad konteinerite töötluskeskkond (nt Docker), kube-proxy ja kubelet, sealhulgas cAdvisor. Koos tarbivad nad teatud fikseeritud hulga ressursse.

Kui teil on palju väikeseid node, on iga nodi ülekandeteenuse osakaal suurem. Näiteks kujutage ette, et kõik ühe nodi süsteemi demonid koos kasutavad 0,1 CPU tuumat ja 0,1 GB mälu. Kui teil on üks kümne tuumaga node, millel on 10 GB mälu, siis demonid tarbivad 1% klastri mahust. Teisest küljest, kümnel ühe tuumaga nodil, millel on 1 GB mälu, võtavad demonid 10% klastri mahust.

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

Miinus nr 3. Ebaefektiivne ressursside kasutamine.
Väikestes node'ides võib tekkida olukord, kus allesjäänud ressursifragmendid on liiga väikesed, et neile mingit koormust määrata, seega jäävad nad kasutamata.

Näiteks, iga pod vajab 0,75 GB mälu. Kui teil on kümme nodi ja igal on 1 GB mälu, saab käivitada kümme pod'i - tulemuseks jääb igasse nodi 0,25 GB kasutamata mälu.

See tähendab, et 25% kogu klastri mälust läheb raisku.

Suuril nodil, millel on 10 GB mälu, saate käivitada 13 sellist moodulit - ja jääb alles vaid üks 0,25 GB kasutamata fragment.

Sel juhul kulu on ainult 2,5% mälu.

Seega, suurte sõlmede puhul jaotatakse ressursse optimaalsemalt.

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

Nii et mis on parem: mitu suurt sõlme klastris või palju väikeseid? Nagu alati, üheselt vastust ei ole. Palju sõltub rakenduse tüübist.

Näiteks, kui rakendusel on vaja 10 GB mälu, on selge valik suurte sõlmede kasuks. Kui aga rakendus vajab kümnekordset kopeerimist kõrge kättesaadavuse tagamiseks, oleks riskantne paigutada koopiad vaid kahele sõlmele — klastries peab olema vähemalt kümme sõlme.

Vahepealsetes olukordades tehke valik, lähtudes iga variandi eelistest ja puudustest. Võib-olla on mõned argumendid teie olukorra jaoks aktuaalsemad kui teised.

Ja pole sugugi kohustuslik, et kõik sõlmed oleksid sama suurusega. Miski ei takista teil alguses eksperimenteerida sõlmedega, mis on sama suurusega, seejärel lisada neile erineva suurusega sõlmed, kombineerides neid klastris. Kubernetes'e tööks mõeldud sõlmed võivad olla täiesti heterogeensed. Seega, võite proovida mõlema lähenemise eeliseid.

Ühtegi kindlat retsepti ei ole, iga olukord on unikaalne ning ainult tootmisprotsess näitab tõde.

Tõlge on koostanud pilveteenuse meeskond Mail.ru Pilve Lahendused.

Veel Kubernetes'est: 25 kasulikku tööriista klastrite haldamiseks ja juurutamiseks.

Allikas: habr.com