Når du oppretter en Kubernetes-klynge, kan det oppstå spørsmål: hvor mange arbeidernoder skal konfigureres og hvilken type? Hva er bedre for en lokal klynge: Kjøp flere kraftige servere eller bruk et dusin gamle maskiner i datasenteret ditt? Er det bedre å ta åtte single-core eller to quad-core instanser i skyen?
Svarene på disse spørsmålene finner du i artikkelen. i oversettelsen av kommandoen .
Klyngekapasitet
Generelt kan en Kubernetes-klynge betraktes som en stor "supernode". Dens totale datakraft er summen av potensene til alle dens konstituerende noder.
Det er flere måter å oppnå ønsket klyngekapasitetsmål på. For eksempel trenger vi en klynge med en total kapasitet på 8 prosessorkjerner og 32 GB RAM fordi et sett med applikasjoner krever så mange ressurser. Deretter kan du installere to noder med 16 GB minne eller fire noder med 8 GB minne, to quad-core prosessorer eller fire dual-core.
Her er bare to mulige måter å opprette en klynge på:
Begge alternativene produserer en klynge med samme kapasitet, men bunnkonfigurasjonen har fire mindre noder og toppkonfigurasjonen har to større noder.
Hvilket alternativ er bedre?
For å svare på dette spørsmålet, la oss se på fordelene med begge alternativene. Vi har oppsummert dem i en tabell.
Flere store noder
Mange små noder
Enklere klyngeadministrasjon (hvis det er lokalt)
Jevn autoskalering
Billigere (hvis på stedet)
Prisen er litt annerledes (i skyen)
Kan kjøre ressurskrevende applikasjoner
Full replikering
Ressurser brukes mer effektivt (mindre overhead på systemdemoner
Høyere klyngefeiltoleranse
Vær oppmerksom på at vi kun snakker om arbeidernoder. Å velge antall og størrelse på hovednoder er et helt annet tema.
Så la oss diskutere hvert punkt fra tabellen mer detaljert.
Første alternativ: flere store noder
Det mest ekstreme alternativet er én arbeidernode for hele klyngekapasiteten. I eksemplet ovenfor vil dette være en enkelt arbeidernode med 16 CPU-kjerner og 16 GB RAM.
Pros
Pluss nr. 1. Enklere administrasjon
Det er lettere å administrere noen få maskiner enn en hel flåte. Det er raskere å rulle ut oppdateringer og rettelser, og det er lettere å synkronisere. Antall feil i absolutte tall er også mindre.
Vær oppmerksom på at alt det ovennevnte gjelder for maskinvaren din, serverne dine og ikke skyforekomster.
Situasjonen er annerledes i skyen. Der håndteres administrasjonen av skytjenesteleverandøren. Å administrere ti noder i skyen er derfor ikke mye forskjellig fra å administrere én node.
Trafikkruting og lastfordeling mellom pods i skyen : trafikk som kommer fra Internett sendes til hovedlastbalanseren, som videresender trafikk til porten til en av nodene (NodePort-tjenesten setter porten i området 30000-32767 i hver klyngennode). Reglene satt av kube-proxy omdirigerer trafikk fra noden til poden. Slik ser det ut for ti pods på to noder:
Pro #2: Mindre kostnad per node
En kraftig bil er dyrere, men prisøkningen er ikke nødvendigvis lineær. Med andre ord er én ti-kjerne-server med 10 GB minne vanligvis billigere enn ti en-kjerne-servere med samme mengde minne.
Men merk at denne regelen vanligvis ikke fungerer i skytjenester. I dagens prisordninger til alle store skyleverandører øker prisene lineært med kapasiteten.
Dermed kan du vanligvis ikke spare på kraftigere servere i skyen.
Pro #3: Du kan kjøre ressurskrevende applikasjoner
Noen applikasjoner krever kraftige servere i en klynge. For eksempel, hvis et maskinlæringssystem krever 8 GB minne, vil du ikke kunne kjøre det på 1 GB noder, men bare med minst én stor arbeidernode.
Cons
Ulempe nr. 1. Mange pods per node
Hvis den samme oppgaven utføres på færre noder, vil hver av dem naturlig nok ha flere pods.
Dette kan være et problem.
Årsaken er at hver modul introduserer noe overhead til containerkjøringen (f.eks. Docker), samt kubelet og cAdvisor.
For eksempel undersøker en kubelet regelmessig alle beholdere på en node for overlevelse – jo flere beholdere, jo mer arbeid må kubelet gjøre.
CAdvisor samler inn ressursbruksstatistikk for alle beholdere på en node, og kubelet spør regelmessig om denne informasjonen og gir den via et API. Igjen betyr flere containere mer arbeid for både cAdvisor og kubelet.
Hvis antallet moduler øker, kan det bremse systemet og til og med undergrave dets pålitelighet.
I Kubernetes-depotet noen at noder hopper mellom Ready/NotReady-statuser fordi vanlige kubelet-sjekker av alle beholdere på en node tar for lang tid.
Av denne grunn Kubernetes . Avhengig av nodens ytelse kan du kjøre flere pods per node, men det er vanskelig å forutsi om det vil være problemer eller alt vil fungere bra. Det er verdt å teste arbeidet på forhånd.
Ulempe nr. 2. Begrensning på replikering
For få noder begrenser det effektive omfanget av applikasjonsreplikering. Hvis du for eksempel har en applikasjon med høy tilgjengelighet med fem replikaer, men bare to noder, reduseres applikasjonens effektive replikasjonsgrad til to.
Fem replikaer kan bare fordeles på to noder, og hvis en av dem mislykkes, vil den ta ned flere replikaer samtidig.
Hvis du har fem noder eller flere, vil hver replika kjøre på en separat node, og feil på én node vil fjerne maksimalt én replika.
Dermed kan høye tilgjengelighetskrav kreve et visst minimum antall noder i klyngen.
Ulempe nr. 3. Verre konsekvenser av fiasko
Med et lite antall noder har hver feil mer alvorlige konsekvenser. For eksempel, hvis du bare har to noder og en av dem mislykkes, forsvinner halvparten av modulene dine umiddelbart.
Selvfølgelig vil Kubernetes migrere arbeidsbelastningen fra den mislykkede noden til andre. Men hvis det er få av dem, er det kanskje ikke nok ledig kapasitet. Som et resultat vil noen av applikasjonene dine være utilgjengelige før du henter frem den mislykkede noden.
Jo flere noder, desto mindre blir konsekvensen av maskinvarefeil.
Ulempe #4: Flere automatiske skaleringstrinn
Kubernetes har et klyngeautomatisk skaleringssystem for skyinfrastruktur, som lar deg automatisk legge til eller fjerne noder avhengig av dine nåværende behov. Med større noder blir autoskalering mer brå og klumpete. For eksempel, på to noder, vil det å legge til en ekstra node umiddelbart øke klyngekapasiteten med 50 %. Og du må betale for disse ressursene, selv om du ikke trenger dem.
Derfor, hvis du planlegger å bruke automatisk klyngeskalering, jo mindre nodene er, desto mer fleksibel og kostnadseffektiv skalering vil du få.
La oss nå se på fordelene og ulempene ved et stort antall små noder.
Andre alternativ: mange små noder
Fordelene med denne tilnærmingen stammer i hovedsak fra ulempene ved det motsatte alternativet med flere store noder.
Pros
Pro #1: Mindre påvirkning av feil
Jo flere noder, jo færre pods på hver node. For eksempel, hvis du har hundre moduler per ti noder, vil hver node ha et gjennomsnitt på ti moduler.
På denne måten, hvis en av nodene svikter, mister du bare 10 % av arbeidsmengden. Sjansen er stor for at bare et lite antall replikaer vil bli berørt, og den generelle applikasjonen vil forbli operativ.
I tillegg vil de gjenværende nodene sannsynligvis ha nok ledige ressurser til å håndtere arbeidsbelastningen til den mislykkede noden, så Kubernetes kan fritt omplanlegge podene og applikasjonene dine vil returnere til en funksjonell tilstand relativt raskt.
Pro #2: God replikering
Hvis det er nok noder, kan Kubernetes-planleggeren tilordne forskjellige noder til alle replikaer. På denne måten, hvis en node mislykkes, vil bare én replika bli påvirket, og applikasjonen vil forbli tilgjengelig.
Cons
Ulempe nr. 1. Vanskelig å kontrollere
Store antall noder er vanskeligere å administrere. For eksempel må hver Kubernetes-node kommunisere med alle de andre, det vil si at antall tilkoblinger vokser kvadratisk, og alle disse tilkoblingene må spores.
Nodekontrolleren i Kubernetes Controller Manager går jevnlig gjennom alle nodene i klyngen for å sjekke helse – jo flere noder, jo mer belastning på kontrolleren.
Belastningen på etcd-databasen vokser også - hver kubelet og kube-proxy kaller for etcd (via API), som etcd skal kringkaste objektoppdateringer til.
Generelt pålegger hver arbeidernode ekstra belastning på systemkomponentene til masternodene.
Kubernetes støtter offisielt klynger med . Men i praksis er det allerede 500 noder .
For å administrere et stort antall arbeidernoder, bør du velge kraftigere masternoder. For eksempel kube-up riktig VM-størrelse for hovednoden avhengig av antall arbeidernoder. Det vil si at jo flere arbeidernoder, desto mer produktive bør masternodene være.
For å løse disse spesifikke problemene er det spesielle utviklinger, som f.eks . Dette systemet lar deg omgå restriksjoner og bygge klynger med et stort antall arbeidernoder.
Ulempe #2: Flere faste kostnader.
På hver arbeidernode kjører Kubernetes et sett med systemdemoner - disse inkluderer containerkjøringstiden (som Docker), kube-proxy og kubelet, inkludert cAdvisor. Sammen bruker de en viss fast mengde ressurser.
Hvis du har mange små noder, er andelen av denne overheaden på hver node større. Tenk deg for eksempel at alle systemdemoner på en enkelt node sammen bruker 0,1 CPU-kjerner og 0,1 GB minne. Hvis du har én ti-kjerners node med 10 GB minne, bruker demoner 1 % av klyngekapasiteten. På den annen side, på ti enkeltkjerne-noder med 1 GB minne, vil daemonene ta 10 % av klyngekapasiteten.
Jo færre noder, jo mer effektivt brukes infrastrukturen.
Ulempe nr. 3. Ineffektiv ressursbruk
På små noder kan det hende at de gjenværende ressursbitene er for små til å tildele noen arbeidsbelastning, så de forblir ubrukte.
For eksempel krever hver pod 0,75 GB minne. Hvis du har ti noder, hver med 1 GB minne, kan du kjøre ti pods, slik at hver node har 0,25 GB ubrukt minne.
Dette betyr at 25 % av hele klyngens minne er bortkastet.
På en stor node med 10 GB minne kan du kjøre 13 av disse modulene – og det blir kun ett ubrukt fragment på 0,25 GB.
I dette tilfellet er bare 2,5 % av minnet bortkastet.
Dermed brukes ressursene mer optimalt på større noder.
Flere store noder eller mange små?
Så, hva er bedre: noen få store noder i en klynge eller mange små? Som alltid er det ikke noe klart svar. Mye avhenger av typen søknad.
For eksempel, hvis en applikasjon krever 10 GB minne, er større noder et opplagt valg. Og hvis en applikasjon krever tidoblet replikering for høy tilgjengelighet, er det neppe verdt risikoen med å plassere replikaer på bare to noder – det må være minimum ti noder i klyngen.
I mellomsituasjoner, ta et valg basert på fordelene og ulempene ved hvert alternativ. Kanskje noen argumenter er mer relevante for din situasjon enn andre.
Og det er slett ikke nødvendig å gjøre alle nodene like store. Ingenting hindrer deg i å eksperimentere først med noder av samme størrelse, og deretter legge til noder av en annen størrelse til dem, og kombinere dem i en klynge. Arbeidsnoder i en Kubernetes-klynge kan være helt heterogene. Så du kan prøve å kombinere fordelene med begge tilnærmingene.
Det er ingen enkelt oppskrift, og hver situasjon har sine egne nyanser, og bare produksjonen vil vise sannheten.
Oversettelse utarbeidet av skyplattformteamet .
Mer om Kubernetes: .
Kilde: www.habr.com
