När du skapar ett Kubernetes-kluster kan frågor uppstå: hur många arbetarnoder ska konfigureras och vilken typ? Vad är bättre för ett lokalt kluster: köp flera kraftfulla servrar eller använd ett dussin gamla maskiner i ditt datacenter? Är det bättre att ta åtta enkelkärniga eller två fyrkärniga instanser i molnet?
Svaren på dessa frågor finns i artikeln. i översättningen av kommandot .
Klusterkapacitet
I allmänhet kan ett Kubernetes-kluster ses som en stor "supernod". Dess totala beräkningskraft är summan av styrkorna för alla dess ingående noder.
Det finns flera sätt att uppnå ditt önskade klusterkapacitetsmål. Till exempel behöver vi ett kluster med en total kapacitet på 8 processorkärnor och 32 GB RAM eftersom en uppsättning applikationer kräver så många resurser. Sedan kan du installera två noder med 16 GB minne eller fyra noder med 8 GB minne, två fyrkärniga processorer eller fyra dual-core.
Här är bara två möjliga sätt att skapa ett kluster:
Båda alternativen ger ett kluster med samma kapacitet, men den nedre konfigurationen har fyra mindre noder och den övre konfigurationen har två större noder.
Vilket alternativ är bättre?
För att svara på denna fråga, låt oss titta på fördelarna med båda alternativen. Vi har sammanfattat dem i en tabell.
Flera stora noder
Många små noder
Enklare klusterhantering (om det är på plats)
Smidig autoskalning
Billigare (om på plats)
Цена мало отличается (в облаке)
Kan köra resurskrävande applikationer
Full replikering
Resurser används mer effektivt (mindre overhead på systemdemoner
Högre klusterfeltolerans
Observera att vi bara pratar om arbetarnoder. Att välja antal och storlek på huvudnoder är ett helt annat ämne.
Så låt oss diskutera varje punkt från tabellen mer i detalj.
Första alternativet: flera stora noder
Det mest extrema alternativet är en arbetarnod för hela klusterkapaciteten. I exemplet ovan skulle detta vara en enda arbetarnod med 16 CPU-kärnor och 16 GB RAM.
Fördelar
Plus nr 1. Enklare hantering
Det är lättare att hantera ett fåtal maskiner än en hel flotta. Det går snabbare att lansera uppdateringar och korrigeringar, och det är lättare att synkronisera. Antalet misslyckanden i absoluta tal är också färre.
Observera att allt ovanstående gäller din hårdvara, dina servrar och inte molninstanser.
Situationen är annorlunda i molnet. Där sköts hanteringen av molntjänstleverantören. Att hantera tio noder i molnet skiljer sig alltså inte mycket från att hantera en nod.
Trafikdirigering och lastfördelning mellan poddar i molnet : trafik som kommer från Internet skickas till huvudlastbalanseraren, som vidarebefordrar trafik till porten på en av noderna (NodePort-tjänsten ställer in porten i intervallet 30000-32767 i varje klusternod). Reglerna som sätts av kube-proxy omdirigerar trafik från noden till podden. Så här ser det ut för tio baljor på två noder:
Pro #2: Mindre kostnad per nod
En kraftfull bil är dyrare, men prisökningen är inte nödvändigtvis linjär. Med andra ord är en tiokärnig server med 10 GB minne vanligtvis billigare än tio enkärniga servrar med samma mängd minne.
Men observera att denna regel vanligtvis inte fungerar i molntjänster. I de nuvarande prissättningssystemen för alla större molnleverantörer ökar priserna linjärt med kapaciteten.
I molnet kan du alltså vanligtvis inte spara på mer kraftfulla servrar.
Pro #3: Du kan köra resurskrävande applikationer
Vissa applikationer kräver kraftfulla servrar i ett kluster. Till exempel, om ett maskininlärningssystem kräver 8 GB minne, kommer du inte att kunna köra det på 1 GB-noder, utan bara med minst en stor arbetarnod.
Nackdelar
Nackdel nr 1. Många baljor per nod
Om samma uppgift utförs på färre noder, kommer var och en av dem naturligtvis att ha fler pods.
Detta kan vara ett problem.
Anledningen är att varje modul introducerar viss overhead till containerkörningstiden (t.ex. Docker), såväl som kubelet och cAdvisor.
Till exempel undersöker en kubelet regelbundet alla behållare på en nod för överlevnad – ju fler behållare, desto mer arbete måste kubelet göra.
CAdvisor samlar in resursanvändningsstatistik för alla behållare på en nod, och kubelet frågar regelbundet efter denna information och tillhandahåller den via ett API. Återigen betyder fler behållare mer arbete för både cAdvisor och kubelet.
Om antalet moduler ökar kan det sakta ner systemet och till och med undergräva dess tillförlitlighet.
I Kubernetes repository några att noder hoppar mellan Ready/NotReady-statusar eftersom regelbundna kubeletkontroller av alla behållare på en nod tar för lång tid.
Av denna anledning Kubernetes . Beroende på nodens prestanda kan du köra fler pods per nod, men det är svårt att förutse om det kommer att bli problem eller om allt kommer att fungera bra. Det är värt att testa arbetet i förväg.
Nackdel nr 2. Begränsning av replikering
För få noder begränsar den effektiva omfattningen av applikationsreplikering. Om du till exempel har en applikation med hög tillgänglighet med fem repliker men bara två noder, reduceras programmets effektiva replikeringsgrad till två.
Fem repliker kan bara fördelas över två noder, och om en av dem misslyckas kommer den att ta ner flera repliker samtidigt.
Om du har fem noder eller fler kommer varje replik att köras på en separat nod, och fel på en nod tar bort högst en replik.
Således kan höga tillgänglighetskrav kräva ett visst minsta antal noder i klustret.
Nackdel nr 3. Värre konsekvenser av misslyckande
Med ett litet antal noder får varje fel allvarligare konsekvenser. Till exempel, om du bara har två noder och en av dem misslyckas, försvinner hälften av dina moduler direkt.
Naturligtvis kommer Kubernetes att migrera arbetsbelastningen från den misslyckade noden till andra. Men om det är få av dem kanske det inte finns tillräckligt med ledig kapacitet. Som ett resultat kommer vissa av dina applikationer att vara otillgängliga förrän du tar upp den misslyckade noden.
Således, ju fler noder, desto mindre påverkan av hårdvarufel.
Nackdel #4: Fler autoskalningssteg
Kubernetes har ett automatiskt skalningssystem för kluster för molninfrastruktur, vilket gör att du automatiskt kan lägga till eller ta bort noder beroende på dina aktuella behov. Med större noder blir automatisk skalning mer abrupt och klumpig. Till exempel, på två noder, kommer att lägga till en extra nod omedelbart öka klusterkapaciteten med 50 %. Och du måste betala för dessa resurser, även om du inte behöver dem.
Således, om du planerar att använda automatisk klusterskalning, ju mindre noderna är, desto mer flexibel och kostnadseffektiv skalning får du.
Låt oss nu titta på fördelarna och nackdelarna med ett stort antal små noder.
Andra alternativet: många små noder
Fördelarna med detta tillvägagångssätt härrör i huvudsak från nackdelarna med det motsatta alternativet med flera stora noder.
Fördelar
Pro #1: Mindre påverkan av misslyckande
Ju fler noder, desto färre pods på varje nod. Till exempel, om du har hundra moduler per tio noder, kommer varje nod att ha i genomsnitt tio moduler.
På så sätt, om en av noderna misslyckas, förlorar du bara 10 % av arbetsbelastningen. Chansen är stor att endast ett litet antal repliker kommer att påverkas och den övergripande applikationen kommer att fortsätta att fungera.
Dessutom kommer de återstående noderna sannolikt att ha tillräckligt med lediga resurser för att hantera arbetsbelastningen för den misslyckade noden, så Kubernetes kan fritt schemalägga podarna och dina applikationer kommer att återgå till ett funktionellt tillstånd relativt snabbt.
Pro #2: Bra replikering
Om det finns tillräckligt med noder kan Kubernetes-schemaläggaren tilldela olika noder till alla repliker. På så sätt, om en nod misslyckas, kommer endast en replik att påverkas och applikationen förblir tillgänglig.
Nackdelar
Nackdel nr 1. Svår att kontrollera
Ett stort antal noder är svårare att hantera. Till exempel måste varje Kubernetes-nod kommunicera med alla andra, det vill säga antalet anslutningar växer kvadratiskt, och alla dessa anslutningar måste spåras.
Nodkontrollanten i Kubernetes Controller Manager går regelbundet igenom alla noder i klustret för att kontrollera hälsan - ju fler noder, desto mer belastning på kontrollern.
Belastningen på etcd-databasen ökar också - varje kubelet och kube-proxy anropar för etcd (via API), till vilken etcd ska sända objektuppdateringar.
I allmänhet lägger varje arbetarnod ytterligare belastning på masternodernas systemkomponenter.
Kubernetes stöder officiellt kluster med . Men i praktiken finns det redan 500 noder .
För att hantera ett stort antal arbetarnoder bör du välja mer kraftfulla masternoder. Till exempel kube-up правильный размер VM для главного узла в зависимости от количества рабочих узлов. То есть чем больше рабочих узлов, тем более производительными должны быть главные узлы.
För att lösa dessa specifika problem finns speciella utvecklingar, som t.ex . Detta system låter dig kringgå begränsningar och bygga kluster med ett stort antal arbetarnoder.
Nackdel #2: Mer omkostnader.
På varje arbetarnod kör Kubernetes en uppsättning systemdemoner - dessa inkluderar behållarens körtid (som 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 denna overhead på varje nod större. Föreställ dig till exempel att alla systemdemoner på en enda nod tillsammans använder 0,1 CPU-kärnor och 0,1 GB minne. Om du har en nod med tio kärnor med 10 GB minne, så förbrukar demoner 1 % av klusterkapaciteten. Å andra sidan, på tio enkärniga noder med 1 GB minne, kommer demonerna att ta 10 % av klusterkapaciteten.
Således, ju färre noder, desto mer effektivt används infrastrukturen.
Nackdel nr 3. Ineffektiv resursanvändning
På små noder kan det vara så att de återstående resursbitarna är för små för att tilldela någon arbetsbelastning, så de förblir oanvända.
Till exempel kräver varje pod 0,75 GB minne. Om du har tio noder, var och en med 1 GB minne, kan du köra tio pods, vilket ger varje nod 0,25 GB oanvänt minne.
Det betyder att 25 % av hela klustrets minne går till spillo.
På en stor nod med 10 GB minne kan du köra 13 av dessa moduler – och det blir bara ett oanvänt fragment på 0,25 GB.
I det här fallet går bara 2,5 % av minnet till spillo.
Därmed används resurser mer optimalt på större noder.
Flera stora noder eller många små?
Så, vilket är bättre: några stora noder i ett kluster eller många små? Som alltid finns det inget klart svar. Mycket beror på typen av applikation.
Till exempel, om en applikation kräver 10 GB minne är större noder ett självklart val. Och om en applikation kräver tiofaldig replikering för hög tillgänglighet är det knappast värt risken att placera repliker på bara två noder – det måste finnas minst tio noder i klustret.
I mellanliggande situationer, gör ett val baserat på fördelarna och nackdelarna med varje alternativ. Kanske är vissa argument mer relevanta för din situation än andra.
Och det är inte alls nödvändigt att göra alla noder i samma storlek. Ingenting hindrar dig från att först experimentera med noder av samma storlek och sedan lägga till noder av en annan storlek och kombinera dem i ett kluster. Arbetarnoder i ett Kubernetes-kluster kan vara helt heterogena. Så du kan försöka kombinera fördelarna med båda tillvägagångssätten.
Det finns inget enskilt recept, och varje situation har sina egna nyanser, och bara produktionen kommer att visa sanningen.
Översättning utarbetad av molnplattformsteamet .
Mer om Kubernetes: .
Källa: will.com