Kubernetes-klusteria luotaessa voi herätä kysymyksiä: kuinka monta työntekijäsolmua määritetään ja minkä tyyppinen? Mikä on parempi paikan päällä olevalle klusterille: ostaa useita tehokkaita palvelimia vai käyttää tusinaa vanhaa konetta palvelinkeskuksessasi? Onko parempi ottaa pilveen kahdeksan yksiytimistä vai kaksi neliytimistä esiintymää?
Vastaukset näihin kysymyksiin ovat artikkelissa. komennon käännöksessä .
Klusterin kapasiteetti
Yleisesti ottaen Kubernetes-klusteria voidaan pitää suurena "supersolmuna". Sen kokonaislaskentateho on kaikkien sen muodostavien solmujen tehojen summa.
Halutun klusterin kapasiteettitavoitteen saavuttamiseksi on useita tapoja. Tarvitsemme esimerkiksi klusterin, jonka kokonaiskapasiteetti on 8 suoritinydintä ja 32 Gt RAM-muistia, koska sovellussarja vaatii niin paljon resursseja. Sitten voit asentaa kaksi solmua 16 Gt muistilla tai neljä solmua 8 Gt muistilla, kaksi neliytimistä prosessoria tai neljä kaksiytimistä.
Tässä on vain kaksi mahdollista tapaa luoda klusteri:
Molemmat vaihtoehdot tuottavat klusterin, jolla on sama kapasiteetti, mutta alemmassa kokoonpanossa on neljä pienempää solmua ja ylimmässä kokoonpanossa on kaksi suurempaa solmua.
Kumpi vaihtoehto on parempi?
Vastataksemme tähän kysymykseen, katsotaanpa kummankin vaihtoehdon etuja. Olemme koonneet niistä yhteen taulukkoon.
Useita suuria solmuja
Monet pienet solmut
Helpompi klusterin hallinta (jos se on paikalla)
Tasainen automaattinen skaalaus
Halvempi (jos paikan päällä)
Hinta on vähän erilainen (pilvessä)
Voi käyttää resurssiintensiivisiä sovelluksia
Täysi replikointi
Resursseja käytetään tehokkaammin (vähemmän järjestelmän demoneja
Korkeampi klusterin vikasietokyky
Huomaa, että puhumme vain työntekijäsolmuista. Pääsolmujen lukumäärän ja koon valitseminen on täysin eri aihe.
Joten keskustellaan jokaisesta taulukon kohdasta yksityiskohtaisemmin.
Ensimmäinen vaihtoehto: useita suuria solmuja
Äärimmäisin vaihtoehto on yksi työntekijäsolmu koko klusterin kapasiteettia varten. Yllä olevassa esimerkissä tämä olisi yksi työntekijäsolmu, jossa on 16 CPU-ydintä ja 16 Gt RAM-muistia.
Pros
Plus nro 1. Helpompi hallinta
On helpompi hallita muutamaa konetta kuin kokonaista konekantaa. Päivitysten ja korjausten käyttöönotto on nopeampaa, ja synkronointi on helpompaa. Myös vikojen määrä absoluuttisina lukuina on pienempi.
Huomaa, että kaikki edellä mainitut koskevat laitteistoasi, palvelimiasi, eivät pilvi-ilmentymiä.
Pilvessä tilanne on toinen. Siellä hallinnasta huolehtii pilvipalveluntarjoaja. Näin ollen kymmenen solmun hallinta pilvessä ei eroa paljon yhden solmun hallinnasta.
Liikenteen reititys ja kuormanjako pilvessä olevien podien välillä : Internetistä tuleva liikenne lähetetään pääkuormituksen tasapainottajalle, joka välittää liikenteen yhden solmun porttiin (NodePort-palvelu asettaa portin alueelle 30000-32767 kussakin klusterin solmussa). Kube-proxyn asettamat säännöt uudelleenohjaavat liikenteen solmusta podiin. Tältä se näyttää kymmenellä kahdella solmulla:
Pro #2: Pienemmät kustannukset solmua kohti
Tehokas auto on kalliimpi, mutta hinnan nousu ei välttämättä ole lineaarista. Toisin sanoen yksi kymmenen ytimen palvelin 10 Gt muistilla on yleensä halvempi kuin kymmenen yhden ytimen palvelinta, joissa on sama määrä muistia.
Huomaa kuitenkin, että tämä sääntö ei yleensä toimi pilvipalveluissa. Kaikkien suurten pilvipalveluntarjoajien nykyisissä hinnoittelujärjestelmissä hinnat nousevat lineaarisesti kapasiteetin mukana.
Näin ollen pilvessä et yleensä voi säästää tehokkaammilla palvelimilla.
Pro #3: Voit käyttää resurssiintensiivisiä sovelluksia
Jotkut sovellukset vaativat tehokkaita palvelimia klusterissa. Jos esimerkiksi koneoppimisjärjestelmä vaatii 8 Gt muistia, et voi käyttää sitä 1 Gt:n solmuissa, vaan vain vähintään yhdellä suurella työntekijäsolmulla.
Miinukset
Haitta nro 1. Useita paloja solmua kohti
Jos sama tehtävä suoritetaan harvemmille solmuille, jokaisessa niistä on luonnollisesti enemmän podeja.
Tämä voi olla ongelma.
Syynä on se, että jokainen moduuli lisää lisäkustannuksia kontin ajon aikana (esim. Docker) sekä kubeletille ja cAdvisorille.
Esimerkiksi kubelet tutkii säännöllisesti kaikkien solmun säiliöiden selviytymistä – mitä enemmän säiliöitä, sitä enemmän työtä kubeletin on tehtävä.
CAdvisor kerää resurssien käyttötilastot kaikista solmun säilöistä, ja kubelet kyselee säännöllisesti näitä tietoja ja toimittaa ne API:n kautta. Jälleen enemmän säiliöitä tarkoittaa enemmän työtä sekä cAdvisorille että kubeletille.
Jos moduulien määrä kasvaa, se voi hidastaa järjestelmää ja jopa heikentää sen luotettavuutta.
Kubernetes-arkistossa joitain että solmut hyppäävät Ready/NotReady-tilojen välillä, koska säännölliset kubelet-tarkastukset solmun kaikkien säilöjen välillä kestää liian kauan.
Tästä syystä Kubernetes . Solmun suorituskyvystä riippuen voit ajaa useampia podeja solmua kohti, mutta on vaikea ennustaa, tuleeko ongelmia vai kaikki toimiiko hyvin. Työtä kannattaa testata etukäteen.
Haitta nro 2. Replikoinnin rajoitus
Liian harvat solmut rajoittavat sovelluksen replikoinnin tehokasta laajuutta. Jos sinulla on esimerkiksi korkean käytettävyyden sovellus, jossa on viisi replikaa mutta vain kaksi solmua, sovelluksen tehokas replikointiaste pienenee kahteen.
Viisi kopiota voidaan jakaa vain kahdelle solmulle, ja jos yksi niistä epäonnistuu, se poistaa useita replikoita kerralla.
Jos sinulla on vähintään viisi solmua, jokainen replika suoritetaan erillisessä solmussa, ja yhden solmun epäonnistuminen poistaa enintään yhden replikan.
Siten korkeat saatavuusvaatimukset voivat vaatia tietyn vähimmäismäärän solmuja klusterissa.
Haitta nro 3. Epäonnistumisen huonommat seuraukset
Pienellä määrällä solmuja jokaisella vialla on vakavampia seurauksia. Jos sinulla on esimerkiksi vain kaksi solmua ja yksi niistä epäonnistuu, puolet moduuleistasi katoaa välittömästi.
Tietenkin Kubernetes siirtää työkuorman epäonnistuneesta solmusta muille. Mutta jos niitä on vähän, vapaata kapasiteettia ei ehkä ole tarpeeksi. Tämän seurauksena jotkin sovelluksistasi eivät ole käytettävissä, ennen kuin tuot esiin epäonnistuneen solmun.
Mitä enemmän solmuja, sitä vähemmän laitteistovikojen vaikutusta.
Haitta 4: Lisää automaattisen skaalauksen vaiheita
Kubernetesilla on klusterin automaattinen skaalausjärjestelmä pilviinfrastruktuurille, jonka avulla voit automaattisesti lisätä tai poistaa solmuja nykyisten tarpeidesi mukaan. Suuremmilla solmuilla automaattisesta skaalauksesta tulee äkillisempi ja kömpelömpi. Esimerkiksi kahdessa solmussa lisäsolmun lisääminen lisää välittömästi klusterin kapasiteettia 50 %. Ja sinun on maksettava näistä resursseista, vaikka et niitä tarvitsisi.
Jos siis aiot käyttää automaattista klusteriskaalausta, mitä pienemmät solmut ovat, sitä joustavampaa ja kustannustehokkaampaa skaalausta saat.
Katsotaanpa nyt suuren määrän pienten solmujen etuja ja haittoja.
Toinen vaihtoehto: monia pieniä solmuja
Tämän lähestymistavan edut johtuvat olennaisesti vastakkaisen vaihtoehdon haitoista, joissa on useita suuria solmuja.
Pros
Pro #1: Vähemmän epäonnistumisen vaikutusta
Mitä enemmän solmuja, sitä vähemmän podeja kussakin solmussa. Jos sinulla on esimerkiksi sata moduulia kymmentä solmua kohti, jokaisessa solmussa on keskimäärin kymmenen moduulia.
Tällä tavalla menetät vain 10 % työkuormasta, jos jokin solmuista epäonnistuu. On todennäköistä, että tämä vaikuttaa vain pieneen määrään replikoita ja koko sovellus pysyy toimintakunnossa.
Lisäksi jäljellä olevilla solmuilla on todennäköisesti tarpeeksi vapaita resursseja käsittelemään epäonnistuneen solmun työtaakkaa, joten Kubernetes voi vapaasti ajoittaa podeja uudelleen ja sovelluksesi palaavat toimintatilaan suhteellisen nopeasti.
Pro #2: Hyvä replikointi
Jos solmuja on tarpeeksi, Kubernetes-ajastin voi määrittää eri solmut kaikille replikoille. Tällä tavalla, jos solmu epäonnistuu, vain yksi replika vaikuttaa ja sovellus pysyy käytettävissä.
Miinukset
Haittapuoli nro 1. Vaikea hallita
Suuria solmumääriä on vaikeampi hallita. Esimerkiksi jokaisen Kubernetes-solmun on kommunikoitava kaikkien muiden kanssa, eli yhteyksien määrä kasvaa neliöllisesti, ja kaikkia näitä yhteyksiä on seurattava.
Kubernetes Controller Managerin solmuohjain käy säännöllisesti läpi kaikki klusterin solmut tarkistaakseen kunnon - mitä enemmän solmuja, sitä enemmän kuormaa ohjain on.
Myös etcd-tietokannan kuormitus kasvaa - jokainen kubelet ja kube-proxy kutsuvat etcd:lle (API:n kautta), jolle etcd lähettää objektipäivitykset.
Yleensä jokainen työntekijäsolmu asettaa lisäkuormituksen pääsolmujen järjestelmäkomponenteille.
Kubernetes tukee virallisesti klustereita . Käytännössä solmuja on kuitenkin jo 500 .
Jos haluat hallita suurta määrää työntekijäsolmuja, sinun tulee valita tehokkaammat pääsolmut. Esimerkiksi kube-up oikea VM-koko pääsolmulle työntekijäsolmujen lukumäärän mukaan. Eli mitä enemmän työntekijäsolmuja, sitä tuottavampia pääsolmujen tulisi olla.
Näiden erityisongelmien ratkaisemiseksi on olemassa erityisiä kehityshankkeita, kuten . Tämän järjestelmän avulla voit ohittaa rajoitukset ja rakentaa klustereita, joissa on valtava määrä työntekijäsolmuja.
Haitta 2: Lisää yleiskustannuksia.
Kubernetes suorittaa kussakin työntekijäsolmussa joukon järjestelmädaemoneja – näitä ovat kontin ajonaika (kuten Docker), kube-välityspalvelin ja kubelet, mukaan lukien cAdvisor. Yhdessä ne kuluttavat tietyn kiinteän määrän resursseja.
Jos sinulla on useita pieniä solmuja, tämän yleiskustannukset kussakin solmussa on suurempi. Kuvittele esimerkiksi, että kaikki yhden solmun järjestelmädaemonit käyttävät yhdessä 0,1 CPU-ydintä ja 0,1 Gt muistia. Jos sinulla on yksi kymmenen ytimen solmu, jossa on 10 Gt muistia, demonit kuluttavat 1 % klusterin kapasiteetista. Toisaalta kymmenessä yksiytimissolmussa, joissa on 1 Gt muistia, demonit vievät 10 % klusterin kapasiteetista.
Siten mitä vähemmän solmuja, sitä tehokkaammin infrastruktuuria käytetään.
Haitta nro 3. Resurssien tehoton käyttö
Pienissä solmuissa voi olla, että jäljellä olevat resurssipalat ovat liian pieniä määritettäviksi työkuormaa, joten ne jäävät käyttämättä.
Esimerkiksi jokainen pod vaatii 0,75 Gt muistia. Jos sinulla on kymmenen solmua, joista jokaisessa on 1 Gt muistia, voit käyttää kymmentä podia, jolloin jokaiselle solmulle jää 0,25 Gt käyttämätöntä muistia.
Tämä tarkoittaa, että 25 % koko klusterin muistista menee hukkaan.
Suuressa solmussa, jossa on 10 Gt muistia, voit käyttää 13 näistä moduuleista - ja käyttämättä jää vain yksi 0,25 Gt:n fragmentti.
Tässä tapauksessa vain 2,5 % muistista menee hukkaan.
Näin ollen resursseja käytetään optimaalisesti suuremmissa solmuissa.
Useita suuria solmuja vai monta pientä?
Joten kumpi on parempi: muutama suuri solmu klusterissa vai monta pientä? Kuten aina, selkeää vastausta ei ole. Paljon riippuu sovelluksen tyypistä.
Jos sovellus vaatii esimerkiksi 10 Gt muistia, suuremmat solmut ovat ilmeinen valinta. Ja jos sovellus vaatii kymmenkertaista replikointia korkean käytettävyyden saavuttamiseksi, tuskin kannattaa riskiä sijoittaa replikoita vain kahteen solmuun - klusterissa on oltava vähintään kymmenen solmua.
Välitilanteissa tee valinta kunkin vaihtoehdon etujen ja haittojen perusteella. Ehkä jotkut väitteet liittyvät tilanteeseesi paremmin kuin toiset.
Ja kaikkia solmuja ei tarvitse tehdä samankokoisiksi. Mikään ei estä sinua kokeilemasta ensin samankokoisia solmuja ja lisäämästä niihin sitten erikokoisia solmuja yhdistämällä ne klusteriksi. Kubernetes-klusterin työntekijäsolmut voivat olla täysin heterogeenisia. Joten voit yrittää yhdistää molempien lähestymistapojen edut.
Ei ole olemassa yhtä reseptiä, ja jokaisessa tilanteessa on omat vivahteensa, ja vain tuotanto näyttää totuuden.
Pilvialustan tiimin laatima käännös .
Lisää Kubernetesista: .
Lähde: will.com