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

Artikel
2025-04-01

Den här artikeln beskriver de olika uppgraderingsalternativen för AKS-kluster. Information om hur du utför en grundläggande Kubernetes-versionsuppgradering finns i Uppgradera ett AKS-kluster.

Information om AKS-kluster som använder flera nodpooler eller Windows Server-noder finns i Uppgradera en nodpool i AKS. Information om hur du uppgraderar en specifik nodpool utan att utföra en Kubernetes-klusteruppgradering finns i Uppgradera en specifik nodpool.

Utföra manuella uppgraderingar

Du kan utföra manuella uppgraderingar för att styra när klustret uppgraderas till en ny Kubernetes-version. Manuella uppgraderingar är användbara när du vill testa en ny Kubernetes-version innan du uppgraderar ditt produktionskluster. Du kan också använda manuella uppgraderingar för att uppgradera klustret till en specifik Kubernetes-version som inte är den senaste tillgängliga versionen.

Information om hur du utför manuella uppgraderingar finns i följande artiklar:

Konfigurera automatiska uppgraderingar

Du kan konfigurera automatiska uppgraderingar för att automatiskt uppgradera klustret till den senaste tillgängliga Kubernetes-versionen. Automatiska uppgraderingar är användbara när du vill se till att klustret alltid kör den senaste Kubernetes-versionen. Du kan också använda automatiska uppgraderingar för att säkerställa att klustret alltid kör en Kubernetes-version som stöds.

Information om hur du konfigurerar automatiska uppgraderingar finns i följande artiklar:

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

AKS använder zonutjämning med bästa prestanda i nodgrupper. Vid en uppgradering är zonerna för belastningsnoder i skalningsuppsättningar för virtuella maskiner okända i förväg, vilket tillfälligt kan orsaka en obalanserad zonkonfiguration. AKS tar dock bort överspänningsnoder när uppgraderingen är klar och bevarar den ursprungliga zonbalansen. Om du vill hålla dina zoner balanserade under uppgraderingar kan du öka antalet till en multipel av tre noder, och Virtual Machine-skalningsuppsättningar balanserar noderna mellan tillgänglighetszoner med zonbalansering efter bästa förmåga. Med bästa möjliga zonbalans försöker skalningsgruppen skala upp och ner samtidigt som balansen bibehålls. Men om detta av någon anledning inte är möjligt (till exempel om en zon går ned kan skalningsuppsättningen inte skapa en ny virtuell dator i den zonen), gör skalningsuppsättningen att tillfällig obalans kan skalas in eller ut.

Beständiga volymanspråk (PVCs) som backas upp av Azures lokalt redundanta lagringsdiskar (LRS) är bundna till en viss zon och kan misslyckas med att återställas omedelbart om överspänningsnoden inte matchar PVC-zonen. Om zonerna inte matchar kan det orsaka stilleståndstid för ditt program när uppgraderingsåtgärden fortsätter att tömma noder men PV:erna är bundna till en zon. För att hantera det här fallet och upprätthålla hög tillgänglighet konfigurerar du en Pod Disruption Budget för din applikation så att Kubernetes kan respektera dina tillgänglighetskrav under tömningsoperationen.

Optimera för icke-dränerbart nodbeteende (förhandsversion)

Du kan konfigurera uppgraderingsprocessens beteende för dräneringsfel. Standarduppgraderingsbeteendet är Schedule, som består av ett nodavloppsfel som gör att uppgraderingsåtgärden misslyckas, vilket lämnar de oanvända noderna i ett schemaläggningsbart tillstånd. Du kan också välja beteendet Cordon , som hoppar över noder som inte kan tömmas genom att placera dem i karantäntillstånd, etikettera dem kubernetes.azure.com/upgrade-status:Quarantinedoch fortsätta med att uppgradera de återstående noderna. Det här beteendet säkerställer att alla noder antingen uppgraderas eller sätts i karantän. Med den här metoden kan du felsöka dräneringsfel och hantera noderna i karantän på ett korrekt sätt.

Ange nytt avspärrningsbeteende

Du måste använda aks-preview tillägget 9.0.0b3 eller senare för att ange det nya avspärrningsbeteendet.

Installera eller uppdatera aks-preview tillägget med kommandot [az extension add][az-extension-add] eller [az extension update][az-extension-update] :

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

# Update the aks-preview extension to the latest version
az extension update --name aks-preview

Uppdatera beteendet för nodpoolens oundvikliga noder med kommandot [Cordon][az-aks-nodepool-update] till az aks nodepool update.

az aks nodepool update --cluster-name $CLUSTER_NAME --name $NODE_POOL_NAME --resource-group $RESOURCE_GROUP --max-surge 1 --undrainable-node-behavior Cordon

I följande exempelutdata visas det uppdaterade beteendet hos den odränerbara noden:

"upgradeSettings": {
    "drainTimeoutInMinutes": null,
    "maxSurge": "1",
    "nodeSoakDurationInMinutes": null,
    "undrainableNodeBehavior": "Cordon"
  }

Kontrollera etiketten på alla blockerade noder när det uppstår ett fel på dräneringsnoden vid uppgradering med kommandot kubectl get.
```
kubectl get nodes --show-labels=true
```
De blockerade noderna är inte schemalagda för poddar och markerade med etiketten "kubernetes.azure.com/upgrade-status: Quarantined". Det maximala antalet noder som kan lämnas blockerade får inte vara mer än Max-Surge värdet.

Lösa oanvändbara noder

Lös först det underliggande problemet som orsakar avloppet. Följande exempel tar bort den ansvariga PDB-filen:
```
kubectl delete pdb nginx-pdb
poddisruptionbudget.policy "nginx-pdb" deleted.
```
Om du är säker på att problemet nu har lösts kan du ta bort "kubernetes.azure.com/upgrade-status: Quarantined" etiketten som placeras på oanvändbara noder med kommandot kubectl label .
```
kubectl label nodes <node-name> <label-key>-
```
Alla efterföljande PUT operationer kommer att försöka stämma av Failed Provisioning Status på klustret till Success först. De noder som är i karantän kommer inte att beaktas för några efterföljande insättningar eller avstämningar. Du måste uttryckligen ta bort etiketterna som nämnts tidigare för att eventuella blockerade noder ska beaktas.
Du kan också ta bort den blockerade noden med kommandot [az aks nodepool delete-machines][az-aks-nodepool-delete-machines]. Det här kommandot är användbart om du vill minska fotavtrycket för nodpoolen genom att ta bort noder som lämnats kvar i äldre versioner.
```
az aks nodepool delete-machines --cluster-name $CLUSTER_NAME --machine-names aks-$NODE_POOL_NAME-test123-vmss000000 --name $NODE_POOL_NAME --resource-group $RESOURCE_GROUP
```
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 här. 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 ursprungliga storlek. AKS prioriterar borttagningen av blockerade noder. Det här kommandot återställer även klusteretableringsstatusen till Succeeded. I det angivna 2 exemplet är det totala antalet uppgraderade noder.
```
# Update the cluster to restore the provisioning status
az aks update --resource-group $RESOURCE_GROUP --name $CLUSTER_NAME

# Scale the node pool to restore the original size
az aks nodepool scale --resource-group $RESOURCE_GROUP --cluster-name $CLUSTER_NAME --name $NODE_POOL_NAME --node-count 2 
```

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

Kombinationen av Planerat underhållsfönster, Maximal ökning, Poddavbrottsbudget, tidsgräns för noddränering och nodabsorberingstid kan avsevärt öka sannolikheten för att noduppgraderingar slutförs framgångsrikt innan underhållsfönstrets slut medan avbrott minimeras.

Planerat underhållsfönster gör det möjligt för serviceteam att schemalägga automatisk uppgradering under ett fördefinierat tidsfönster, vanligtvis en period med låg trafik, för att minimera påverkan på arbetsbelastningen. Vi rekommenderar en fönstervaraktighet på minst fyra timmar.
Max surge på nodpoolen tillåter att du begär extra kvot under uppgraderingsprocessen och begränsar antalet noder som valts för uppgradering samtidigt. En högre maxuppgång resulterar i en snabbare uppgraderingsprocess. Vi rekommenderar inte att du ställer in den på 100 %, eftersom den uppgraderar alla noder samtidigt, vilket kan orsaka avbrott i program som körs. Vi rekommenderar en maximal ökningskvot på 33 % för produktionsnodpooler.
Max otillgänglig (förhandsversion) i nodpoolen tillåter uppgraderingar genom att spärra befintliga noder och tömma utan att lägga till några överspänningsnoder. En högre maximal gräns för otillgängliga noder resulterar i snabbare uppgraderingar men orsakar också fler störningar i arbetsflödet för nodpoolen. Den här funktionen rekommenderas för kunder som har kapacitetsbegränsningar på grund av brist på extra SKU-kapacitet i regionen eller kvotproblem.
Poddstörningsbudget anges för tjänsteapplikationer och begränsar antalet poddar som kan vara otillgängliga under frivilliga avbrott, till exempel vid AKS-kontrollerade noduppgraderingar. Det kan konfigureras som minAvailable repliker, vilket anger det minsta antalet programpoddar som måste vara aktiva, eller maxUnavailable repliker, vilket anger det maximala antalet programpoddar som kan avslutas, vilket säkerställer hög tillgänglighet för programmet. Se vägledningen för att konfigurera Pod Disruption Budgetar (PDBs). PDB-värden bör verifieras för att fastställa vilka inställningar som fungerar bäst för din specifika tjänst.
Tidsgräns för noddränering i nodpoolen gör det möjligt för dig att konfigurera väntetiden för poddavstängning och mjuk avstängning per nod under en uppgradering. Det här alternativet är användbart när du hanterar långvariga arbetsbelastningar. När tidsgränsen för nodtömning har angetts (i minuter) tar AKS hänsyn till budgetar för poddavbrott. Om den inte anges är standardtimeouten 30 minuter.
Nodavblödningstiden hjälper till att sprida noduppgraderingar på ett kontrollerat sätt och kan minimera programavbrott under en uppgradering. Du kan ange en väntetid, helst så nära 0 minuter som möjligt, för att kontrollera programberedskapen mellan noduppgraderingar. Om det inte anges är standardvärdet 0 minuter. Nodsänkningstiden fungerar tillsammans med de maximala egenskaperna för ökning och nodtömningstid som finns tillgängliga i nodpoolen för att säkerställa rätt resultat gällande uppgraderingshastighet och programtillgänglighet.

Uppgraderingsinställningar	Tillgängliga resurser för ökning	Förväntat beteende
`maxSurge` = `5` `maxUnavailable` = `0`	5 noder tillgängliga för ökad belastning	5 noder kommer att tillsättas för att uppgradera nodpoolen.
`maxSurge` = `5` `maxUnavailable` = `0`	0–4 noder är tillgängliga för aktivering	Uppgraderingsåtgärden misslyckas på grund av att det inte finns tillräckligt med noder för att uppfylla `maxSurge`.
`maxSurge` = `0` `maxUnavailable` = `5`	N/A eftersom inga överspänningsnoder behövs	Åtgärden använder 5 noder från den befintliga nodpoolen utan att lägga till nya noder för att uppgradera nodpoolen.

Valideringar som används i uppgraderingsprocessen idag

När du initierar en uppgraderingsåtgärd via API, Azure CLI eller Azure-portalen utför Azure Kubernetes Service (AKS) en serie valideringar före uppgraderingen innan uppgraderingen påbörjas. Dessa valideringar säkerställer att klustret är i ett felfritt tillstånd och kan uppgraderas.

API-brytande ändringar: Identifierar om det finns föråldrade API:er som används som kan påverka arbetsflöden.
Kubernetes-uppgraderingsversion: Säkerställer att målversionen är giltig (t.ex. inga hopp större än tre delversioner, inga nedgraderingar och kompatibilitet med kontrollplanet).
Kontroll av felaktig PDB-konfiguration: Söker efter felkonfigurerade budgetar för poddavbrott (PDB) som maxUnavailable = 0 vilket inte tillåter att någon nod störs.
Kvot: Bekräftar att det finns tillräckligt med kvot för att hantera ökande nodbehov som krävs under uppgraderingsprocessen.
Undernät: Verifierar om det finns tillräckligt med allocable IP-adresser för uppgraderingen eller om storleksjusteringar för undernätet behövs.
Certifikat/tjänstens huvudnamn: Identifierar utgångna certifikat eller tjänstens huvudnamn som kan påverka uppgraderingsprocessen.

Dessa kontroller hjälper till att minimera uppgraderingsfel och ge användarna tidig insyn i potentiella problem som behöver lösas innan de fortsätter.

Nästa steg

I den här artikeln visas olika uppgraderingsalternativ för AKS-kluster. En detaljerad beskrivning av metodtips för uppgradering och andra överväganden finns i AKS-korrigerings- och uppgraderingsvägledning.

Dela via