NÀr man skapar en Kubernetes-kluster kan frÄgor uppstÄ: hur mÄnga arbetsnoder ska man konfigurera och av vilken typ? Vad Àr bÀst för en on-premise kluster: köpa flera kraftfulla servrar eller anvÀnda ett tiotal gamla maskiner i ditt datacenter? Och i molnet Àr det bÀttre att ta Ätta enskilda kÀrnor eller tvÄ fyrkÀrniga instanser?
Svar pÄ dessa frÄgor finns i artikeln översatt av teamet .
Kapacitet av kluster
Generellt kan en Kubernetes-kluster ses som en stor "supernod". Dess totala berÀkningskraft Àr summan av kapaciteterna hos alla enskilda noder.
Det finns flera sÀtt att uppnÄ önskad mÄlkraft för klustret. Till exempel, om vi behöver en kluster med en total kapacitet pÄ 8 CPU-kÀrnor och 32 GB RAM, eftersom applikationsuppsÀttningen krÀver en sÄdan mÀngd resurser. DÄ kan vi konfigurera tvÄ noder med 16 GB minne eller fyra noder med 8 GB minne, tvÄ fyrkÀrniga processorer eller fyra tvÄkÀrniga.
HÀr Àr bara tvÄ möjliga sÀtt att skapa en kluster:
BÄda alternativen ger en kluster med samma kapacitet, men i konfigurationen nedan finns fyra mindre noder, medan i konfigurationen ovan finns tvÄ större.
Vilket alternativ Àr bÀttre?
För att svara pÄ denna frÄga, lÄt oss titta pÄ fördelarna med bÄda alternativ.
Flera stora noder
MÄnga smÄ noder
Enklare hantering av klustret (om det Àr on-premise)
Smidigare autoskalning
Billigare (om on-premise)
Priserna skiljer sig lite (i molnet)
Kan köra resurskrÀvande applikationer
FullstÀndig replikering
Resurser anvÀnds effektivare (mindre overhead pÄ systemdemoner)
Högre klusterresiliens
Observera att vi endast talar om arbetsnoder. Valet av antal och storlek pÄ huvudnoderna Àr ett helt annat Àmne.
SÄ lÄt oss diskutera varje punkt i tabellen mer ingÄende.
Det första alternativet: flera stora noder
Det mest extrema alternativet Àr en enda arbetsnod för hela klusterkapaciteten. I exemplet ovan skulle detta vara en arbetsnod med 16 CPU-kÀrnor och 16 GB RAM.
Fördelar
Fördel nummer 1. Enklare hantering
Det Àr enklare att hantera flera maskiner Àn en hel park. Att snabbt rulla ut uppdateringar och fixar Àr lÀttare, och antalet fel i absoluta siffror Àr ocksÄ mindre.
Observera att allt som ovan nÀmns avser din egen hÄrdvara, dina egna servrar, och inte molninfrastruktur.
I molnet Àr situationen en annan. HÀr hanterar molnleverantören administrationen. DÀrför skiljer sig hanteringen av tio noder i molnet egentligen inte frÄn hanteringen av en enda nod.
Routing av trafik och lastfördelning mellan poddar i molnet : inkommande trafik frÄn internet dirigeras till den primÀra lastbalanseraren, som skickar trafiken till porten av en av noderna (NodePort-tjÀnsten sÀtter porten i intervallet 30000-32767 pÄ varje nod i klustret). Reglerna som stÀlls in av kube-proxy omdirigerar trafiken frÄn noden till podden. SÄ hÀr ser det ut för tio poddar pÄ tvÄ noder:
Fördel â 2. LĂ€gre kostnader per nod
En kraftfull maskin Àr dyrare, men prisökningen Àr inte nödvÀndigtvis linjÀr. Med andra ord, en server med tio kÀrnor och 10 GB minne Àr vanligtvis billigare Àn tio enmaskiner med samma mÀngd minne.
Men observera att denna regel vanligtvis inte gÀller för molntjÀnster. I de nuvarande prissÀttningsscheman hos alla större molnleverantörer ökar priserna linjÀrt med ökad kapacitet.
DÀrför Àr det vanligtvis inte möjligt att spara pÄ kraftfullare servrar i molnet.
Fördel â 3. Det gĂ„r att köra resurskrĂ€vande applikationer
Vissa applikationer krÀver kraftfulla servrar i klustret. Till exempel, om ett maskininlÀrningssystem krÀver 8 GB minne, kan du inte köra det pÄ noder med 1 GB, utan du behöver minst en stor arbetsnod.
Nackdelar
Nackdel â 1. MĂ„nga poddar per nod
Om samma uppgift utförs pÄ ett mindre antal noder, kommer det naturligtvis att finnas fler poddar pÄ var och en av dem.
Detta kan bli ett problem.
Anledningen Àr att varje modul medför en viss overhead för containermiljön (till exempel Docker), liksom kubelet och cAdvisor.
Till exempel, kubelet övervakar regelbundet alla containrar pĂ„ noden â ju fler containrar, desto mer arbete för kubelet.
CAdvisor samlar in statistik om resursanvÀndning frÄn alla containrar pÄ noden, och kubelet begÀr regelbundet denna information och tillhandahÄller den via API:et. Ju fler containrar, desto mer arbete för bÄde cAdvisor och kubelet.
Om antalet moduler ökar kan detta sakta ner systemet och till och med pÄverka dess tillförlitlighet negativt.
I Kubernetes-repositoriet har vissa , att noder hoppar mellan statusarna Ready/NotReady, eftersom kubelets regelbundna kontroller av alla containrar pÄ noden tar för lÄng tid.
Av denna anledning rekommenderar Kubernetes . Beroende pÄ nodens prestanda kan du köra fler pods per nod, men det Àr svÄrt att förutsÀga om problem uppstÄr eller om allt fungerar bra. Det Àr bra att testa driften i förvÀg.
Nackdel nr 2. BegrÀnsning av replikering
Ett för litet antal noder begrÀnsar den effektiva graden av replikering av applikationer. Till exempel, om du har en applikation med hög tillgÀnglighet med fem repliker, men bara tvÄ noder, minskar den effektiva graden av replikering till tvÄ.
Fem repliker kan endast fördelas pÄ tvÄ noder, och om en av dem gÄr ned, slÄs flera repliker ut direkt.
Om du har fem eller fler noder kommer varje replik att köras pÄ en separat nod, och ett nedbrott av en nod kommer att ta bort högst en replik.
SÄledes kan krav pÄ hög tillgÀnglighet krÀva ett visst minimalt antal noder i klustret.
Nackdel nr 3. Allvarligare konsekvenser av fel
Vid ett litet antal noder innebÀr varje fel mer allvarliga konsekvenser. Till exempel, om du har endast tvÄ noder och en gÄr ned, försvinner plötsligt hÀlften av dina moduler.
SjÀlvklart kommer Kubernetes att flytta arbetsbelastningen frÄn den nedlagda noden till andra. Men om det finns fÄ, kan det saknas ledig kapacitet. Som ett resultat blir en del av dina applikationer otillgÀngliga tills du ÄterstÀller den nedlagda noden.
DÀrför gÀller att ju fler noder, desto mindre inverkan av hÄrdvarufel.
Nackdel nr 4. Fler steg i automatisk skalning
I Kubernetes fungerar ett system för automatisk skalning av kluster för molninfrastruktur, vilket gör att noder automatiskt kan lÀggas till eller tas bort beroende pÄ aktuella behov. Med stora noder blir automatisk skalning mer drastisk och klumpig. Till exempel, med tvÄ noder, ökar tillÀgget av en extra nod klustrets kapacitet med 50% direkt. Och du mÄste betala för dessa resurser, Àven om du inte behöver dem.
SĂ„ om du planerar att anvĂ€nda automatisk skalning av klustret, ju mindre noder â desto mer flexibel och kostnadseffektiv skalning fĂ„r du.
LÄt oss nu titta pÄ fördelarna och nackdelarna med mÄnga smÄ noder.
Andra alternativet: mÄnga smÄ noder
Fördelarna med detta tillvÀgagÄngssÀtt hÀrstammar i grunden frÄn nackdelarna med motsvarande alternativ med nÄgra stora noder.
Fördelar
Fördel nr 1. Mindre konsekvenser av fel
Ju fler noder, desto fÀrre pods per nod. Till exempel, om du har hundra moduler pÄ tio noder, sÄ finns det i genomsnitt tio moduler pÄ varje nod.
SÄ om en av noderna gÄr ner förlorar du endast 10% av arbetsbelastningen. Det finns sannolikhet att endast ett fÄtal repliker trÀffas, och applikationerna förblir i stort sett aktiva.
Dessutom, pÄ de ÄterstÄende noderna, finns det troligtvis tillrÀckligt med lediga resurser för arbetsbelastningen frÄn den misslyckade noden, sÄ Kubernetes kan fritt omplanera pods, och dina applikationer ÄtergÄr relativt snabbt till funktionellt tillstÄnd.
Fördel nr 2. Bra replikering
Om det finns tillrÀckligt med noder kan Kubernetes schemalÀggare tilldela alla repliker olika noder. SÄ om en nod faller kommer endast en replik att pÄverkas, och applikationen förblir tillgÀnglig.
Nackdelar
Nackdel nr 1. SvÄrare att hantera
Det Àr svÄrare att hantera mÄnga noder. Till exempel, varje Kubernetes-nod mÄste kommunicera med alla andra, vilket betyder att antalet kopplingar vÀxer kvadratiskt, och alla dessa kopplingar mÄste övervakas.
Nodekontrollern i Kubernetes controller manager gĂ„r regelbundet igenom alla noder i klustret för att kontrollera deras status â ju fler noder, desto större belastning pĂ„ kontrollern.
Belastningen pĂ„ etcd-databasen ökar ocksĂ„ â varje kubelet och kube-proxy anropar för etcd (via API), som etcd mĂ„ste förmedla objektuppdateringar till.
Generellt sett lÀgger varje arbetsnod en extra belastning pÄ systemkomponenterna pÄ huvudnoderna.
Officiellt stöder Kubernetes kluster med Men i praktiken kan redan 500 noder .
För att hantera ett stort antal arbetsnoder bör man vÀlja mer kraftfulla huvudnoder. Till exempel installerar kube-up den rÀtta storleken pÄ VM för huvudnoden beroende pÄ antalet arbetsnoder. Det vill sÀga, ju fler arbetsnoder, desto mer kraftfulla mÄste huvudnoderna vara.
För att lösa dessa specifika problem finns det speciella lösningar som Detta system gör det möjligt att kringgÄ begrÀnsningarna och bygga kluster med ett enormt antal arbetsnoder.
Nackdel nr 2. Större overhead
PĂ„ varje arbetsnod kör Kubernetes en uppsĂ€ttning systemdemoner â dessa inkluderar container-runtime (till exempel Docker), kube-proxy och kubelet, inklusive cAdvisor. Tillsammans förbrukar de en viss fast mĂ€ngd resurser.
Om du har mÄnga smÄ noder Àr andelen av dessa overhead pÄ varje nod större. TÀnk till exempel pÄ att alla systemdemoner pÄ en nod tillsammans anvÀnder 0,1 CPU-kÀrnor och 0,1 GB minne. Om du har en tio-kÀrnig nod med 10 GB minne, förbrukar demonarna 1 % av klusterkapaciteten. à andra sidan, pÄ tio en-kÀrniga noder med 1 GB minne, kommer demonarna att ta 10 % av klusterkapaciteten.
SÄledes, ju fÀrre noder, desto mer effektivt utnyttjas infrastrukturen.
Nackdel nr 3. Ineffektiv resursanvÀndning
PÄ smÄ noder kan det uppstÄ en situation dÀr de ÄterstÄende resurserna Àr för smÄ för att kunna tilldelas nÄgon arbetsbelastning, vilket gör att de förblir oanvÀnda.
Till exempel krĂ€ver varje pod 0,75 GB minne. Om du har tio noder och varje har 1 GB minne, kan du köra tio poddar â vilket innebĂ€r att det pĂ„ varje nod finns 0,25 GB oanvĂ€nt minne kvar.
Detta betyder att 25 % av minnet i hela klustret slösas bort.
PĂ„ en stor nod med 10 GB minne kan du köra 13 sĂ„dana moduler â och det kommer att finnas bara en överbliven del av 0,25 GB.
I det hÀr fallet slösas endast 2,5 % av minnet.
PÄ sÄ sÀtt utnyttjas resurserna bÀttre pÄ stora noder.
Flera stora noder eller mÄnga smÄ?
SÄ vad Àr bÀttre: flera stora noder i en kluster eller mÄnga smÄ? Som alltid finns det inget entydigt svar. Mycket beror pÄ applikationstypen.
Till exempel, om applikationen krĂ€ver 10 GB minne, Ă€r valet uppenbart till förmĂ„n för stora noder. Om applikationen dĂ€remot krĂ€ver tiofaldig replikering för hög tillgĂ€nglighet, bör man knappast ta risken att placera replikat endast pĂ„ tvĂ„ noder â klustret bör ha minst tio noder.
I mellansituationer, gör valet baserat pÄ fördelar och nackdelar med varje alternativ. Kanske Àr vissa argument mer relevanta för din situation Àn andra.
Och det Àr inte nödvÀndigt att göra alla noder av samma storlek. Inget hindrar att experimentera först med noder av en storlek och sedan lÀgga till noder av en annan storlek, för att kombinera dem i klustret. Arbetande noder i Kubernetes-klustret kan vara helt heterogena. SÄ man kan försöka kombinera fördelarna med bÄda tillvÀgagÄngssÀtten.
Det finns inget universellt recept, och varje situation har sina nyanser, och endast produktionen kommer att avslöja sanningen.
ĂversĂ€ttningen har förberetts av teamet för molnplattformen .
Mer om Kubernetes: .
KĂ€lla: habr.com
