Uppgraderingsalternativ och rekommendationer för AKS-kluster (Azure Kubernetes Service)

Gäller för: ✔️ AKS Automatic ✔️ AKS Standard

För de flesta produktionsarbetsbelastningar är AKS Automatic den rekommenderade standardklusterupplevelsen. Den tillhandahåller produktionsklara standardvärden för livscykelåtgärder för kluster och noder, inklusive hanterat uppgraderingsbeteende, inbyggda skyddsåtgärder och minskade driftkostnader.

AKS Standard är fortfarande tillgängligt för scenarier där du behöver djupare manuell kontroll över uppgraderingsmekanik, nätverksval eller beteende för nodpooler.

Den här artikeln ger dig en teknisk grund för AKS-uppgraderingar genom att ta upp uppgraderingsalternativ, vanliga scenarier och rekommendationer för både AKS Automatic och AKS Standard.

Vad den här artikeln beskriver

Den här tekniska referensen omfattar:

• Varför AKS Automatic är den rekommenderade produktionsklara standardinställningen för de flesta arbetsbelastningar.
• Hur uppgraderingsbeteendet skiljer sig mellan AKS Automatic och AKS Standard.
• Manuella och automatiserade uppgraderingsvägar och när var och en ska användas.
• Vanliga uppgraderingsscenarier med specifika rekommendationer.
• Optimeringstekniker för prestanda och minimala störningar.
• Valideringsprocesser och föruppgraderingskontroller.

För relaterad vägledning:

• Översikt och standardvärden för AKS finns i Introduktion till Azure Kubernetes Service (AKS) Automatisk.
• Information om produktionsorienterad AKS-uppgraderingsstrategi finns i AKS-strategier för produktionsuppgradering.
• Information om tillståndskänsliga uppgraderingsmönster för arbetsbelastningar finns i Uppgraderingsmönster för tillståndskänsliga arbetsbelastningar.
• För scenarioledd vägledning, se AKS-uppgraderingsscenarier: Välj din sökväg.
• Om du inte har använt AKS-uppgraderingar tidigare börjar du med hubben för uppgraderingsscenarier för guidad hjälp.

Snabbnavigering

Uppgradera driftsmodeller

AKS Automatisk (rekommenderat standardval för produktion)

AKS Automatic är utformat för produktionsklar drift som standard. För uppgraderingar tillhandahåller AKS Automatic:

• Hanterade systemnodpooler.
• Automatiskt klusteruppgraderingsbeteende med plattformshanterade standardvärden.
• Automatisk uppgradering av nod-OS-avbildning med säkerhetsfokuserad takt.
• Inbyggda kontroller för inaktuella Kubernetes-API:er.
• Schemastöd för planerat underhåll.

Använd AKS Automatic när du vill minimera orkestreringen av manuell uppgradering och hålla produktionskluster anpassade till versioner som stöds med mindre ansträngning.

AKS Standard (avancerad kontrollmodell)

AKS Standard ger dig direkt kontroll över uppgraderingssekvensering och justering. Du väljer och hanterar:

• Manuell eller automatisk uppgraderingskonfiguration.
• Uppgradera kanalval.
• Nodpool och överspänningsbeteende.
• Driftprocedurer kring underhållsperioder och budgetar för arbetsbelastningsstörningar.

Använd AKS Standard när din miljö kräver anpassning som går utöver AKS Automatiska standardvärden.

Uppgraderingsalternativ

Utföra manuella uppgraderingar

Gäller främst för AKS Standard eller för specialiserade operativa arbetsflöden.

Med manuella uppgraderingar kan du styra när klustret uppgraderas till en ny Kubernetes-version. De här uppgraderingarna är användbara för testning, stegvisa distributioner och riktad versionsimplementering.

• Uppgradera ett AKS-kluster
• Uppgradera flera AKS-kluster via Azure Kubernetes Fleet Manager
• Uppgradera nodbilden
• Anpassa uppgradering av nodöverspänning
• Uppdateringar av operativsystemet för processnoder

Konfigurera automatiska uppgraderingar

För AKS Standard hjälper automatiska uppgraderingar till att behålla kluster på versioner som stöds samtidigt som kontroll över principer och schemaläggning bevaras. I AKS Automatic är uppgraderingsautomatisering och skyddsräcken redan en del av standarddriftsmodellen.

• Uppgradera ett AKS-kluster automatiskt
• Uppgradera automatiskt flera AKS-kluster via Azure Kubernetes Fleet Manager
• Använda planerat underhåll för att schemalägga och kontrollera uppgraderingar
• Stoppa automatiskt AKS-klusteruppgradering på API-förändringar som bryter kompatibilitet (förhandsversion)
• Uppgradera aks-klusternodens operativsystemavbildningar automatiskt
• Tillämpa säkerhetsuppdateringar på AKS-noder automatiskt med hjälp av GitHub-åtgärder

Särskilda överväganden för nodpooler som omfattar flera tillgänglighetszoner

AKS använder zonbalansering i möjligaste mån i nodpooler. Under en efterfrågetopp under uppgraderingar är zonerna för belastningsnoder i virtuella maskiners skalningsuppsättningar okända på förhand, vilket tillfälligt kan orsaka en obalanserad zonindelning. AKS tar bort överspänningsnoder efter uppgraderingen och återställer det ursprungliga zonsaldot.

För att hålla zonerna balanserade anger du överspänning till en multipel av tre noder. Beständiga volymanspråk som använder lokalt redundanta Azure-lagringsdiskar är zonbundna och kan orsaka stilleståndstid om överspänningsnoder finns i en annan zon. Använd en budget för poddavbrott (PDB) för att upprätthålla hög tillgänglighet under dräneringar.

Optimera uppgraderingar för att förbättra prestanda och minimera störningar

Kombinera planerat underhållsfönster, maximal surgekapacitet, PDB, tidsgräns för noddränering och stabiliseringstid för nod för att öka sannolikheten för lyckade uppgraderingar med minimala störningar.

AKS Automatisk

I AKS Automatic är uppgraderingsbeteendet på plattformsnivå förkonfigurerat. Fokusera din justering på arbetsbelastningsresiliens och kapacitetsberedskap:

• Verifiera budgetar för poddstörningar och antal repliker.
• Säkerställ kvot- och undernätskapacitet för förväntad tillväxt.
• Ange planerade underhållsscheman som är anpassade till perioder med låg trafik.
• Övervaka uppgraderingshändelser och kritisk arbetsbelastningsberedskap.

AKS Standard

Justera uppgraderingskontrollerna direkt i AKS Standard:

• Planerat underhållsperiod: Schemalägg automatisk uppgradering under perioder med låg trafik. Använd minst fyra timmar.
• Maximal ökning: Högre värden påskyndar uppgraderingar men kan störa arbetsbelastningar. Använd 33% för produktion.
• Maximalt otillgängligt: Använd när kapaciteten är begränsad.
• Poddstörningsbudget: Ange för att begränsa antalet nerlagda poddar under uppgraderingar. Verifiera din tjänst.
• Tidsgräns för noddränering: Konfigurera väntetid för podavstängning. Standardvärdet är 30 minuter.
• Noddränkningstid: Staggera uppgraderingar för att minimera driftstopp. Standardvärdet är 0 minuter.

Valideringar som används i uppgraderingsprocessen

AKS utför valideringar före uppgraderingen för att säkerställa klusterhälsa:

• API-förändringar som bryter bakåtkompatibilitet: Identifierar föråldrade API:er.
• Kubernetes-uppgraderingsversion: Garanterar en giltig uppgraderingssökväg.
• PDB-konfiguration: Kontrollerar felkonfigurerade PDB:er (till exempel maxUnavailable=0).
• Kvot: Bekräftar tillräckligt med kvot för överspänningsnoder.
• Undernät: Verifierar tillräckligt med IP-adresser.
• Certifikat/tjänstens huvudnamn: Identifierar utgångna autentiseringsuppgifter.
• Kontroll av hanterat resurslås: Söker efter resurslås som tillämpas på resursgruppen för det hanterade klustret.

Dessa kontroller gäller i hela AKS. I AKS Automatic är de integrerade i den hanterade uppgraderingsvägen. I AKS Standard ingår de i ditt operativa arbetsflöde.

Vanliga uppgraderingsscenarier och rekommendationer

Scenario 1: Kapacitetsbegränsningar

Om klustret begränsas av produktnivå eller regional kapacitet kan uppgraderingar misslyckas när överbelastningsnoder inte kan etableras. Den här situationen är vanlig med specialiserade produktnivåer (till exempel GPU-noder) eller i regioner med begränsade resurser. Fel som SKUNotAvailable, AllocationFailed, eller OverconstrainedAllocationRequest kan inträffa om maxSurge ställs in för högt för tillgänglig kapacitet.

AKS automatisk styrning

• Håll fönster för planerat underhåll på plats.
• Verifiera prenumerationskvoten och undernätets utrymme före förväntade uppgraderingsperioder.
• Håll arbetsbelastningens skalnings- och avbrottsbudgetar anpassade till underhållsperioder.

AKS Standard-vägledning

• Använd maxUnavailable för att uppgradera med hjälp av befintliga noder i stället för att skapa nya. Mer information finns i Anpassa otillgängliga noder under uppgraderingen.
• Lägre maxSurge för att minska behovet av extra kapacitet. För mer information, se Anpassa uppgradering av nodökning.
• För säkerhetsuppdateringar använder du säkerhetskorrigeringsåterskapningar som inte kräver överspänningsnoder. Mer information finns i Tillämpa säkerhets- och kerneluppdateringar på Linux-noder i Azure Kubernetes Service.

Scenario 2: Nodavloppsfel och PDB:er

Uppgraderingar kräver tömning av noder (avlägsna poddar). Dränering kan misslyckas när poddar avslutas långsamt eller när strikta poddavbrottsbudgetar (PDB) blockerar poddavhysningar.

Exempelfel:

Code: UpgradeFailed
Message: Drain node ... failed when evicting pod ... Cannot evict pod as it would violate the pod's disruption budget.

AKS automatisk styrning

• Behandla PDB- och replikstrategin som de primära tillförlitlighetskontrollerna.
• Validera avbrottsbudgetar i stagingmiljön före produktionsutrullning.
• Behåll kritiska arbetsbelastningar konfigurerade för löpande borttagning.

AKS Standard-vägledning

Alternativ 1: Framtvinga uppgradering, kringgå PDB-begränsningar

Använd endast framtvingad uppgradering när PDF-filer förhindrar kritiska uppgraderingar och inte kan lösas. Den här åtgärden åsidosätter PDB-skydd och kan potentiellt orsaka fullständig tjänst otillgänglighet under uppgraderingen.

Krav: Azure CLI 2.79.0+ eller AKS API version 2025-09-01+

az aks upgrade \
  --name $CLUSTER_NAME \
  --resource-group $RESOURCE_GROUP_NAME \
  --kubernetes-version $KUBERNETES_VERSION \
  --enable-force-upgrade \
  --upgrade-override-until yyyy-mm-ddT13:00:00Z

Alternativ 2: Hantera noder som inte kan tömmas med respekt för PDB:er

Använd den här konservativa metoden för att respektera PDF-filer samtidigt som du förhindrar uppgraderingsfel.

Konfigurera beteendet för noder som inte kan tömmas:

az aks nodepool update \
  --resource-group <resource-group-name> \
  --cluster-name <cluster-name> \
  --name <node-pool-name> \
  --undrainable-node-behavior Cordon \
  --max-blocked-nodes 2 \
  --drain-timeout 30

Beteendealternativ:

• Schemaläggning (standard): Tar bort den blockerade noden och skapar en extra ersättningsnod.
• Cordon (rekommenderas): Avspärrar noden och etiketterar den som kubernetes.azure.com/upgrade-status=Quarantined.

Maximalt antal blockerade noder (förhandsversion):

• Anger hur många noder som misslyckas med att tömma som tolereras
• Kräver undrainable-node-behavior att anges
• Standardvärdet är inställt på maxSurge (vanligtvis 10%) om det inte anges
• Om det beräknade värdet är högre än det antal noder som återstår att uppgradera i den aktuella åtgärden används i stället antalet noder som återstår att uppgradera, precis som maximal ökning.

Krav för maximalt blockerade noder

Azure CLI-tillägget aks-preview version 18.0.0b9 eller senare krävs för att använda funktionen maxblockerade noder.

# Install or update the aks-preview extension
az extension add --name aks-preview
az extension update --name aks-preview

Exempelkonfiguration med maximalt antal blockerade noder

az aks nodepool update \
  --cluster-name jizenMC1 \
  --name nodepool1 \
  --resource-group jizenTestMaxBlockedNodesRG \
  --max-surge 1 \
  --undrainable-node-behavior Cordon \
  --max-blocked-nodes 2 \
  --drain-timeout 5

Alternativ 3: Automatisk PDB-hantering (förhandsversion)

Använd det automatiska PDB-hanteringstillägget för att proaktivt lösa PDB-blockerade avlopp utan att kringgå PDB-skydd eller kräva manuell rensning av noder i karantän. Automatisk PDB-hantering identifierar när en PDB blockerar borttagning på en avspärrad nod och tillfälligt skalar upp distributionens repliker så att avbrottsbudgeten uppfylls. När dräneringen är klar skalas antalet repliker tillbaka till det ursprungliga antalet.

Automatisk PDB-hantering kan också skapa PDB:er automatiskt för driftsättningar som saknar en sådan, så att dina arbetslaster skyddas vid dränering under uppgraderingar. Information om installation och konfiguration finns i Hantera poddstörningsbudgetar automatiskt under AKS-uppgraderingar.

Rekommendationer för att förhindra dräneringsfel

• Ange maxUnavailable i PDB-regler för att tillåta minst en pod-evakuering
• Öka poddrepliker för att uppfylla störningsbudgetens krav
• Utöka tidsgränsen för avrinning om arbetsbelastningar behöver mer tid. (Standardvärdet är 30 minuter.)
• Använd automatisk PDB-hantering för att automatisera PDB-skapande och replikskalning under tömningsåtgärder.
• Testa PDB:er i stagingmiljön, övervaka uppgraderingshändelser och använd blågröna distributioner för kritiska arbetslaster. Mer information finns i Blågrön distribution av AKS-kluster.

Verifiera oanvändbara noder

• De blockerade noderna är inte schemalagda för poddar och markerade med etiketten "kubernetes.azure.com/upgrade-status: Quarantined".

• Kontrollera etiketten på alla blockerade noder när det uppstår ett fel på dräneringsnoden vid uppgraderingen:

  kubectl get nodes --show-labels=true
  

Lösa oanvändbara noder

1. Ta bort det ansvariga PDB:et:

   kubectl delete pdb <pdb-name>
   

2. kubernetes.azure.com/upgrade-status: Quarantined Ta bort etiketten:

   kubectl label nodes <node-name> kubernetes.azure.com/upgrade-status-
   

3. Du kan också ta bort den blockerade noden:

   az aks nodepool delete-machines --cluster-name <cluster-name> --machine-names <machine-name> --name <node-pool-name> --resource-group <resource-group-name>
   

4. När du har slutfört det här steget kan du stämma av klusterstatusen genom att utföra en uppdateringsåtgärd utan de valfria fälten enligt beskrivningen i az aks. Du kan också skala nodpoolen till samma antal noder som antalet uppgraderade noder. Den här åtgärden säkerställer att nodpoolen når sin avsedda ursprungliga storlek. AKS prioriterar borttagningen av blockerade noder. Det här kommandot återställer även klusteretableringsstatusen till Succeeded. I följande exempel 2 är det totala antalet uppgraderade noder.

   # Update the cluster to restore the provisioning status
   az aks update --resource-group <resource-group-name> --name <cluster-name>
   
   # Scale the node pool to restore the original size
   az aks nodepool scale --resource-group <resource-group-name> --cluster-name <cluster-name> --name <node-pool-name> --node-count 2
   

Scenario 3: Långsamma uppgraderingar

Konservativa inställningar eller problem på nodnivå kan fördröja uppgraderingar, vilket påverkar din förmåga att hålla dig uppdaterad med korrigeringar och förbättringar.

Vanliga orsaker till långsamma uppgraderingar är:

• Låg maxSurge eller maxUnavailable värden (begränsar parallellitet).
• Långa väntetider (långa pauser mellan noduppgraderingar).
• Dräneringsfel (se Nodavloppsfel).

AKS automatisk styrning

• Håll underhållsscheman aktuella.
• Övervaka tillståndet för uppgraderingshändelser och arbetsbelastningens beredskap.
• Lös blockering av PDB- eller kapacitetsproblem snabbt för att undvika långvarig fördröjning.

AKS Standard-vägledning

• Använd maxSurge=33%, maxUnavailable=1 för produktion.
• Använd maxSurge=50%, maxUnavailable=2 för dev/test.
• Använd OS-säkerhetsuppdatering för snabb, riktad korrigering (undviker fullständig nodomavbildning).
• Aktivera --undrainable-node-behavior för att undvika uppgraderingsblockerare.

Scenario 4: IP-överbelastning

Överspänningsnoder kräver fler IP-adresser. Om undernätet är nära kapacitet kan nodetablering misslyckas (till exempel Error: SubnetIsFull). Det här scenariot är vanligt med Azure Container Networking Interface, högt maxPodseller stort antal noder.

AKS automatisk styrning

• Verifiera undernät och kapacitetsplaner före produktionsexpansion.
• Övervaka nätverksanvändningen som en del av rutinåtgärder.

AKS Standard-vägledning

• Se till att ditt undernät har tillräckligt med IP-adresser för alla noder, överspänningsnoder och poddar. Formeln är Total IPs = (Number of nodes + maxSurge) * (1 + maxPods).

• Frigör oanvända IP-adresser eller expandera undernätet (till exempel från /24 till /22).

• Lägre maxSurge om det inte går att utöka undernätet.

  az aks nodepool update \
    --resource-group <resource-group-name> \
    --cluster-name <cluster-name> \
    --name <node-pool-name> \
    --max-surge 10%
  

• Övervaka IP-användning med Azure Monitor eller anpassade aviseringar.

• Minska maxPods per nod, rensa överblivna ip-adresser för lastbalanserare och planera undernätsstorlek för storskaliga kluster.

Vanliga frågor

Ska jag använda AKS Automatic eller AKS Standard för produktionsuppgraderingar?

Använd AKS Automatic för de flesta produktionsarbetsbelastningar. Den är utformad som produktionsklar standard med hanterat uppgraderingsbeteende och inbyggda skyddsräcken.

Använd AKS Standard när du behöver avancerad manuell kontroll över uppgraderingssekvensering, infrastrukturval eller åtgärder för nodpooler.

Kan jag använda verktyg med öppen källkod för validering?

Ja. Många verktyg med öppen källkod integreras väl med AKS-uppgraderingsprocesser:

• Trivy: Säkerhetsgenomsökning efter containeravbildningar och Kubernetes-konfigurationer.
• Sonobuoy: Kubernetes-efterlevnadstestning och klustervalidering.
• kube-bench: Säkerhetstestkontroller mot Center for Internet Security-standarder.
• Polaris: Validering av Metodtips för Kubernetes.
• kubectl-neat: Rensa Kubernetes-manifest för validering.

Hur validerar jag API-kompatibilitet innan jag uppgraderar?

Kör utfasningskontroller med hjälp av verktyg som kubent:

# Install and run API deprecation scanner
kubectl apply -f https://github.com/doitintl/kube-no-trouble/releases/latest/download/knt-full.yaml

# Check for deprecated APIs in your cluster
kubectl run knt --image=doitintl/knt:latest --rm -it --restart=Never -- \
  -c /kubeconfig -o json > api-deprecation-report.json

# Review findings
cat api-deprecation-report.json | jq '.[] | select(.deprecated==true)'

Vad skiljer AKS-uppgraderingar från andra Kubernetes-plattformar?

AKS ger flera unika fördelar:

• Hanterade driftvägar i AKS Automatisk för lägre uppgraderingskostnader.
• Intern Azure-integrering med Azure Traffic Manager, Azure Load Balancer och nätverk.
• Azure Kubernetes Fleet Manager för samordnade uppgraderingar av flera kluster.
• Automatisk nodbildskorrigering utan manuell nodhantering.
• Inbyggd validering för kvot, nätverk och autentiseringsuppgifter.
• Azure-stöd för uppgraderingsrelaterade problem.

Välj uppgraderingssökväg

Den här artikeln gav dig en teknisk grund. Välj nu din scenariobaserade sökväg.

Är du redo att köra?

Beslutar du fortfarande?

Använd hubben för uppgraderingsscenarier för ett guidat beslutsträd som tar hänsyn till dina:

• Avbrottstolerans
• Miljökomplexitet
• Riskprofil
• Tidslinjebegränsningar

Slutliga rekommendationer

• Använd AKS Automatic för de flesta produktionsarbetsbelastningar.
• Läs AKS-korrigerings- och uppgraderingsvägledningen för bästa praxis och planeringstips innan du påbörjar en uppgradering.
• Sök alltid efter API-ändringar som bryter kompatibilitet och validera din arbetsbelastnings kompatibilitet med målversionen av Kubernetes.
• Testa uppgraderingsinställningar (till exempel maxSurge, maxUnavailableoch PDB) i en mellanlagringsmiljö för att minimera produktionsrisken.
• Övervaka uppgraderingshändelser och klusterhälsa under hela processen.