Når du opretter en Kubernetes-klynge, kan der opstå spørgsmål: hvor mange arbejdsknudepunkter skal konfigureres og hvilken type? Hvad er bedre for en lokal klynge: Køb flere kraftfulde servere eller brug et dusin gamle maskiner i dit datacenter? Er det bedre at tage otte single-core eller to quad-core instanser i skyen?
Svarene på disse spørgsmål findes i artiklen. i oversættelsen af kommandoen .
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 nå dit ønskede klyngekapacitetsmål på. For eksempel har vi brug for en klynge med en samlet kapacitet på 8 processorkerner og 32 GB RAM, fordi et sæt applikationer kræver så mange 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.
Her er kun to mulige måder at oprette en klynge på:
Begge muligheder producerer en klynge med samme kapacitet, men den nederste konfiguration har fire mindre noder, og 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 noder
Mange små noder
Nemmere klyngestyring (hvis det er på stedet)
Glat autoskalering
Billigere (hvis on-premise)
Prisen er lidt anderledes (i skyen)
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 arbejderknudepunkter. At vælge antallet og størrelsen af hovedknudepunkter er et helt andet emne.
Så lad os diskutere hvert punkt fra tabellen mere detaljeret.
Første mulighed: flere store noder
Den mest ekstreme mulighed er én arbejderknude for hele klyngekapaciteten. I eksemplet ovenfor ville dette være en enkelt arbejderknude med 16 CPU-kerner og 16 GB RAM.
Pros
Plus nr. 1. Lettere styring
Det er nemmere at styre nogle få maskiner end en hel flåde. Det er hurtigere at udrulle opdateringer og rettelser, og det er nemmere at synkronisere. Antallet af fejl i absolutte tal er også mindre.
Bemærk, at alt ovenstående gælder for din hardware, dine servere og ikke for cloud-instanser.
Situationen er anderledes i skyen. Der varetages administrationen af cloud-tjenesteudbyderen. At administrere ti noder i skyen er således ikke meget anderledes end at administrere én node.
Trafikdirigering og belastningsfordeling mellem pods i skyen : trafik, der kommer fra internettet, sendes til hovedbelastningsbalanceren, som videresender trafik til porten på en af noderne (NodePort-tjenesten indstiller porten i området 30000-32767 i 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:
Pro #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 bemærk, 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.
I skyen kan du således normalt ikke spare 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 kunne køre det på 1 GB noder, men kun med mindst én stor arbejderknude.
Cons
Ulempe nr. 1. Mange bælg 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 hvert modul introducerer nogle overhead til containerens runtime (f.eks. Docker), såvel som kubelet og cAdvisor.
For eksempel sonderer en kubelet regelmæssigt alle beholdere på en node for overlevelse – jo flere beholdere, jo mere arbejde skal kubelet udføre.
CAdvisor indsamler ressourceforbrugsstatistik for alle containere på en node, og kubelet forespørger regelmæssigt på disse oplysninger og leverer dem via en API. Igen betyder flere containere mere arbejde for både cAdvisor og kubelet.
Hvis antallet af moduler stiger, kan det bremse systemet og endda underminere dets pålidelighed.
I Kubernetes repository nogle at noder hopper mellem Ready/NotReady-statusser, fordi regelmæssig kubelet-tjek af alle containere på en node 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.
Ulempe nr. 2. Begrænsning af replikering
For få noder begrænser det effektive omfang af applikationsreplikering. Hvis du f.eks. har et program med høj tilgængelighed med fem replikaer, men kun to noder, reduceres programmets effektive replikationsgrad til to.
Fem replikaer kan kun fordeles over to noder, og hvis en af dem fejler, vil den fjerne flere replikaer på én gang.
Hvis du har fem noder eller flere, vil hver replika køre på en separat node, og fejl på én node vil højst fjerne én replika.
Høje tilgængelighedskrav kan således kræve et vist minimum antal knudepunkter i klyngen.
Ulempe nr. 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 med det samme.
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 følge heraf vil nogle af dine applikationer være utilgængelige, før du henter den mislykkede node frem.
Jo flere knudepunkter, jo mindre påvirkning af hardwarefejl.
Ulempe #4: Flere autoskaleringstrin
Kubernetes har et cluster auto-scaling system til cloud-infrastruktur, som giver dig mulighed for automatisk at tilføje eller fjerne noder afhængigt af dine aktuelle behov. Med større noder bliver autoskalering mere brat og klodset. For eksempel på to noder vil tilføjelse af en ekstra node øjeblikkeligt øge klyngekapaciteten med 50 %. Og du skal betale for disse ressourcer, selvom du ikke har brug for dem.
Derfor, hvis du planlægger at bruge automatisk klyngeskalering, jo mindre noder, jo mere fleksibel og omkostningseffektiv skalering får du.
Lad os nu se på fordele og ulemper ved et stort antal små noder.
Anden mulighed: mange små noder
Fordelene ved denne tilgang stammer i det væsentlige fra ulemperne ved den modsatte mulighed med flere store noder.
Pros
Pro #1: Mindre virkning af fiasko
Jo flere noder, jo færre pods på hver node. For eksempel, hvis du har hundrede moduler pr. ti noder, så vil hver node have et gennemsnit på ti moduler.
Så hvis en af noderne fejler, mister du kun 10% af arbejdsbyrden. Chancerne er, at kun et lille antal replikaer vil blive påvirket, og den overordnede applikation vil forblive operationel.
Derudover vil de resterende noder sandsynligvis have nok ledige ressourcer til at håndtere arbejdsbyrden af den mislykkede node, så Kubernetes kan frit omplanlægge pods, og dine applikationer vil vende tilbage til en funktionel tilstand relativt hurtigt.
Pro #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
Ulempe nr. 1. Svært at kontrollere
Et stort antal noder er sværere at håndtere. For eksempel skal hver Kubernetes-node kommunikere med alle de andre, det vil sige, at antallet af forbindelser vokser kvadratisk, og alle disse forbindelser skal spores.
Nodecontrolleren i Kubernetes Controller Manager går jævnligt gennem alle noderne i klyngen for at kontrollere sundheden - jo flere noder, jo mere belastning på controlleren.
Belastningen på etcd-databasen vokser også - hver kubelet og kube-proxy kalder for etcd (via API'et), som etcd skal udsende objektopdateringer til.
Generelt pålægger hver arbejderknude yderligere belastning på masterknudepunkternes systemkomponenter.
Kubernetes understøtter officielt klynger med . Men i praksis er der allerede 500 noder .
For at administrere et stort antal arbejderknudepunkter bør du vælge mere kraftfulde masterknudepunkter. For eksempel kube-up den korrekte VM-størrelse for masterknuden afhængigt af antallet af arbejderknudepunkter. Det vil sige, at jo flere arbejderknudepunkter, jo mere produktive bør masterknudepunkterne 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 arbejderknudepunkter.
Ulempe #2: Flere faste omkostninger.
På hver arbejderknude kører Kubernetes et sæt systemdæmoner - disse inkluderer container-runtime (såsom Docker), kube-proxy og kubelet, inklusive cAdvisor. Sammen 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 en ti-core node med 10 GB hukommelse, så bruger dæmoner 1 % af klyngekapaciteten. På den anden side, på ti single-core noder med 1 GB hukommelse, vil dæmonerne tage 10% af klyngekapaciteten.
Jo færre noder, jo mere effektivt bruges infrastrukturen.
Ulempe nr. 3. Ineffektiv brug af ressourcer
På små noder kan det være, at de resterende ressourceklumper 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, hvilket efterlader 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 der vil kun være ét ubrugt fragment på 0,25 GB.
I dette tilfælde er kun 2,5 % af hukommelsen spildt.
Dermed bruges ressourcer mere optimalt på større knudepunkter.
Flere 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 et oplagt valg. Og hvis applikationen kræver tidoblet replikering for høj tilgængelighed, er det næppe værd at risikere at placere replikaer på kun to noder – der skal være minimum ti noder i klyngen.
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 noderne i samme størrelse. Intet forhindrer dig i først at eksperimentere med noder af samme 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ændig 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