Prilikom kreiranja Kubernetes klastera mogu se pojaviti pitanja: koliko radnih čvorova konfigurirati i koji tip? Šta je bolje za lokalni klaster: kupiti nekoliko moćnih servera ili koristiti desetak starih mašina u svom data centru? Da li je bolje uzeti osam single-core ili dvije četverojezgrene instance u oblaku?
Odgovori na ova pitanja nalaze se u članku. u prevodu naredbe .
Kapacitet klastera
Općenito, Kubernetes klaster se može smatrati velikim "superčvorom". Njegova ukupna računarska snaga je zbir snaga svih njegovih sastavnih čvorova.
Postoji nekoliko načina za postizanje željenog cilja kapaciteta klastera. Na primjer, potreban nam je klaster ukupnog kapaciteta 8 procesorskih jezgri i 32 GB RAM-a jer skup aplikacija zahtijeva toliko resursa. Tada možete instalirati dva čvora sa 16 GB memorije ili četiri čvora sa 8 GB memorije, dva quad-core procesora ili četiri dual-core procesora.
Evo samo dva moguća načina za kreiranje klastera:
Obje opcije proizvode klaster istog kapaciteta, ali donja konfiguracija ima četiri manja čvora, a gornja konfiguracija ima dva veća čvora.
Koja je opcija bolja?
Da bismo odgovorili na ovo pitanje, pogledajmo prednosti obje opcije. Saželi smo ih u tabeli.
Nekoliko velikih čvorova
Mnogo malih čvorova
Lakše upravljanje klasterima (ako je on-premise)
Glatko automatsko skaliranje
Jeftinije (ako je lokalno)
Cijena je malo drugačija (u oblaku)
Može pokretati aplikacije koje zahtijevaju velike resurse
Potpuna replikacija
Resursi se koriste efikasnije (manje troškova za sistemske demone
Veća tolerancija grešaka klastera
Imajte na umu da govorimo samo o radničkim čvorovima. Odabir broja i veličine glavnih čvorova je sasvim druga tema.
Dakle, razgovarajmo o svakoj tački iz tabele detaljnije.
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 jezgara i 16 GB RAM-a.
Plûsy
Plus br. 1. Lakše upravljanje
Lakše je upravljati s nekoliko mašina nego cijelom flotom. Brže je uvođenje ažuriranja i popravki, a lakše je sinhronizirati. Broj kvarova u apsolutnim brojevima je također manji.
Imajte na umu da se sve gore navedeno odnosi na vaš hardver, vaše servere, a ne na instance u oblaku.
Situacija je drugačija u oblaku. Tamo upravljanje obavlja provajder usluga u oblaku. Stoga se upravljanje deset čvorova u oblaku ne razlikuje mnogo od upravljanja jednim čvorom.
Usmjeravanje saobraćaja i raspodjela opterećenja između podova u oblaku : saobraćaj koji dolazi sa Interneta šalje se glavnom balanseru opterećenja, koji prosleđuje saobraćaj na port jednog od čvorova (usluga NodePort postavlja port u opsegu 30000-32767 u svakom čvoru klastera). Pravila koja postavlja kube-proxy preusmjeravaju promet sa čvora na pod. Evo kako to izgleda za deset mahuna na dva čvora:
Pro #2: Manje cijene po čvoru
Snažan automobil je skuplji, ali povećanje cijene nije nužno linearno. Drugim riječima, jedan deset-jezgarni server sa 10 GB memorije obično je jeftiniji od deset single-core servera sa istom količinom memorije.
Ali imajte na umu da ovo pravilo obično ne funkcionira u uslugama u oblaku. U trenutnim šemama cijena svih glavnih provajdera oblaka, cijene raste linearno s kapacitetom.
Dakle, u oblaku obično ne možete uštedjeti na moćnijim serverima.
Pro #3: Možete pokretati aplikacije koje zahtijevaju velike resurse
Neke aplikacije zahtijevaju moćne servere u klasteru. Na primjer, ako sistem za strojno učenje zahtijeva 8 GB memorije, nećete ga moći pokrenuti na čvorovima od 1 GB, već samo s barem jednim velikim radnim čvorom.
Minusy
Nedostatak br. 1. Mnogo mahuna po čvoru
Ako se isti zadatak izvodi na manje čvorova, onda će svaki od njih prirodno imati više podova.
Ovo bi mogao biti problem.
Razlog je taj što svaki modul uvodi neke dodatne troškove u vrijeme izvođenja kontejnera (npr. Docker), kao i kubelet i cAdvisor.
Na primjer, kubelet redovno ispituje sve kontejnere na čvoru radi preživljavanja – što je više kontejnera, to više posla mora da obavi kubelet.
CADvisor prikuplja statistiku korišćenja resursa za sve kontejnere na čvoru, a kubelet redovno ispituje ove informacije i pruža ih preko API-ja. Opet, više kontejnera znači više posla i za cAdvisor i za kubelet.
Ako se broj modula poveća, to može usporiti sistem, pa čak i potkopati njegovu pouzdanost.
U Kubernetes spremištu nešto da čvorovi skaču između statusa Ready/NotReady jer redovne kubelet provjere svih kontejnera na čvoru traju predugo.
Iz tog razloga Kubernetes . Ovisno o performansama čvora, možete pokrenuti više podova po čvoru, ali je teško predvidjeti da li će biti problema ili će sve raditi dobro. Vrijedi unaprijed testirati rad.
Nedostatak br. 2. Ograničenje replikacije
Premalo čvorova ograničava efektivni opseg replikacije aplikacije. Na primjer, ako imate aplikaciju visoke dostupnosti sa pet replika, ali samo dva čvora, tada se efektivni stupanj replikacije aplikacije smanjuje na dva.
Pet replika može se distribuirati samo na dva čvora, a ako jedna od njih ne uspije, uklonit će više replika odjednom.
Ako imate pet ili više čvorova, svaka replika će se izvoditi na zasebnom čvoru, a neuspjeh 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
Sa malim brojem čvorova, svaki kvar ima ozbiljnije posljedice. Na primjer, ako imate samo dva čvora i jedan od njih pokvari, polovina vaših modula odmah nestaje.
Naravno, Kubernetes će migrirati radno opterećenje sa neuspjelog čvora na druge. Ali ako ih je malo, onda možda neće biti dovoljno slobodnog kapaciteta. Kao rezultat toga, neke od vaših aplikacija će biti nedostupne sve dok ne prikažete neuspjeli čvor.
Dakle, što je više čvorova, to je manji uticaj kvarova na hardveru.
Nedostatak #4: Više koraka za automatsko skaliranje
Kubernetes ima sistem za automatsko skaliranje klastera za infrastrukturu oblaka, koji vam omogućava da automatski dodajete ili uklanjate čvorove u zavisnosti od vaših trenutnih potreba. Sa većim čvorovima, automatsko skaliranje postaje naglo i nezgrapnije. Na primjer, na dva čvora, dodavanje dodatnog čvora će odmah povećati kapacitet klastera za 50%. I moraćete da platite za te resurse, čak i ako vam nisu potrebni.
Stoga, ako planirate koristiti automatsko skaliranje klastera, što su čvorovi manji, to ćete dobiti fleksibilnije i isplativije skaliranje.
Pogledajmo sada prednosti i nedostatke velikog broja malih čvorova.
Druga opcija: mnogo malih čvorova
Prednosti ovog pristupa u suštini proizlaze iz nedostataka suprotne opcije sa nekoliko velikih čvorova.
Plûsy
Pro #1: Manji uticaj neuspeha
Što više čvorova, to je manje podova na svakom čvoru. Na primjer, ako imate sto modula na deset čvorova, tada će svaki čvor imati u prosjeku deset modula.
Na ovaj način, ako jedan od čvorova pokvari, gubite samo 10% radnog opterećenja. Šanse su da će samo mali broj replika biti pogođen i da će cjelokupna aplikacija ostati operativna.
Osim toga, preostali čvorovi će vjerovatno imati dovoljno slobodnih resursa da podnose radno opterećenje neuspjelog čvora, tako da Kubernetes može slobodno rasporediti podove i vaše će se aplikacije relativno brzo vratiti u funkcionalno stanje.
Pro #2: Dobra replikacija
Ako ima dovoljno čvorova, Kubernetes planer može dodijeliti različite čvorove svim replikama. Na ovaj način, ako čvor ne uspije, samo jedna replika će biti pogođena i aplikacija će ostati dostupna.
Minusy
Nedostatak br. 1. Teško ga je kontrolisati
Velikim brojem čvorova je teže upravljati. Na primjer, svaki Kubernetes čvor mora komunicirati sa svim ostalima, odnosno, broj veza raste kvadratno, a sve te veze treba pratiti.
Kontroler čvorova u Kubernetes Controller Manager-u redovno prolazi kroz sve čvorove u klasteru kako bi provjerio zdravlje - što je više čvorova, to je veće opterećenje na kontroleru.
Opterećenje etcd baze podataka također raste - svaki kubelet i kube-proxy poziva za etcd (preko API-ja), na koji etcd treba emitovati ažuriranja objekata.
Općenito, svaki radni čvor nameće dodatno opterećenje sistemskim komponentama glavnih čvorova.
Kubernetes zvanično podržava klastere sa . Međutim, u praksi već postoji 500 čvorova .
Da biste upravljali velikim brojem radnih čvorova, trebali biste odabrati moćnije glavne čvorove. Na primjer, kube-up ispravna veličina VM-a za glavni čvor u zavisnosti od broja radnih čvorova. To jest, što je više radnih čvorova, to bi glavni čvorovi trebali biti produktivniji.
Za rješavanje ovih specifičnih problema postoje posebni razvoji, kao npr . Ovaj sistem vam omogućava da zaobiđete ograničenja i izgradite klastere sa ogromnim brojem radnih čvorova.
Nedostatak #2: Više režijskih troškova.
Na svakom radnom čvoru, Kubernetes pokreće skup sistemskih demona - oni uključuju vrijeme izvođenja kontejnera (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 nadmetanja na svakom čvoru je veći. Na primjer, zamislite da svi sistemski demoni na jednom čvoru zajedno koriste 0,1 CPU jezgra i 0,1 GB memorije. Ako imate jedan deset-jezgarni čvor sa 10 GB memorije, onda demoni troše 1% kapaciteta klastera. S druge strane, na deset jednojezgrenih čvorova sa 1 GB memorije, demoni će zauzeti 10% kapaciteta klastera.
Dakle, što je manje čvorova, to se infrastruktura efikasnije koristi.
Nedostatak br. 3. Neefikasno korištenje resursa
Na malim čvorovima može se dogoditi da su preostali komadi resursa premali da bi im se dodijelio bilo kakvo radno opterećenje, pa ostaju neiskorišteni.
Na primjer, za svaku podlogu je potrebno 0,75 GB memorije. Ako imate deset čvorova, svaki sa 1 GB memorije, možete pokrenuti deset podova, ostavljajući svaki čvor sa 0,25 GB neiskorištene memorije.
To znači da je 25% memorije cjelokupnog klastera izgubljeno.
Na velikom čvoru sa 10 GB memorije možete pokrenuti 13 ovih modula - i ostat će samo jedan neiskorišteni fragment od 0,25 GB.
U ovom slučaju, samo 2,5% memorije je izgubljeno.
Dakle, resursi se optimalnije koriste 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 zavisi od vrste aplikacije.
Na primjer, ako aplikacija zahtijeva 10 GB memorije, veći čvorovi su očigledan izbor. A ako aplikacija zahtijeva desetostruku replikaciju za visoku dostupnost, teško da je vrijedan rizik postavljanja replika na samo dva čvora - mora postojati najmanje deset čvorova u klasteru.
U srednjim situacijama, napravite izbor na osnovu prednosti i mana 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 sprečava da prvo eksperimentišete sa čvorovima iste veličine, a zatim im dodate čvorove različite veličine, kombinujući ih u klaster. Radnički čvorovi u Kubernetes klasteru mogu biti potpuno heterogeni. Dakle, možete pokušati kombinirati prednosti oba pristupa.
Ne postoji jedinstven recept, a svaka situacija ima svoje nijanse, a samo proizvodnja će pokazati istinu.
Prevod pripremio tim za cloud platformu .
Više o Kubernetesu: .
izvor: www.habr.com