Uppgraderingsalternativ för AKS-kluster (Azure Kubernetes Service)
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:
- Uppgradera ett AKS-kluster
- Uppgradera nodbilden
- Anpassa uppgradering av nodtoppar
- Uppdateringar av operativsystemet för processnoder
- Uppgradera flera AKS-kluster via Azure Kubernetes Fleet Manager
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:
- Uppgradera ett AKS-kluster automatiskt
- Använd Planerat underhåll för att schemalägga och kontrollera uppgraderingar för ditt AKS-kluster
- Stoppa AKS-klusteruppgraderingar automatiskt på API-icke-bakåtkompatibla ändringar (förhandsversion)
- Uppgradera aks-klusternodens operativsystemavbildningar automatiskt
- Tillämpa säkerhetsuppdateringar på AKS-noder automatiskt med GitHub Actions
Särskilda överväganden för nodpooler som omfattar flera tillgänglighetszoner
AKS använder zonutjämning med bästa prestanda i nodgrupper. Under en uppgradering är zonerna för överspänningsnoderna i VM-skalningsuppsättningar okända i förväg, vilket tillfälligt kan orsaka en obalanserad zonkonfiguration under en uppgradering. 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 ökningen till flera av tre noder, och Vm-skalningsuppsättningar balanserar noderna mellan tillgänglighetszoner med zonutjämning med bästa förmåga. Med zonbalans med bästa förmåga försöker skalningsuppsättningen skala in och ut 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 budget för poddavbrott i ditt program så att Kubernetes kan respektera dina tillgänglighetskrav under avloppsåtgärden.
Optimera för oanvändbart 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:Quarantined
och 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.
Hur gör jag för att ange det nya Cordon-beteendet?
Använd CLI-förhandsversionen och installationstillägget aks-preview
9.0.0b3 eller senare.
Du kan använda följande kommandon för att uppdatera eller installera aks-preview
tillägget:
az extension update --name aks-preview
az extension add --name aks-preview
Uppdatera nodpoolens oanvändbara nodbeteende till Cordon
:
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 oanvändbara nodbeteendet uppdaterat:
"upgradeSettings": {
"drainTimeoutInMinutes": null,
"maxSurge": "1",
"nodeSoakDurationInMinutes": null,
"undrainableNodeBehavior": "Cordon"
}
Verifiera etiketten på alla blockerade noder. När det uppstår ett fel på dräneringsnoden vid uppgraderingen med hjälp av följande kommando:
kubectl get nodes --show-labels=true
De blockerade noderna är oplanerade 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.
Hur gör jag för att ta bort de blockerade noderna?
Lös först problemet som orsakar avloppet. Följande exempel tar bort det ansvariga PDB:et:
kubectl delete pdb nginx-pdb
poddisruptionbudget.policy "nginx-pdb" deleted.
Ta sedan bort den blockerade noden med kommandot 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 MyCluster --machine-names aks-nodepool1-test123-vmss000000 --name nodepool1 --resource-group TestRG
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.
Exempelkommando:
az aks update --resource-group TestRG --name MyCluster
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.
az aks nodepool scale --resource-group TestRG --cluster-name MyCluster --name nodepool1 --node-count 2
Optimera uppgraderingar för att förbättra prestanda och minimera störningar
Kombinationen av fönstret Planerat underhåll, Maximal ökning, Budget för poddavbrott, tidsgräns för noddränering och nodavblödning kan avsevärt öka sannolikheten för att noduppgraderingar slutförs i slutet av underhållsfönstret samtidigt som avbrott minimeras.
- Med fönstret Planerat underhåll kan tjänstteam schemalägga automatisk uppgradering under ett fördefinierat fö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.
- Poddstörningsbudget anges för tjänstprogram och begränsar antalet poddar som kan vara nere under frivilliga avbrott, till exempel AKS-kontrollerade noduppgraderingar. Det kan konfigureras som
minAvailable
repliker, vilket anger det minsta antalet programpoddar som måste vara aktiva, ellermaxUnavailable
repliker, vilket anger det maximala antalet programpoddar som kan avslutas, vilket säkerställer hög tillgänglighet för programmet. Mer information om hur du konfigurerar poddstörningar (PDB) finns i vägledningen. PDB-värden bör verifieras för att fastställa vilka inställningar som fungerar bäst för din specifika tjänst. - Med tidsgränsen för noddränering i nodpoolen kan du konfigurera väntetiden för borttagning av poddar och respitfull avslutning 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 noddränering har angetts (i minuter) respekterar AKS väntan på poddavbrottsbudgetar. 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. Nodavblödningstiden fungerar tillsammans med de maximala timeout-egenskaperna för överspänning och nodavlopp som är tillgängliga i nodpoolen för att leverera rätt resultat när det gäller uppgraderingshastighet och programtillgänglighet.
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.
Azure Kubernetes Service