Kubernetes arbetarnoder: många små noder eller några få stora noder?

När man skapar ett Kubernetes-kluster kan frågor uppstå: hur många arbetsnoder ska jag konfigurera och vilken typ? Vad är bättre för ett lokalt kluster: att köpa flera kraftfulla servrar eller att använda ett dussin gamla maskiner i ditt datacenter? Och i molnet, är det bättre att ta åtta enkärniga eller två fyrkärniga instanser?

Svaren på dessa frågor finns i artikeln Daniel Weibel, mjukvaruingenjör och lärare på utbildningsprojektet Learnk8s i lagets översättning Kubernetes aaS från Mail.ru.

Klusterkapacitet

I allmänhet kan ett Kubernetes-kluster betraktas som en stor "supernod". Dess totala beräkningskraft är summan av kraften hos alla dess ingående noder.

Det finns flera sätt att uppnå den önskade målkapaciteten för ett kluster. Till exempel behöver vi ett kluster med en total kapacitet på 8 processorkärnor och 32 GB RAM eftersom uppsättningen applikationer kräver den mängden resurser. Sedan kan du installera två noder med 16 GB minne eller fyra noder med 8 GB minne, två fyrkärniga processorer eller fyra dubbelkärniga processorer.

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, medan den övre konfigurationen har två större noder.

Vilket alternativ är bättre?

För att besvara denna fråga, låt oss titta på fördelarna med båda alternativen. Vi har sammanfattat dem i en tabell.

Flera stora noder

Massor av små knutar

Enklare klusterhantering (om det sker lokalt)

Smidig autoskalning

Billigare (om det sker på plats)

Priset är inte mycket annorlunda (i molnet)

Du kan köra resurskrävande applikationer

Fullständig replikering

Resurser används mer effektivt (mindre omkostnader för systemdaemoner)
Högre feltolerans i klustret

Observera att vi bara talar om fungerande noder. Att välja antal och storlek på masternoder är en helt annan fråga.

Så, låt oss diskutera varje punkt från tabellen mer i detalj.

Alternativ 1: Flera stora noder

Det mest extrema alternativet är en arbetsnod för hela klusterkapaciteten. I exemplet ovan skulle detta vara en arbetsnod med 16 CPU-kärnor och 16 GB RAM.

Fördelar

Plusnummer 1. Lättare att kontrollera
Det är lättare att hantera ett fåtal bilar än en hel flotta. Lansera uppdateringar och korrigeringar snabbare, synkronisera enklare. Antalet misslyckanden i absoluta tal är också lägre.

Observera att allt ovanstående gäller din egen hårdvara, dina egna servrar och inte molninstanser.

I molnet är situationen annorlunda. Där hanteras hanteringen av en molntjänstleverantör. Att hantera tio noder i molnet skiljer sig således inte mycket från att hantera en nod.

Trafikdirigering och lastbalansering mellan poddar i molnet utförs automatiskttrafik som kommer från internet dirigeras till den huvudsakliga lastbalanseraren, som dirigerar trafiken till porten för en av noderna (NodePort-tjänsten anger en port i intervallet 30000-32767 på varje klusternod). Reglerna som anges av kube-proxy omdirigerar trafik från noden till poden. Så här ser det ut för tio poddar på två noder:

Plus #2: Lägre 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 den här regeln vanligtvis inte fungerar i molntjänster. I de nuvarande prissättningssystemen hos alla större molnleverantörer ökar priserna linjärt med kapaciteten.

Så i molnet kan man oftast inte spara pengar på kraftfullare servrar.

Fördel #3: Du kan köra resurskrävande applikationer
Vissa applikationer kräver kraftfulla servrar i ett kluster. Om till exempel ett maskininlärningssystem kräver 8 GB minne kommer du inte att kunna köra det på 1 GB noder om du inte har minst en stor arbetsnod.

Nackdelar

Nackdelar #1: För många poddar per nod
Om samma uppgift utförs på färre noder, kommer var och en av dem naturligtvis att ha fler poddar.

Detta kan vara ett problem.

Anledningen är att varje pod introducerar en viss overhead för containerkörningen (t.ex. Docker) samt kubelet och cAdvisor.

Till exempel undersöker kubelet regelbundet alla containrar på en nod för överlevnad - ju fler containrar, desto mer arbete måste kubelet göra.

CAdvisor samlar in statistik om resursanvändning från alla containrar på en nod, och kubelet frågar regelbundet efter denna information och tillhandahåller den via ett API. Återigen, ju fler containrar, desto mer arbete för både cAdvisor och kubelet.

Om antalet moduler ökar kan det göra systemet långsammare och till och med undergräva dess tillförlitlighet.

Det finns några i Kubernetes-förvaret klagade, att noder hoppar mellan statusarna Klar/Inte klar eftersom vanliga kubelet-kontroller av alla containrar på noden tar för lång tid.
Av denna anledning, Kubernetes rekommenderar att man placerar högst 110 poddar per nod. Beroende på nodens prestanda kan du köra fler poddar per nod, men det är svårt att förutsäga om det kommer att bli problem eller om allt kommer att fungera bra. Det är värt att testa arbetet i förväg.

Minus #2. Replikeringsbegränsning
För få noder begränsar den effektiva graden av applikationsreplikering. Om du till exempel har ett program med hög tillgänglighet med fem repliker men bara två noder, reduceras programmets effektiva replikeringsgrad till två.

Fem repliker kan bara distribueras över två noder, och om en av dem misslyckas tas flera repliker omedelbart bort.

Om du har fem eller fler noder kommer varje replik att köras på en separat nod, och ett enskilt nodfel tar bort högst en replik.

Således kan höga tillgänglighetskrav kräva ett visst minsta antal noder i ett kluster.

Minus #3. Värre konsekvenser av misslyckande
Med ett litet antal noder får varje fel allvarligare konsekvenser. Om du till exempel bara har två noder och en av dem misslyckas, försvinner hälften av dina moduler på en gång.

Självklart kommer Kubernetes att migrera arbetsbelastningen från den felaktiga noden till andra. Men om det finns få av dem, kanske det inte finns tillräckligt med ledig kapacitet. Som ett resultat kommer vissa av dina applikationer att vara otillgängliga tills du återställer den felaktiga noden.

Således, ju fler noder, desto mindre påverkan har hårdvarufel.

Minus #4. Fler steg för autoskalning
Kubernetes tillhandahåller ett system för autoskalning av kluster för molninfrastruktur, vilket gör att noder kan läggas till eller tas bort automatiskt baserat på aktuella behov. Med större noder blir autoskalning mer ryckig och klumpig. Till exempel, på två noder, kommer att lägga till ytterligare en nod att öka klusterkapaciteten med 50 % samtidigt. Och du kommer att behöva betala för dessa resurser, även om du inte behöver dem.

Så om du planerar att använda klusterautomatisk skalning, ju mindre noderna är, desto mer flexibel och kostnadseffektiv blir skalningen.

Nu ska vi titta på fördelarna och nackdelarna med att ha ett stort antal små noder.

Alternativ 2: Många små noder

Fördelarna med denna metod följer i huvudsak av nackdelarna med det motsatta alternativet med flera stora noder.

Fördelar

Fördel #1: Mindre påverkan av misslyckanden
Ju fler noder, desto färre poddar på varje nod. Om du till exempel har hundra moduler på tio noder, kommer varje nod att ha i genomsnitt tio moduler.

Så om en nod går sönder förlorar du bara 10 % av din arbetsbelastning. Det är troligt att endast ett litet antal repliker påverkas och att applikationerna som helhet kommer att förbli fungerande.

Dessutom kommer de återstående noderna sannolikt att ha tillräckligt med reservkapacitet för att hantera den felaktiga nodens arbetsbelastning, så Kubernetes kan fritt omschemalägga poddar och dina applikationer kommer att vara igång igen relativt snabbt.

Plus #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, påverkas endast en replik och programmet förblir tillgängligt.

Nackdelar

Minus #1: Svårare att kontrollera
Ett stort antal noder är svårare att hantera. Till exempel måste varje Kubernetes-nod kommunicera med alla andra, vilket innebär att 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 deras hälsa – ju fler noder, desto mer belastning på kontrollanten.

Belastningen på etcd-databasen ökar också - varje kubelet- och kube-proxy-anrop bevakare för etcd (via API:et) till vilken etcd ska sända objektuppdateringar.

I allmänhet lägger varje arbetsnod en extra belastning på systemkomponenterna i huvudnoderna.

Kubernetes stöder officiellt kluster med antal noder upp till 5000. I praktiken finns det dock redan 500 noder kan orsaka icke-triviala problem.

För att hantera ett stort antal arbetsnoder bör effektivare huvudnoder väljas. Till exempel, kube-up installeras automatiskt rätt VM-storlek för huvudnoden beroende på antalet arbetsnoder. Det vill säga, ju fler fungerande noder, desto mer produktiva måste huvudnoderna vara.

För att lösa dessa specifika problem finns det särskilda utvecklingar, som t.ex. Virtuell Kubelet. Det här systemet låter dig kringgå begränsningar och bygga kluster med ett stort antal fungerande noder.

Nackdelar #2: Mer omkostnader
På varje arbetsnod kör Kubernetes en uppsättning systemdaemoner – dessa inkluderar containerkörningen (t.ex. 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. Tänk dig till exempel att alla systemdaemoner på en enda nod tillsammans använder 0,1 CPU-kärnor och 0,1 GB minne. Om du har en nod med 10 kärnor och 1 GB minne förbrukar daemoner 1 % av klusterkapaciteten. Å andra sidan, på tio noder med en enda kärna och 10 GB minne, kommer daemonerna att ta upp XNUMX % av klusterkapaciteten.

Således, ju färre noder, desto effektivare används infrastrukturen.

Minus #3: Ineffektiv resursanvändning
På små noder kan det vara så att de återstående resursfragmenten ä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 poddar, vilket lämnar varje nod med 0,25 GB oanvänt minne.

Det betyder att 25 % av hela klustrets minne är slösat bort.

På en stor nod med 10 GB minne kan du köra 13 av dessa moduler och fortfarande bara ha en oanvänd bit på 0,25 GB kvar.

I det här fallet går endast 2,5 % av minnet till spillo.

Således används resurser mer optimalt på stora noder.

Några få 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 tydligt svar. Mycket beror på typen av applikation.

Om till exempel en applikation kräver 10 GB minne är större noder det självklara valet. 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 – klustret bör ha minst tio noder.

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 knutar lika stora. Det finns inget som hindrar dig från att först experimentera med noder av en storlek, sedan lägga till noder av en annan storlek till dem 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 metoderna.

Det finns inget enda recept, och varje situation har sina egna nyanser, och endast produktionen kommer att visa sanningen.

Översättning utarbetad av molnplattformsteamet Mail.ru molnlösningar.

Mer om Kubernetes: 25 användbara verktyg för att hantera och distribuera kluster.

Källa: will.com