Kubernetese klastri loomisel võib tekkida küsimusi: mitu töötaja sõlme konfigureerida ja mis tüüpi? Mis on kohapealse klastri jaoks parem: osta mitu võimsat serverit või kasutada oma andmekeskuses tosinat vana masinat? Kas on parem võtta pilves kaheksa ühetuumalist või kaks neljatuumalist eksemplari?
Vastused neile küsimustele leiate artiklist. käsu tõlkes .
Klastri võimsus
Üldiselt võib Kubernetese klastrit pidada suureks "supersõlmeks". Selle koguarvutusvõimsus on kõigi selle moodustavate sõlmede võimsuste summa.
Soovitud klastri võimsuse eesmärgi saavutamiseks on mitu võimalust. Näiteks vajame klastrit, mille koguvõimsus on 8 protsessorituuma ja 32 GB muutmälu, kuna rakenduste komplekt nõuab nii palju ressursse. Seejärel saate 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 vaid kaks võimalikku viisi klastri loomiseks.
Mõlemad valikud loovad sama võimsusega klastri, kuid alumisel konfiguratsioonil on neli väiksemat sõlme ja ülemisel konfiguratsioonil kaks suuremat sõlme.
Kumb variant on parem?
Sellele küsimusele vastamiseks vaatame mõlema võimaluse eeliseid. Oleme need kokku võtnud tabelis.
Mitu suurt sõlme
Paljud väikesed sõlmed
Lihtsam klastri haldamine (kui see on kohapeal)
Sujuv automaatne skaleerimine
Odavam (kui see on kohapeal)
Hind on veidi erinev (pilves)
Võib käivitada ressursimahukaid rakendusi
Täielik replikatsioon
Ressursse kasutatakse tõhusamalt (süsteemideemonite jaoks kulub vähem
Kõrgem klastri veataluvus
Pange tähele, et me räägime ainult töötajate sõlmedest. Põhisõlmede arvu ja suuruse valimine on hoopis teine teema.
Niisiis, arutame iga tabeli punkti üksikasjalikumalt.
Esimene võimalus: mitu suurt sõlme
Kõige äärmuslikum variant on üks töötaja sõlm kogu klastri võimsuse jaoks. Ülaltoodud näites oleks see üks töötaja sõlm 16 protsessorituuma ja 16 GB muutmäluga.
Plusse
Pluss nr 1. Lihtsam juhtimine
Mõnda masinat on lihtsam hallata kui tervet masinaparki. Värskenduste ja paranduste juurutamine on kiirem ning sünkroonimine lihtsam. Rikete arv absoluutarvudes on samuti väiksem.
Pange tähele, et kõik ülaltoodu kehtib teie riistvara, serverite, mitte pilvejuhtumite kohta.
Pilves on olukord erinev. Seal tegeleb haldamisega pilveteenuse pakkuja. Seega ei erine kümne sõlme haldamine pilves palju ühe sõlme haldamisest.
Liikluse marsruutimine ja koormuse jaotus pilves olevate kaunade vahel : Internetist tulev liiklus suunatakse põhikoormuse tasakaalustajasse, mis suunab liikluse edasi ühe sõlme porti (teenus NodePort seab pordi vahemikku 30000-32767 igas klastri sõlmes). Kube-puhverserveri seatud reeglid suunavad liikluse sõlmest moodulisse. Kahe sõlme kümne kauna puhul näeb see välja järgmine:
Pro nr 2: väiksem kulu sõlme kohta
Võimas auto on kallim, kuid hinnatõus ei pruugi olla lineaarne. Ehk siis üks kümnetuumaline 10 GB mäluga server on tavaliselt odavam kui kümme sama mälumahuga ühetuumalist serverit.
Kuid pange tähele, et see reegel tavaliselt pilveteenustes ei tööta. Kõigi suuremate pilveteenuse pakkujate praegustes hinnaskeemides tõusevad hinnad lineaarselt võimsusega.
Seega ei saa pilves tavaliselt võimsamatele serveritele salvestada.
Pro nr 3: saate käitada ressursimahukaid rakendusi
Mõned rakendused nõuavad võimsaid servereid klastris. Näiteks kui masinõppesüsteem vajab 8 GB mälu, ei saa te seda käitada 1 GB sõlmedes, vaid ainult vähemalt ühe suure töötaja sõlmega.
Miinused
Puudus nr 1. Palju kaunasid sõlme kohta
Kui sama ülesanne sooritatakse vähemate sõlmedega, on igal neist loomulikult rohkem kaunasid.
See võib olla probleem.
Põhjus on selles, et iga moodul lisab konteineri käitusajale (nt Docker) ning kubeletile ja cAdvisorile teatud üldkulusid.
Näiteks uurib kubelet regulaarselt kõiki sõlme mahuteid, et tagada nende säilivus – mida rohkem konteinereid, seda rohkem tööd peab kubelet tegema.
CAdvisor kogub ressursikasutuse statistikat kõigi sõlme konteinerite kohta ning kubelet küsib seda teavet regulaarselt ja pakub seda API kaudu. Jällegi tähendab rohkem konteinereid rohkem tööd nii cAdvisori kui ka kubeleti jaoks.
Kui moodulite arv suureneb, võib see süsteemi aeglustada ja isegi õõnestada selle töökindlust.
Kubernetese hoidlas mõned et sõlmed hüppavad Ready/NotReady olekute vahel, kuna sõlme kõigi konteinerite regulaarne kubeleti kontroll võtab liiga kaua aega.
Sel põhjusel Kubernetes . Sõltuvalt sõlme jõudlusest saate ühe sõlme kohta käitada rohkem podisid, kuid on raske ennustada, kas tekib probleeme või kõik töötab hästi. Tööd tasub eelnevalt katsetada.
Puudus nr 2. Replikatsiooni piirang
Liiga vähe sõlme piirab rakenduse replikatsiooni tõhusat ulatust. Näiteks kui teil on kõrge kättesaadavusega rakendus, millel on viis koopiat, kuid ainult kaks sõlme, vähendatakse rakenduse efektiivset replikatsiooniastet kahele.
Viit koopiat saab jagada ainult kahe sõlme vahel ja kui üks neist ebaõnnestub, eemaldab see korraga mitu koopiat.
Kui teil on viis või enam sõlme, töötab iga koopia eraldi sõlmes ja ühe sõlme rike eemaldab maksimaalselt ühe koopia.
Seega võivad kõrged käideldavusnõuded nõuda klastris teatud minimaalset arvu sõlme.
Puudus nr 3. Ebaõnnestumise hullemad tagajärjed
Väikese arvu sõlmede korral on igal ebaõnnestumisel tõsisemad tagajärjed. Näiteks kui teil on ainult kaks sõlme ja üks neist ebaõnnestub, kaovad pooled teie moodulitest kohe.
Loomulikult migreerib Kubernetes töökoormuse ebaõnnestunud sõlmelt teistele. Aga kui neid on vähe, siis ei pruugi vaba mahtu piisavalt olla. Selle tulemusena pole mõned teie rakendused saadaval, kuni kuvate ebaõnnestunud sõlme.
Seega, mida rohkem sõlme, seda väiksem on riistvaratõrgete mõju.
Puudus nr 4: rohkem automaatse skaleerimise samme
Kubernetesil on pilveinfrastruktuuri jaoks klastrite automaatse skaleerimise süsteem, mis võimaldab teil vastavalt hetkevajadustele automaatselt lisada või eemaldada sõlme. Suuremate sõlmede korral muutub automaatne skaleerimine järsemaks ja kohmakamaks. Näiteks kahel sõlmel suurendab täiendava sõlme lisamine koheselt klastri võimsust 50%. Ja te peate nende ressursside eest maksma, isegi kui te neid ei vaja.
Seega, kui kavatsete kasutada automaatset klastri skaleerimist, siis mida väiksemad on sõlmed, seda paindlikuma ja kuluefektiivsema skaleerimise saate.
Nüüd vaatame suure hulga väikeste sõlmede eeliseid ja puudusi.
Teine võimalus: palju väikeseid sõlme
Selle lähenemisviisi eelised tulenevad peamiselt mitme suure sõlmega vastupidise variandi puudustest.
Plusse
Pro nr 1: ebaõnnestumise mõju väiksem
Mida rohkem sõlme, seda vähem kaunasid igal sõlmel. Näiteks kui teil on sada moodulit kümne sõlme kohta, siis on igal sõlmel keskmiselt kümme moodulit.
Nii kaotate ühe sõlme rikke korral ainult 10% töökoormusest. Tõenäoliselt mõjutab see vaid väikest arvu koopiaid ja kogu rakendus jääb tööle.
Lisaks on ülejäänud sõlmedel tõenäoliselt piisavalt vabu ressursse ebaõnnestunud sõlme töökoormusega toimetulemiseks, nii et Kubernetes saab kaustasid vabalt ümber ajastada ja teie rakendused naasevad suhteliselt kiiresti funktsionaalsesse olekusse.
Pro nr 2: hea replikatsioon
Kui sõlme on piisavalt, saab Kubernetese ajakava määrata kõikidele koopiatele erinevad sõlmed. Nii mõjutab sõlme rikke korral ainult üks koopia ja rakendus jääb kättesaadavaks.
Miinused
Puudus nr 1. Raske kontrollida
Suurte arvu sõlmede haldamine on keerulisem. Näiteks iga Kubernetese sõlm peab suhtlema kõigi teistega, see tähendab, et ühenduste arv kasvab ruutkeskmiselt ja kõiki neid ühendusi tuleb jälgida.
Kubernetes Controller Manageri sõlmekontroller käib regulaarselt läbi kõik klastri sõlmed, et kontrollida tervist – mida rohkem sõlme, seda suurem on kontrolleri koormus.
Kasvab ka etcd andmebaasi koormus – iga kubelet ja kube-puhverserver kutsub etcd jaoks (API kaudu), millele etcd peaks objektivärskendusi edastama.
Üldiselt paneb iga töötaja sõlm põhisõlmede süsteemikomponentidele täiendava koormuse.
Kubernetes toetab ametlikult klastreid . Praktikas on aga juba 500 sõlme .
Suure hulga töötajate sõlmede haldamiseks peaksite valima võimsamad põhisõlmed. Näiteks kube-up õige VM-i suurus põhisõlme jaoks sõltuvalt töötaja sõlmede arvust. See tähendab, et mida rohkem töötajaid, seda tootlikumad peaksid olema põhisõlmed.
Nende spetsiifiliste probleemide lahendamiseks on spetsiaalsed arendused, nagu . See süsteem võimaldab teil piirangutest mööda minna ja luua suure hulga töötajate sõlmedega klastreid.
Puudus nr 2: rohkem üldkulusid.
Kubernetes käitab igas töötaja sõlmes süsteemideemonite komplekti – nende hulka kuuluvad konteineri käitusaeg (nt Docker), kube-puhverserver ja kubelet, sealhulgas cAdvisor. Koos tarbivad nad kindla kindla hulga ressursse.
Kui teil on palju väikeseid sõlmi, on selle üldkulude osakaal igas sõlmes suurem. Näiteks kujutage ette, et kõik ühes sõlmes asuvad süsteemideemonid kasutavad kokku 0,1 CPU südamikku ja 0,1 GB mälu. Kui teil on üks kümnetuumaline sõlm 10 GB mäluga, tarbivad deemonid 1% klastri mahust. Teisest küljest võtavad deemonid kümnel ühetuumalisel sõlmel, millel on 1 GB mälu, 10% klastri mahust.
Seega, mida vähem sõlme, seda tõhusamalt kasutatakse infrastruktuuri.
Puudus nr 3. Ressursside ebaefektiivne kasutamine
Väikestes sõlmedes võib juhtuda, et ülejäänud ressursitükid on töökoormuse määramiseks liiga väikesed, mistõttu neid ei kasutata.
Näiteks vajab iga tasku 0,75 GB mälu. Kui teil on kümme sõlme, millest igaühel on 1 GB mälu, saate käitada kümmet sõlme, jättes igale sõlmele 0,25 GB kasutamata mälu.
See tähendab, et 25% kogu klastri mälust läheb raisku.
Suures 10 GB mäluga sõlmes saate käitada 13 neist moodulitest - ja kasutamata jääb ainult üks 0,25 GB fragment.
Sel juhul läheb raisku vaid 2,5% mälust.
Seega kasutatakse suuremates sõlmedes ressursse optimaalsemalt.
Mitu suurt sõlme või palju väikseid?
Niisiis, kumb on parem: paar suurt sõlme klastris või palju väikseid? Nagu alati, pole selget vastust. Palju sõltub rakenduse tüübist.
Näiteks kui rakendus vajab 10 GB mälu, on suuremad sõlmed ilmselge valik. Ja kui rakendus nõuab kõrgeks saadavuseks kümnekordset replikatsiooni, siis vaevalt tasub riskida koopiate paigutamisega vaid kahele sõlmele – klastris peab olema vähemalt kümme sõlme.
Vahepealsetes olukordades tehke valik iga variandi eeliste ja puuduste põhjal. Võib-olla on mõned argumendid teie olukorra jaoks asjakohasemad kui teised.
Ja pole üldse vaja teha kõik sõlmed ühesuurused. Miski ei takista teil esmalt katsetada sama suurusega sõlmedega, seejärel lisada neile erineva suurusega sõlme, ühendades need klastris. Kubernetese klastri töötaja sõlmed võivad olla täiesti heterogeensed. Seega võite proovida kombineerida mõlema lähenemisviisi eeliseid.
Ühtset retsepti pole ja igal olukorral on oma nüansid ning tõde näitab ainult tootmine.
Tõlke koostas pilveplatvormi meeskond .
Lisateavet Kubernetese kohta: .
Allikas: www.habr.com