Når du opretter en Kubernetes-klynge, kan der opstå spørgsmål: hvor mange arbejderknudepunkter skal jeg konfigurere og hvilken type? Hvad er bedre for en on-premise klynge: at købe flere kraftfulde servere eller bruge et dusin gamle maskiner i dit datacenter? Og i skyen, er det bedre at tage otte single-core eller to quad-core instanser?
Svarene på disse spørgsmål er i artiklen i oversættelsen af holdet .
Klyngekapacitet
Generelt kan en Kubernetes-klynge opfattes som en stor "supernode". Dens samlede regnekraft er summen af kræfterne af alle dets konstituerende noder.
Der er flere måder at opnå den ønskede målkapacitet for en klynge. For eksempel har vi brug for en klynge med en samlet kapacitet på 8 processorkerner og 32 GB RAM, fordi sættet af applikationer kræver den mængde ressourcer. Så kan du installere to noder med 16 GB hukommelse eller fire noder med 8 GB hukommelse, to quad-core processorer eller fire dual-core processorer.
Her er kun to mulige måder at oprette en klynge på:
Begge muligheder giver en klynge med samme kapacitet, men den nederste konfiguration har fire mindre noder, mens den øverste konfiguration har to større noder.
Hvilken mulighed er bedre?
For at besvare dette spørgsmål, lad os se på fordelene ved begge muligheder. Vi har opsummeret dem i en tabel.
Flere store knudepunkter
Mange små knaster
Nemmere klyngestyring (hvis det er på stedet)
Glat autoskalering
Billigere (hvis on-premise)
Prisen er ikke meget anderledes (i skyen)
Du kan køre ressourcekrævende applikationer
Fuld replikation
Ressourcer bruges mere effektivt (mindre overhead på systemdæmoner)
Højere klyngefejltolerance
Bemærk venligst, at vi kun taler om arbejdsknuder. At vælge antallet og størrelsen af masterknudepunkter er et helt andet emne.
Så lad os diskutere hvert punkt fra tabellen mere detaljeret.
Mulighed 1: Flere store knudepunkter
Den mest ekstreme mulighed er én arbejdsknude for hele klyngekapaciteten. I eksemplet ovenfor ville dette være en arbejderknude med 16 CPU-kerner og 16 GB RAM.
Pros
Plus #1. Nemmere at styre
Det er lettere at styre et par biler end en hel flåde. Udrul opdateringer og rettelser hurtigere, synkroniser nemmere. Antallet af fejl i absolutte tal er også lavere.
Bemærk venligst, at alt ovenstående gælder for din egen hardware, dine egne servere og ikke for cloud-instanser.
I skyen er situationen anderledes. Der varetages administrationen af en cloud-tjenesteudbyder. At administrere ti noder i skyen er således ikke meget anderledes end at administrere én node.
Trafikdirigering og belastningsbalancering mellem pods i skyen : trafik, der kommer fra internettet, dirigeres til hovedbelastningsbalanceren, som dirigerer trafikken til porten på en af noderne (NodePort-tjenesten indstiller en port i området 30000-32767 på hver klyngenode). Reglerne sat af kube-proxy omdirigerer trafik fra noden til poden. Sådan ser det ud for ti bælg på to noder:
Plus #2: Mindre omkostninger pr. node
En kraftig bil er dyrere, men prisstigningen er ikke nødvendigvis lineær. Med andre ord er én ti-core server med 10 GB hukommelse normalt billigere end ti single-core servere med den samme mængde hukommelse.
Men vær opmærksom på, at denne regel normalt ikke virker i skytjenester. I de nuværende prisordninger for alle større cloud-udbydere stiger priserne lineært med kapaciteten.
Så i skyen kan du normalt ikke spare penge på mere kraftfulde servere.
Pro #3: Du kan køre ressourcekrævende applikationer
Nogle applikationer kræver kraftige servere i en klynge. For eksempel, hvis et maskinlæringssystem kræver 8 GB hukommelse, vil du ikke være i stand til at køre det på 1 GB noder, medmindre du har mindst én stor arbejderknude.
Cons
Ulemper #1: For mange pods pr. node
Hvis den samme opgave udføres på færre noder, vil hver af dem naturligvis have flere pods.
Dette kan være et problem.
Årsagen er, at hver pod introducerer nogle overhead til containerens runtime (f.eks. Docker) samt kubelet og cAdvisor.
For eksempel sonderer kubelet regelmæssigt alle containere på en node for overlevelse - jo flere containere, jo mere arbejde skal kubelet udføre.
CAdvisor indsamler ressourceforbrugsstatistik fra alle containere på en node, og kubelet forespørger regelmæssigt på disse oplysninger og leverer dem gennem en API. Igen, jo flere containere, jo mere arbejde for både cAdvisor og kubelet.
Hvis antallet af moduler stiger, kan det bremse systemet og endda underminere dets pålidelighed.
Der er nogle i Kubernetes-lageret , at noder hopper mellem Ready/NotReady-statusser, fordi regelmæssig kubelet-tjek af alle containere på noden tager for lang tid.
Af denne grund, Kubernetes . Afhængigt af nodens ydeevne kan du køre flere pods pr. node, men det er svært at forudsige, om der vil være problemer, eller alt vil fungere fint. Det er værd at teste arbejdet på forhånd.
Minus #2. Replikationsbegrænsning
For få noder begrænser den effektive grad af applikationsreplikation. For eksempel, hvis du har en meget tilgængelig applikation med fem replikaer, men kun to noder, reduceres den effektive replikeringsgrad af applikationen til to.
Fem replikaer kan kun fordeles på to noder, og hvis en af dem fejler, fjerner den straks flere replikaer.
Hvis du har fem eller flere noder, vil hver replika køre på en separat node, og en enkelt nodefejl vil højst slette én replika.
Høje tilgængelighedskrav kan således kræve et vist minimumsantal af noder i en klynge.
Minus #3. Værre konsekvenser af fiasko
Med et lille antal noder har hver fejl mere alvorlige konsekvenser. For eksempel, hvis du kun har to noder, og en af dem fejler, forsvinder halvdelen af dine moduler på én gang.
Selvfølgelig vil Kubernetes migrere arbejdsbyrden fra den mislykkede node til andre. Men hvis der er få af dem, så er der måske ikke nok ledig kapacitet. Som et resultat vil nogle af dine applikationer være utilgængelige, før du bringer den mislykkede node op igen.
Jo flere noder, jo mindre indvirkning har hardwarefejl.
Minus #4. Flere autoskaleringstrin
Kubernetes leverer et klynge-autoskaleringssystem til cloud-infrastruktur, der gør det muligt automatisk at tilføje eller fjerne noder baseret på aktuelle behov. Med større noder bliver autoskalering mere ryk og klodset. For eksempel på to noder vil tilføjelse af en ekstra node øge klyngekapaciteten med 50 % på én gang. Og du skal betale for disse ressourcer, selvom du ikke har brug for dem.
Så hvis du planlægger at bruge klyngeautoskalering, jo mindre noder, jo mere fleksibel og omkostningseffektiv skalering får du.
Lad os nu se på fordele og ulemper ved at have et stort antal små noder.
Mulighed 2: Mange små noder
Fordelene ved denne tilgang følger i det væsentlige af ulemperne ved den modsatte mulighed med flere store knudepunkter.
Pros
Pro #1: Mindre virkning af fiasko
Jo flere noder, jo færre pods på hver node. For eksempel, hvis du har hundrede moduler på ti noder, så vil hver node have et gennemsnit på ti moduler.
Så hvis en node fejler, mister du kun 10 % af din arbejdsbyrde. Det er sandsynligt, at kun et lille antal replikaer er berørt, og applikationer som helhed vil forblive funktionelle.
Derudover vil de resterende noder sandsynligvis have tilstrækkelig ledig kapacitet til at håndtere den fejlbehæftede nodes arbejdsbyrde, så Kubernetes frit kan omplanlægge pods, og dine applikationer vil være tilbage op og køre relativt hurtigt.
Plus #2: God replikering
Hvis der er nok noder, kan Kubernetes-planlæggeren tildele forskellige noder til alle replikaer. På denne måde, hvis en node fejler, vil kun én replika blive påvirket, og applikationen forbliver tilgængelig.
Cons
Minus #1: Sværere at kontrollere
Et stort antal noder er sværere at håndtere. For eksempel skal hver Kubernetes-node kommunikere med alle de andre, hvilket betyder, at antallet af forbindelser vokser kvadratisk, og alle disse forbindelser skal spores.
Nodecontrolleren i Kubernetes-controllermanageren går regelmæssigt alle noderne i klyngen for at tjekke for sundhed - jo flere noder, jo mere belastning på controlleren.
Belastningen på etcd-databasen vokser også - hver kubelet og kube-proxy kalder for etcd (via API'en), som etcd skal udsende objektopdateringer til.
Generelt lægger hver arbejderknude en ekstra belastning på systemkomponenterne i hovedknuderne.
Kubernetes understøtter officielt klynger med . Men i praksis er der allerede 500 noder .
For at administrere et stort antal arbejderknudepunkter bør der vælges mere effektive masterknudepunkter. For eksempel kube-up korrekt VM-størrelse for masterknudepunkt afhængigt af antallet af arbejderknudepunkter. Det vil sige, at jo flere arbejdsknuder, jo mere produktive skal hovedknudepunkterne være.
For at løse disse specifikke problemer er der særlige udviklinger, som f.eks . Dette system giver dig mulighed for at omgå restriktioner og bygge klynger med et stort antal arbejdende noder.
Ulemper #2: Mere overhead
På hver arbejderknude kører Kubernetes et sæt systemdæmoner - disse inkluderer container-runtime (f.eks. Docker), kube-proxy og kubelet, inklusive cAdvisor. Tilsammen bruger de en vis fast mængde ressourcer.
Hvis du har mange små noder, er andelen af denne overhead på hver node større. Forestil dig for eksempel, at alle systemdæmoner på en enkelt node tilsammen bruger 0,1 CPU-kerner og 0,1 GB hukommelse. Hvis du har én 10-kernet node med 1 GB hukommelse, så bruger dæmoner 1 % af klyngekapaciteten. På den anden side, på ti single-core noder med 10 GB hukommelse, vil dæmonerne optage XNUMX% af klyngekapaciteten.
Jo færre noder, jo mere effektivt bruges infrastrukturen.
Minus #3: Ineffektiv brug af ressourcer
På små noder kan det være tilfældet, at de resterende ressourcefragmenter er for små til at tildele nogen arbejdsbyrde, så de forbliver ubrugte.
For eksempel kræver hver pod 0,75 GB hukommelse. Hvis du har ti noder, hver med 1 GB hukommelse, kan du køre ti pods, som vil efterlade hver node med 0,25 GB ubrugt hukommelse.
Det betyder, at 25 % af hele klyngens hukommelse er spildt.
På en stor node med 10 GB hukommelse kan du køre 13 af disse moduler og stadig kun have en ubrugt 0,25 GB-klump tilbage.
I dette tilfælde er kun 2,5 % af hukommelsen spildt.
Dermed bruges ressourcer mere optimalt på store knudepunkter.
Nogle få store knudepunkter eller mange små?
Så hvad er bedre: nogle få store noder i en klynge eller mange små? Som altid er der ikke noget klart svar. Meget afhænger af typen af ansøgning.
Hvis en applikation for eksempel kræver 10 GB hukommelse, er større noder det oplagte valg. Og hvis en applikation kræver ti gange replikering for høj tilgængelighed, er det næppe værd at risikere at placere replikaer på kun to noder – klyngen skal have mindst ti noder.
I mellemliggende situationer skal du træffe et valg baseret på fordele og ulemper ved hver mulighed. Måske er nogle argumenter mere relevante for din situation end andre.
Og det er slet ikke nødvendigt at lave alle knuderne i samme størrelse. Der er intet, der forhindrer dig i først at eksperimentere med noder af én størrelse, og derefter tilføje noder af en anden størrelse til dem og kombinere dem i en klynge. Arbejdernoder i en Kubernetes-klynge kan være fuldstændigt heterogene. Så du kan prøve at kombinere fordelene ved begge tilgange.
Der er ingen enkelt opskrift, og hver situation har sine egne nuancer, og kun produktionen vil vise sandheden.
Oversættelse udarbejdet af cloud platform-teamet .
Mere om Kubernetes: .
Kilde: www.habr.com
