Azure Kubernetes Service (AKS) skalningsöversikt – HPA, VPA, Autoscaler för kluster och KEDA

När du kör program i Azure Kubernetes Service (AKS) kan du skala poddar, poddresurser, noder eller händelsedrivna arbetsbelastningar för att matcha ändringar i efterfrågan. AKS stöder manuell skalning, horisontell autoskalning av poddar (HPA), vertikal autoskalning av poddar (VPA), automatisk klusterskalning, Kubernetes händelsestyrd automatisk skalning (KEDA), automatisk etablering av noder och skalning i burstläge med Azure Container Instances (ACI).

Välj rätt skalningsmetod

Skalningsmetod Bäst för Nyckelmått Guide
Horizontal Pod Autoscaler (HPA) Tillståndslösa eller partitionsbara arbetsbelastningar med variabel efterfrågan CPU-användning, RPS, ködjup När ska jag använda horisontell skalning av poddar (HPA) i Kubernetes?
Vertikal automatisk skalning av poddar (VPA) Arbetsbelastningar som inte kan parallelliseras; rätt dimensionering av resursbegäranden för poddar Cpu-/minnesresursanvändning Använd Vertical Pod Autoscaler i AKS
Autoskalning av kluster Kapacitet på nodnivå när poddar förblir i statusen Pending Väntande poddar Använd Cluster Autoscaler i AKS
Automatisk avetablering av noder (NAP) Arbetsbelastningar som väntar och behöver rätt dimensionerad VM-kapacitet Resurskrav för väntande poddar Översikt över automatisk provisionering av noder
KEDA Händelsedrivna arbetslaster; nollskalning krävs Kölängd, eftersläpning av händelser Översikt över KEDA-tillägg
Burstskalning i ACI Linux-arbetsbelastningar med toppar i efterfrågan som ryms inom begränsningarna för virtuella noder Tillfällig efterfrågetopp Skapa virtuella noder med Azure Container Instances

När du ska använda varje skalningsmetod

  • Använd HPA när din arbetsbelastning kan köra flera identiska repliker och efterfrågan varierar baserat på PROCESSOR-, minnes- eller begärandefrekvens.
  • Använd VPA när din arbetsbelastning inte kan skalas horisontellt (icke-parallelliserbar) eller om du behöver rätt storlek på resursbegäranden för bättre schemaläggning.
  • Använd Cluster Autoscaler när du har fördefinierade nodpooler och behöver lägga till eller ta bort noder utifrån antalet väntande poddar.
  • Använd NAP när du vill ha automatisk SKU-val och nodetablering utan att konfigurera nodpooler manuellt.
  • Använd KEDA när skalning ska svara på externa händelser (köer, strömmar, meddelanden) eller så behöver du kapacitet för att skala till noll.
  • Använd ACI-burst-skalning när du behöver snabb kapacitetsexpansion för Linux-arbetsbelastningar utan att vänta på VM-etablering (vanligtvis 2–5 minuter).

Snabbrekommendations

För de flesta produktionsarbetsbelastningar börjar du med AKS Automatic, som förkonfigurerar NAP, VPA och KEDA. I AKS Standard aktiverar och konfigurerar du dessa funktioner explicit.

Skala poddar eller noder manuellt

Du kan skala podrepliker och noder manuellt för att testa hur applikationen reagerar på förändringar i tillgängliga resurser eller för att bibehålla en fast kapacitetsnivå. Om du vill skala manuellt definierar du det nödvändiga antalet repliker eller noder. Kubernetes skapar eller tar sedan bort poddar, medan AKS lägger till eller tar bort noder från den tillämpliga nodpoolen.

När du skalar ned noder anropar AKS relevant Azure Compute API för klustrets beräkningstyp. För kluster som bygger på Virtual Machine Scale Sets avgör Virtual Machine Scale Sets-API:et vilka noder som ska ta borts. Mer information finns i vanliga frågor och svar om Virtual Machine Scale Sets.

Kom igång genom att läsa:

Automatisk horisontell skalning av poddar

Använd HPA när din arbetslast kan köra flera identiska repliker och efterfrågan varierar. Den skalas på CPU eller minne, programmått (begäranden per sekund, svarstid) eller externa kö- och kvarvarande mått. När repliker kan överskrida befintlig nodkapacitet använder du den förkonfigurerade NAP-funktionen i AKS Automatic eller konfigurerar autoskalning av kluster eller NAP i AKS Standard.

Använd inte HPA och VPA på samma CPU- eller minnesmått. För att använda båda autoskalarna använder du VPA i rekommendationsläge eller konfigurerar HPA så att den använder separata anpassade mätvärden.

Skärmbild av ett diagram som visar hur Horizontal Pod Autoscaler fungerar med AKS.

Läs mer: När ska jag använda horizontal pod autoscaling (HPA) i Kubernetes?

Se även: Använd Vertical Pod Autoscaler i AKS för att anpassa poddens CPU- och minnesbegäranden efter behov.

Vertikal podd-autoskalare

Vertical Pod Autoscaler analyserar poddens processor- och minnesanvändning och rekommenderar eller tillämpar lämpliga resursbegäranden. Använd VPA för att ändra storlek på arbetsbelastningar som inte kan skalas effektivt genom att lägga till repliker eller för att förbättra schemaläggning och resursanvändning.

Beroende på dess uppdateringsläge kan VPA tillämpa rekommendationer när poddar skapas eller avlägsnas och återskapa poddar med uppdaterade resursbegäranden. Granska tillgänglighetskraven för arbetsbelastningar innan du tillåter att VPA tillämpar ändringar automatiskt.

Kom igång genom att läsa Använd Vertical Pod Autoscaler i AKS.

Kluster-autoskalering

Cluster Autoscaler justerar antalet noder i en nodpool utifrån poddschemaläggningens krav. Den lägger till noder när poddar inte kan schemaläggas på grund av otillräcklig nodkapacitet och tar bort underutnytttagna noder när deras arbetsbelastningar kan köras någon annanstans.

Skärmbild av ett diagram som visar hur autoskalning av kluster fungerar med AKS.

Cluster Autoscaler används ofta med HPA. HPA justerar antalet podrepliker baserat på arbetsbelastningen, medan Cluster Autoscaler justerar nodkapaciteten för att hantera dessa poddar.

Information om hur du kommer igång finns i Använda autoskalning av kluster i AKS.

Utskalningshändelser

Om en nodpool inte har tillräckligt med beräkningsresurser för en podd förblir podden Väntande. När Cluster Autoscaler upptäcker poddar som inte kan schemaläggas på grund av resursbegränsningar i nodpoolen ökar den antalet noder i nodpoolen. Kubernetes placerar de väntande poddarna efter att de nya noderna har provisionerats och är redo.

Etablering av VM-baserade noder kan ta flera minuter. För arbetsbelastningar med plötslig burst-efterfrågan bör du överväga att använda virtuella noder och Azure Container Instances.

Nedskalningshändelser

Cluster Autoscaler övervakar om noder är underutnyttjade och avgör om deras poddar kan köras på andra noder. När en nod inte längre krävs schemaläggs kubernetes om sina poddar och AKS tar bort noden från nodpoolen.

Nedskalningsåtgärder kan störa arbetslaster när poddar flyttas mellan noder. Kör flera poddrepliker och konfigurera lämpliga tillgänglighetskontroller för att minimera störningar.

Kubernetes Händelsestyrd autoskalning

Kubernetes Händelsedriven autoskalning (KEDA) är en komponent med öppen källkod som skalar arbetsbelastningar baserat på händelser. KEDA utökar Kubernetes med anpassade resurser, inklusive ScaledObject, som beskriver hur en arbetsbelastning ska svara på en händelsekälla eller ett mått.

KEDA är användbart för arbetsbelastningar som bearbetar köer, strömmar, meddelanden eller andra kvarvarande händelser. Den kan skala ned stödda arbetsbelastningar till noll när det inte finns några händelser och öka antalet repliker när eftersläpningen växer.

Kombinera inte en KEDA ScaledObject med en separat HPA för samma arbetsbelastning. KEDA skapar och använder internt en HPA, så skalningsmekanismerna skulle konkurrera med varandra.

Information om hur du kommer igång finns i översikten över KEDA-tillägget.

Automatisk tilldelning av noder

Nod autoprovisioning (NAP) använder Karpenter-projektet med öppen källkod för att etablera och hantera noder enligt väntande poddkrav. NAP väljer en lämplig SKU för virtuella datorer och nodkvantitet för att möta efterfrågan på arbetsbelastningar i realtid.

NAP börjar med en tillåten uppsättning vm-SKU:er och väljer kapacitet för väntande arbetsbelastningar. Du kan definiera resursgränser och schemaläggningsinställningar för att styra hur de etablerar noder och distribuerar arbetsbelastningar.

Skalning och skyddsmekanismer för styrplanet

AKS skalar automatiskt kontrollplanskomponenter baserat på klusterstorlek och resursanvändning för API-server. Den här vägledningen gäller för AKS Automatic och AKS Standard. Använd prisnivån Standard eller Premium för produktions- eller skalningsarbetsbelastningar.

Kubernetes har ett flerdimensionellt skalningskuvert där varje resurstyp ställer olika krav på kontrollplanet. Till exempel övervakas hemligheter ofta av flera styrenheter och poddar som gör ett inledande LIST-anrop, vilket skapar större belastning på kontrollplanet än resurser som övervakas mer sällan. Att skala kraftigt i en dimension kan minska kapaciteten i andra. Om du till exempel kör hundratusentals poddar kan du minska den poddmutationshastighet som kontrollplanet stöder. Rekommendationer finns i Metodtips för Kubernetes-klienter för storskaliga AKS-kluster.

Om du vill kontrollera om kontrollplanet har skalats upp kontrollerar du large-cluster-control-plane-scaling-status ConfigMap:

kubectl describe configmap large-cluster-control-plane-scaling-status -n kube-system

Förekomsten av den här ConfigMap bekräftar att AKS skalar upp kontrollplanet.

Skyddsåtgärder för styrplanet

Om automatisk skalning av API-servern inte räcker för att stabilisera den under hög belastning kan AKS driftsätta ett hanterat skydd för API-servern. Den här sista utvägen begränsar klientbegäranden som inte är systembaserade för att förhindra att kontrollplanet slutar svara. Systemkritiska API-serveranrop från komponenter som kubelet fortsätter att fungera.

För att avgöra om det hanterade skyddet för API-servern har tillämpats kontrollerar du om aks-managed-apiserver-guardFlowSchema och PriorityLevelConfiguration finns:

kubectl get flowschemas
kubectl get prioritylevelconfigurations

Skyddet är aktivt när aks-managed-apiserver-guard visas i utdata från båda kommandona.

Om dessa resurser finns kan du läsa felsökningsguiden för API-servern och etcd för att få vägledning om hur du åtgärdar.

Burst till Azure Container Instances (ACI)

Du kan integrera AKS med Azure Container Instances för att hantera snabba ökningar av efterfrågan. Automatisk skalning av poddar kan skapa fler repliker än vad den befintliga nodpoolen kan stödja, medan etablering av ytterligare VM-baserade noder kan ta flera minuter. ACI tillhandahåller beräkningskapacitet utan att kräva ytterligare VM-noder.

Virtuella noder (ACI-stödda virtuella Kubernetes-noder) stöder Linux-poddar och noder och kräver ett AKS-kluster som använder Azure CNI-nätverk. De stöder inte några vanliga scenarier, inklusive API-serverauktoriserade IP-intervall, beständiga volymer och beständiga volymanspråk, IPv6 och hanterade identiteter som är kopplade till virtuella noder. Granska begränsningarna för virtuella noder innan du använder ACI-burstskalning.

Skärmbild av ett diagram som visar hur Azure Container Instances fungerar med AKS.

Komponenten för virtuella AKS-noder baseras på Virtual Kubelet och presenterar ACI som en virtuell Kubernetes-nod. Kubernetes kan schemalägga berättigade poddar via den virtuella noden så att de körs som ACI-containerinstanser i stället för direkt på AKS VM-noder.

Virtuella noder använder ett annat undernät i samma virtuella nätverk som AKS-klustret. Den här konfigurationen ger en privat nätverksanslutning mellan AKS och ACI, samtidigt som ACI kan fungera som ett logiskt tillägg för klustret.

Relaterat innehåll

Använd följande resurser för att implementera skalningsmetoden som passar din arbetsbelastning:

Mer information om grundläggande Kubernetes- och AKS-begrepp finns i:

  • Last updated on