Prilikom stvaranja Kubernetes klastera mogu se pojaviti pitanja: koliko radnih čvorova konfigurirati i koju vrstu? Što je bolje za lokalni klaster: kupiti nekoliko snažnih poslužitelja ili koristiti desetak starih strojeva u svom podatkovnom centru? Je li bolje uzeti osam jednojezgrenih ili dvije četverojezgrene instance u oblaku?
Odgovori na ova pitanja nalaze se u članku. u prijevodu naredbe .
Kapacitet klastera
Općenito, Kubernetes klaster se može smatrati velikim "superčvorom". Njegova ukupna računalna snaga zbroj je snaga svih njegovih sastavnih čvorova.
Postoji nekoliko načina za postizanje željenog ciljanog kapaciteta klastera. Na primjer, potreban nam je klaster ukupnog kapaciteta 8 procesorskih jezgri i 32 GB RAM-a jer skup aplikacija zahtijeva toliko resursa. Zatim možete instalirati dva čvora s 16 GB memorije ili četiri čvora s 8 GB memorije, dva četverojezgrena procesora ili četiri dvojezgrena.
Evo samo dva moguća načina za stvaranje klastera:
Obje opcije proizvode klaster s istim kapacitetom, ali donja konfiguracija ima četiri manja čvora, a gornja konfiguracija ima dva veća čvora.
Koja je opcija bolja?
Kako bismo odgovorili na ovo pitanje, pogledajmo prednosti obje opcije. Saželi smo ih u tablicu.
Nekoliko velikih čvorova
Mnogo malih čvorova
Lakše upravljanje klasterom (ako je on-premise)
Glatko automatsko skaliranje
Jeftinije (ako je na lokaciji)
Cijena se malo razlikuje (u oblaku)
Može pokretati aplikacije koje zahtijevaju velike resurse
Potpuna replikacija
Resursi se koriste učinkovitije (manje troškova na demonima sustava
Veća tolerancija grešaka klastera
Imajte na umu da govorimo samo o radnim čvorovima. Odabir broja i veličine glavnih čvorova sasvim je druga tema.
Dakle, raspravimo detaljnije svaku točku iz tablice.
Prva opcija: nekoliko velikih čvorova
Najekstremnija opcija je jedan radni čvor za cijeli kapacitet klastera. U gornjem primjeru, ovo bi bio jedan radni čvor sa 16 CPU jezgri i 16 GB RAM-a.
Prozodija
Plus br. 1. Lakše upravljanje
Lakše je upravljati s nekoliko strojeva nego s cijelom flotom. Brže je uvesti ažuriranja i popravke i lakše je sinkronizirati. Broj kvarova u apsolutnim brojevima također je manji.
Imajte na umu da se sve gore navedeno odnosi na vaš hardver, vaše poslužitelje, a ne na instance oblaka.
Drugačija je situacija u oblaku. Tamo se upravljanjem bavi pružatelj usluga u oblaku. Stoga se upravljanje deset čvorova u oblaku ne razlikuje puno od upravljanja jednim čvorom.
Usmjeravanje prometa i raspodjela opterećenja između podova u oblaku : promet koji dolazi s interneta šalje se glavnom balanseru opterećenja, koji prosljeđuje promet na port jednog od čvorova (usluga NodePort postavlja port u rasponu 30000-32767 u svakom čvoru klastera). Pravila koja postavlja kube-proxy preusmjeravaju promet s čvora na pod. Evo kako to izgleda za deset mahuna na dva čvora:
Pro #2: Manji trošak po čvoru
Snažan automobil je skuplji, ali rast cijene nije nužno linearan. Drugim riječima, jedan poslužitelj s deset jezgri i 10 GB memorije obično je jeftiniji od deset poslužitelja s jednom jezgrom i istom količinom memorije.
No imajte na umu da ovo pravilo obično ne funkcionira u uslugama u oblaku. U trenutnim shemama cijena svih glavnih pružatelja usluga oblaka, cijene rastu linearno s kapacitetom.
Dakle, u oblaku obično ne možete štedjeti na snažnijim poslužiteljima.
Pro #3: Možete pokretati aplikacije koje zahtijevaju velike resurse
Neke aplikacije zahtijevaju moćne poslužitelje u klasteru. Na primjer, ako sustav strojnog učenja zahtijeva 8 GB memorije, nećete ga moći pokrenuti na čvorovima od 1 GB, već samo s barem jednim velikim radnim čvorom.
Cons
Nedostatak br. 1. Mnogo mahuna po čvoru
Ako se isti zadatak izvodi na manje čvorova, tada će svaki od njih prirodno imati više mahuna.
Ovo bi mogao biti problem.
Razlog je taj što svaki modul uvodi neke dodatne troškove u runtime spremnika (npr. Docker), kao i kubelet i cAdvisor.
Na primjer, kubelet redovito provjerava mogućnost preživljavanja svih spremnika na čvoru—što je više spremnika, to kubelet mora obaviti više posla.
CAdvisor prikuplja statistiku korištenja resursa za sve spremnike na čvoru, a kubelet redovito postavlja upite o tim informacijama i pruža ih putem API-ja. Opet, više spremnika znači više posla i za cAdvisor i za kubelet.
Ako se broj modula povećava, to može usporiti sustav, pa čak i potkopati njegovu pouzdanost.
U repozitoriju Kubernetes neki da čvorovi skaču između statusa Ready/NotReady jer redovite kubelet provjere svih spremnika na čvoru predugo traju.
Iz tog razloga Kubernetes . Ovisno o performansama čvora, možete pokrenuti više podova po čvoru, ali teško je predvidjeti hoće li biti problema ili će sve dobro funkcionirati. Vrijedno je testirati rad unaprijed.
Nedostatak br. 2. Ograničenje replikacije
Premalo čvorova ograničava učinkovit opseg replikacije aplikacije. Na primjer, ako imate aplikaciju visoke dostupnosti s pet replika, ali samo dva čvora, tada je efektivni stupanj replikacije aplikacije smanjen na dva.
Pet replika može se distribuirati samo na dva čvora, a ako jedan od njih zakaže, srušit će više replika odjednom.
Ako imate pet ili više čvorova, svaka replika će se izvoditi na zasebnom čvoru, a kvar jednog čvora će ukloniti najviše jednu repliku.
Stoga zahtjevi visoke dostupnosti mogu zahtijevati određeni minimalni broj čvorova u klasteru.
Nedostatak br. 3. Gore posljedice neuspjeha
S malim brojem čvorova svaki kvar ima ozbiljnije posljedice. Na primjer, ako imate samo dva čvora i jedan od njih zakaže, pola vaših modula odmah nestaje.
Naravno, Kubernetes će migrirati radno opterećenje s pokvarenog čvora na druge. Ali ako ih ima malo, tada možda neće biti dovoljno slobodnog kapaciteta. Zbog toga će neke od vaših aplikacija biti nedostupne dok ne prikažete neuspjeli čvor.
Dakle, što je više čvorova, manji je utjecaj kvarova hardvera.
Nedostatak #4: Više koraka automatskog skaliranja
Kubernetes ima sustav automatskog skaliranja klastera za infrastrukturu oblaka, koji vam omogućuje automatsko dodavanje ili uklanjanje čvorova ovisno o vašim trenutnim potrebama. S većim čvorovima, automatsko skaliranje postaje naglo i nezgrapno. Na primjer, na dva čvora, dodavanje dodatnog čvora odmah će povećati kapacitet klastera za 50%. I morat ćete platiti za te resurse, čak i ako vam ne trebaju.
Stoga, ako planirate koristiti automatsko skaliranje klastera, što su čvorovi manji, to ćete dobiti fleksibilnije i isplativije skaliranje.
Sada pogledajmo prednosti i nedostatke velikog broja malih čvorova.
Druga opcija: mnogo malih čvorova
Prednosti ovog pristupa u biti proizlaze iz nedostataka suprotne opcije s nekoliko velikih čvorova.
Prozodija
Pro #1: Manji utjecaj neuspjeha
Što je više čvorova, to je manje mahuna na svakom čvoru. Na primjer, ako imate sto modula po deset čvorova, tada će svaki čvor imati u prosjeku deset modula.
Na ovaj način, ako jedan od čvorova zakaže, gubite samo 10% radnog opterećenja. Velike su šanse da će to utjecati na samo mali broj replika i da će cjelokupna aplikacija ostati operativna.
Dodatno, preostali čvorovi vjerojatno će imati dovoljno slobodnih resursa da se nose s radnim opterećenjem neuspjelog čvora, tako da Kubernetes može slobodno preraspodijeliti blokove i vaše će se aplikacije vratiti u funkcionalno stanje relativno brzo.
Pro #2: Dobra replikacija
Ako ima dovoljno čvorova, Kubernetes planer može dodijeliti različite čvorove svim replikama. Na ovaj način, ako čvor zakaže, to će utjecati na samo jednu repliku i aplikacija će ostati dostupna.
Cons
Nedostatak br. 1. Teško ga je kontrolirati
Teže je upravljati velikim brojem čvorova. Primjerice, svaki Kubernetes čvor mora komunicirati sa svim ostalima, odnosno broj konekcija raste kvadratično i sve te konekcije treba pratiti.
Kontroler čvorova u Kubernetes Controller Manageru redovito prolazi kroz sve čvorove u klasteru kako bi provjerio ispravnost - što je više čvorova, to je veće opterećenje kontrolera.
Opterećenje etcd baze podataka također raste - svaki kubelet i kube-proxy poziva za etcd (preko API-ja), kojem bi etcd trebao emitirati ažuriranja objekta.
Općenito, svaki radni čvor nameće dodatno opterećenje komponentama sustava glavnih čvorova.
Kubernetes službeno podržava klastere sa . Međutim, u praksi već postoji 500 čvorova .
Za upravljanje velikim brojem radnih čvorova trebali biste odabrati snažnije glavne čvorove. Na primjer, kube-up ispravnu veličinu VM-a za glavni čvor ovisno o broju radnih čvorova. Odnosno, što je više radnih čvorova, to bi glavni čvorovi trebali biti produktivniji.
Za rješavanje ovih specifičnih problema postoje posebni razvoji, kao što su . Ovaj sustav vam omogućuje da zaobiđete ograničenja i izgradite klastere s velikim brojem radnih čvorova.
Nedostatak #2: Više režijskih troškova.
Na svakom radnom čvoru, Kubernetes pokreće skup sistemskih demona - oni uključuju runtime spremnika (kao što je Docker), kube-proxy i kubelet, uključujući cAdvisor. Zajedno troše određenu fiksnu količinu resursa.
Ako imate mnogo malih čvorova, udio ovog opterećenja na svakom čvoru je veći. Na primjer, zamislite da svi sistemski demoni na jednom čvoru zajedno koriste 0,1 CPU jezgre i 0,1 GB memorije. Ako imate jedan čvor s deset jezgri i 10 GB memorije, tada demoni troše 1% kapaciteta klastera. S druge strane, na deset jednojezgrenih čvorova s 1 GB memorije demoni će zauzeti 10% kapaciteta klastera.
Dakle, što je manje čvorova, to se učinkovitije koristi infrastruktura.
Nedostatak br. 3. Neučinkovito korištenje resursa
Na malim čvorovima može biti da su preostali dijelovi resursa premali da bi im se dodijelilo radno opterećenje, pa ostaju neiskorišteni.
Na primjer, svaki pod zahtijeva 0,75 GB memorije. Ako imate deset čvorova, svaki s 1 GB memorije, možete pokrenuti deset podova, ostavljajući svaki čvor s 0,25 GB neiskorištene memorije.
To znači da je 25% cijele memorije klastera izgubljeno.
Na velikom čvoru s 10 GB memorije možete pokrenuti 13 ovih modula - i bit će samo jedan neiskorišteni fragment od 0,25 GB.
U ovom slučaju gubi se samo 2,5% memorije.
Stoga se resursi koriste optimalnije na većim čvorovima.
Nekoliko velikih čvorova ili mnogo malih?
Dakle, što je bolje: nekoliko velikih čvorova u klasteru ili mnogo malih? Kao i uvijek, nema jasnog odgovora. Mnogo ovisi o vrsti aplikacije.
Na primjer, ako aplikacija zahtijeva 10 GB memorije, veći čvorovi očit su izbor. A ako aplikacija zahtijeva deseterostruku replikaciju za visoku dostupnost, teško da se isplati riskirati postavljanje replika na samo dva čvora - mora postojati najmanje deset čvorova u klasteru.
U srednjim situacijama, napravite izbor na temelju prednosti i nedostataka svake opcije. Možda su neki argumenti relevantniji za vašu situaciju od drugih.
I uopće nije potrebno napraviti sve čvorove iste veličine. Ništa vas ne sprječava da prvo eksperimentirate s čvorovima iste veličine, a zatim im dodate čvorove različite veličine, kombinirajući ih u klaster. Radnički čvorovi u Kubernetes klasteru mogu biti potpuno heterogeni. Stoga možete pokušati kombinirati prednosti oba pristupa.
Nema jedinstvenog recepta, svaka situacija ima svoje nijanse, a tek će proizvodnja pokazati istinu.
Prijevod pripremio tim cloud platforme .
Više o Kubernetesu: .
Izvor: www.habr.com