För att helt behärska Kubernetes behöver du känna till olika sätt att skala klusterresurser: efter , detta är en av Kubernetes huvuduppgifter. Vi har tillhandahållit en översikt på hög nivå över horisontell och vertikal autoskalning och mekanismer för klusterstorleksändring, samt rekommendationer om hur man använder dem effektivt.
artikel översatt av teamet som implementerade automatisk skalning .
Varför det är viktigt att tänka på skalning
- ett verktyg för resurshantering och orkestrering. Naturligtvis är det trevligt att mixtra med de coola funktionerna i att distribuera, övervaka och hantera pods (en pod är en grupp behållare som lanseras som svar på en förfrågan).
Men du bör också tänka på följande frågor:
- Hur skalar man moduler och applikationer?
- Hur håller man containrar operativa och effektiva?
- Hur ska man svara på ständiga förändringar i kod och arbetsbelastningar från användare?
Att konfigurera Kubernetes-kluster för att balansera resurser och prestanda kan vara utmanande och kräver expertkunskaper om Kubernetes inre funktioner. Arbetsbelastningen för din applikation eller dina tjänster kan fluktuera under dagen eller till och med en timme, så balansering ses bäst som en pågående process.
Kubernetes autoskalningsnivåer
Effektiv autoskalning kräver samordning mellan två nivåer:
- Podnivå, inklusive horisontell (Horizontal Pod Autoscaler, HPA) och vertikal autoscaler (Vertical Pod Autoscaler, VPA). Detta skalar de tillgängliga resurserna för dina behållare.
- Klusternivå, som hanteras av Cluster Autoscaler (CA), som ökar eller minskar antalet noder inom klustret.
Horisontell Autoscaler (HPA) modul
Som namnet antyder, skalar HPA antalet pod-repliker. De flesta devops använder CPU och minnesbelastning som triggers för att ändra antalet repliker. Det går dock att skala systemet utifrån , deras eller .
Driftschema för HPA på hög nivå:
- HPA kontrollerar kontinuerligt de metriska värden som anges under installationen med ett standardintervall på 30 sekunder.
- HPA försöker öka antalet moduler om den angivna tröskeln nås.
- HPA uppdaterar antalet repliker inom distributions-/replikeringskontrollern.
- Driftsättnings-/replikeringskontrollern distribuerar sedan alla nödvändiga ytterligare moduler.
HPA startar moduldistributionsprocessen när en metrisk tröskel nås
Tänk på följande när du använder HPA:
- Standard HPA-kontrollintervall är 30 sekunder. Den sätts av flaggan horisontell-pod-autoscaler-sync-period i controller manager.
- Det relativa standardfelet är 10 %.
- Efter den senaste ökningen av antalet moduler räknar HPA med att mätvärdena stabiliseras inom tre minuter. Detta intervall ställs in av flaggan horisontell-pod-autoscaler-upscale-delay.
- Efter den senaste minskningen av antalet moduler väntar HPA i fem minuter för att stabilisera sig. Detta intervall ställs in av flaggan horisontell-pod-autoscaler-downscale-delay.
- HPA fungerar bäst med distributionsobjekt snarare än replikeringskontroller. Horisontell autoskalning är inkompatibel med rullande uppdatering, som direkt manipulerar replikeringskontroller. Med distribution beror antalet repliker direkt på distributionsobjekten.
Vertikal autoskalning av poddar
Vertikal autoskalning (VPA) allokerar mer (eller mindre) CPU-tid eller minne till befintliga pods. Lämplig för statliga eller statslösa pods, men främst avsedda för statliga tjänster. Däremot kan du också använda VPA för tillståndslösa moduler om du behöver automatiskt justera mängden initialt tilldelade resurser.
VPA svarar också på OOM-händelser (out of memory). För att ändra CPU-tid och minne måste du starta om podarna. Vid omstart respekterar VPA tilldelningsbudgeten () för att garantera det minsta nödvändiga antalet moduler.
Du kan ställa in lägsta och maximala resurser för varje modul. Således kan du begränsa den maximala mängden tilldelat minne till 8 GB. Detta är användbart om de nuvarande noderna definitivt inte kan allokera mer än 8 GB minne per behållare. Detaljerade specifikationer och manövermekanism beskrivs i .
Dessutom har VPA en intressant rekommendationsfunktion (VPA Recommender). Den övervakar resursanvändning och OOM-händelser för alla moduler för att föreslå nya minnes- och CPU-tidsvärden baserade på en intelligent algoritm baserad på historiska mätvärden. Det finns också ett API som tar ett pod-handtag och returnerar föreslagna resursvärden.
Det är värt att notera att VPA Recommender inte spårar resurs "limit". Detta kan resultera i att modulen monopoliserar resurser inom noder. Det är bättre att sätta gränsen på namnutrymmesnivå för att undvika enorm minnes- eller CPU-förbrukning.
VPA-driftschema på hög nivå:
- VPA kontrollerar kontinuerligt de metriska värden som anges under installationen med ett standardintervall på 10 sekunder.
- Om den specificerade tröskeln nås försöker VPA ändra den tilldelade mängden resurser.
- VPA uppdaterar antalet resurser inom distributions-/replikeringskontrollern.
- När moduler startas om tillämpas alla nya resurser på de skapade instanserna.
VPA lägger till den nödvändiga mängden resurser
Tänk på följande när du använder VPA:
- Skalning kräver en obligatorisk omstart av podden. Detta är nödvändigt för att undvika instabil drift efter ändringar. För tillförlitligheten startas moduler om och distribueras över noder baserat på nyligen allokerade resurser.
- VPA och HPA är ännu inte kompatibla med varandra och kan inte köras på samma pods. Om du använder båda skalningsmekanismerna i samma kluster, se till att dina inställningar förhindrar att de aktiveras på samma objekt.
- VPA justerar containerförfrågningar för resurser endast baserat på tidigare och nuvarande användning. Den anger inga gränser för resursanvändning. Det kan finnas problem med att applikationer inte fungerar korrekt och börjar ta över fler och fler resurser, detta kommer att leda till att Kubernetes stänger av denna pod.
- VPA är fortfarande på ett tidigt stadium av utvecklingen. Var beredd på att systemet kan genomgå vissa förändringar inom en snar framtid. Du kan läsa om и . Det finns alltså planer på att implementera den gemensamma driften av VPA och HPA, såväl som utbyggnaden av moduler tillsammans med en vertikal autoskalningspolicy för dem (till exempel en speciell etikett "kräver VPA").
Automatisk skalning av ett Kubernetes-kluster
Cluster Autoscaler (CA) ändrar antalet noder baserat på antalet väntande pods. Systemet kontrollerar periodiskt efter väntande moduler - och ökar klusterstorleken om fler resurser behövs och om klustret inte överskrider de fastställda gränserna. CA kommunicerar med molntjänstleverantören, begär ytterligare noder från den eller släpper lediga. Den första allmänt tillgängliga versionen av CA introducerades i Kubernetes 1.8.
System på hög nivå för SA-drift:
- CA söker efter väntande moduler med ett standardintervall på 10 sekunder.
- Om en eller flera poddar är i ett standbyläge eftersom klustret inte har tillräckligt med tillgängliga resurser för att tilldela dem, försöker det tillhandahålla en eller flera ytterligare noder.
- När molntjänstleverantören allokerar den nödvändiga noden ansluter den sig till klustret och är redo att servera poddarna.
- Kubernetes-schemaläggaren distribuerar väntande pods till en ny nod. Om efter detta några moduler fortfarande förblir i ett vänteläge, upprepas processen och nya noder läggs till i klustret.
Automatisk provisionering av klusternoder i molnet
Tänk på följande när du använder CA:
- CA ser till att alla poddar i klustret har utrymme att köra, oavsett CPU-belastning. Den försöker också säkerställa att det inte finns några onödiga noder i klustret.
- CA registrerar behovet av skalning efter cirka 30 sekunder.
- När en nod inte längre behövs väntar CA som standard 10 minuter innan systemet skalas ut.
- Autoskalningssystemet har konceptet expanders. Det här är olika strategier för att välja en grupp av noder som nya noder ska läggas till.
- Använd alternativet ansvarsfullt cluster-autoscaler.kubernetes.io/safe-to-evict (true). Om du installerar många pods, eller om många av dem är utspridda över alla noder, kommer du till stor del att förlora förmågan att skala ut klustret.
- användning för att förhindra att poddar tas bort, vilket kan göra att delar av din applikation misslyckas helt.
Hur Kubernetes autoscalers interagerar med varandra
För perfekt harmoni bör autoskalning tillämpas på både podnivå (HPA/VPA) och klusternivå. De interagerar med varandra relativt enkelt:
- HPA:er eller VPA:er uppdaterar pod-repliker eller resurser som allokerats till befintliga pods.
- Om det inte finns tillräckligt med noder för den planerade skalningen, märker CA närvaron av pods i ett väntande tillstånd.
- CA tilldelar nya noder.
- Moduler distribueras till nya noder.
Samarbete Kubernetes utskalningssystem
Vanliga misstag i Kubernetes autoskalning
Det finns flera vanliga problem som devops stöter på när man försöker implementera autoskalning.
HPA och VPA beror på mätvärden och vissa historiska data. Om otillräckliga resurser allokeras kommer modulerna att minimeras och kommer inte att kunna generera mätvärden. I det här fallet kommer automatisk skalning aldrig att ske.
Själva skalningsoperationen är tidskänslig. Vi vill att modulerna och klustret ska skalas snabbt – innan användarna märker några problem eller fel. Därför bör den genomsnittliga skalningstiden för baljor och klustret tas med i beräkningen.
Idealiskt scenario - 4 minuter:
- 30 sekunder. Uppdatera målstatistik: 30–60 sekunder.
- 30 sekunder. HPA kontrollerar metriska värden: 30 sekunder.
- Mindre än 2 sekunder. Pods skapas och går in i vänteläge: 1 sekund.
- Mindre än 2 sekunder. CA ser väntande moduler och skickar anrop till provisionsnoder: 1 sekund.
- 3 minuter. Molnleverantören allokerar noder. K8s väntar tills de är klara: upp till 10 minuter (beroende på flera faktorer).
Worst case (mer realistiskt) scenario - 12 minuter:
- 30 sekunder. Uppdatera målstatistik.
- 30 sekunder. HPA kontrollerar de metriska värdena.
- Mindre än 2 sekunder. Poddarna skapas och går in i vänteläge.
- Mindre än 2 sekunder. CA ser de väntande modulerna och ringer för att tillhandahålla noderna.
- 10 minuter. Molnleverantören allokerar noder. K8s väntar tills de är klara. Väntetiden beror på flera faktorer, såsom leverantörsfördröjning, OS-fördröjning och supportverktyg.
Blanda inte ihop molnleverantörers skalningsmekanismer med vår CA. Den senare körs i ett Kubernetes-kluster, medan molnleverantörsmotorn arbetar på noddistributionsbasis. Den vet inte vad som händer med dina poddar eller applikation. Dessa system fungerar parallellt.
Hur man hanterar skalning i Kubernetes
- Kubernetes är ett verktyg för resurshantering och orkestrering. Operationer för att hantera poddar och klusterresurser är en viktig milstolpe för att bemästra Kubernetes.
- Förstå logiken i pods skalbarhet med hänsyn till HPA och VPA.
- CA bör endast användas om du har en god förståelse för behoven hos dina baljor och behållare.
- För att konfigurera ett kluster optimalt måste du förstå hur olika skalningssystem fungerar tillsammans.
- När du uppskattar skalningstid, tänk på värsta och bästa tänkbara scenarier.
Källa: will.com