Uppgradera ett AKS-kluster (Azure Kubernetes Service)
En del av AKS-klusterlivscykeln omfattar periodiska uppgraderingar till den senaste Kubernetes-versionen. Det är viktigt att du använder de senaste säkerhetsversionerna och uppgraderingarna för att få de senaste funktionerna. Den här artikeln visar hur du söker efter och tillämpar uppgraderingar på ditt AKS-kluster.
När du uppgraderar ett AKS-kluster som stöds kan du inte hoppa över Kubernetes-delversioner. Du måste utföra alla uppgraderingar sekventiellt efter huvudversionsnummer. Till exempel tillåts uppgraderingar mellan 1.14.x ->1.15.x eller 1.15.x ->1.16.x . 1.14.x ->1.16.x tillåts inte. Du kan bara hoppa över flera versioner när du uppgraderar från en version som inte stöds tillbaka till en version som stöds. Du kan till exempel utföra en uppgradering från en 1.10.x som inte stöds till en 1.12.x som stöds om den är tillgänglig.
När du utför en uppgradering från en version som inte stöds och hoppar över två eller flera mindre versioner har uppgraderingen ingen garanti för funktionalitet och undantas från serviceavtalen och den begränsade garantin. Om din version är betydligt inaktuell rekommenderar vi att du återskapar klustret i stället.
- Om du använder Azure CLI kräver den här artikeln Azure CLI version 2.34.1 eller senare. Kör
az --version
för att hitta versionen. Om du behöver installera eller uppgradera kan du läsa Installera Azure CLI. - Om du använder Azure PowerShell kräver den här artikeln Azure PowerShell version 5.9.0 eller senare. Kör
Get-InstalledModule -Name Az
för att hitta versionen. Om du behöver installera eller uppgradera kan du läsa Install Azure PowerShell (Installera Azure PowerShell). - För att utföra uppgraderingsåtgärder krävs
Microsoft.ContainerService/managedClusters/agentPools/write
RBAC-rollen. Mer information om Azure RBAC-roller finns i Åtgärder för Azure-resursprovider. - Från och med 1.30 kubernetes-version och 1.27 LTS-versioner inaktiveras beta-API:erna som standard när du uppgraderar till dem.
Varning
En AKS-klusteruppgradering utlöser en avspärrning och tömning av dina noder. Om du har en låg beräkningskvot kan uppgraderingen misslyckas. Mer information finns i Öka kvoter.
Anteckning
Information om hur du håller dig uppdaterad med AKS-korrigeringar, versioner och uppdateringar finns i AKS-versionsspåraren.
Kontrollera vilka Kubernetes-versioner som är tillgängliga för klustret med hjälp av
az aks get-upgrades
kommandot .az aks get-upgrades --resource-group myResourceGroup --name myAKSCluster --output table
Följande exempelutdata visar den aktuella versionen som 1.26.6 och visar de tillgängliga versionerna under
upgrades
:{ "agentPoolProfiles": null, "controlPlaneProfile": { "kubernetesVersion": "1.26.6", ... "upgrades": [ { "isPreview": null, "kubernetesVersion": "1.27.1" }, { "isPreview": null, "kubernetesVersion": "1.27.3" } ] }, ... }
Följande exempelutdata innebär att appservice-kube
tillägget inte är kompatibelt med din Azure CLI-version (minst version 2.34.1 krävs):
The 'appservice-kube' extension is not compatible with this version of the CLI.
You have CLI core version 2.0.81 and this extension requires a min of 2.34.1.
Table output unavailable. Use the --query option to specify an appropriate query. Use --debug for more info.
Om du får dessa utdata måste du uppdatera din Azure CLI-version. Kommandot az upgrade
lades till i version 2.11.0 och fungerar inte med versioner före 2.11.0. Du kan uppdatera äldre versioner genom att installera om Azure CLI enligt beskrivningen i Installera Azure CLI. Om din Azure CLI-version är 2.11.0 eller senare kör du az upgrade
för att uppgradera Azure CLI till den senaste versionen.
Om ditt Azure CLI uppdateras och du får följande exempelutdata innebär det att inga uppgraderingar är tillgängliga:
ERROR: Table output unavailable. Use the --query option to specify an appropriate query. Use --debug for more info.
Om inga uppgraderingar är tillgängliga skapar du ett nytt kluster med en version av Kubernetes som stöds och migrerar dina arbetsbelastningar från det befintliga klustret till det nya klustret. AKS stöder inte uppgradering av ett kluster till en nyare Kubernetes-version när az aks get-upgrades
det visar att inga uppgraderingar är tillgängliga.
Under klusteruppgraderingsprocessen utför AKS följande åtgärder:
- Lägg till en ny buffertnod (eller så många noder som konfigurerats i maximal ökning) i klustret som kör den angivna Kubernetes-versionen.
- Avspärra och töm en av de gamla noderna för att minimera avbrott i program som körs. Om du använder maximal ökning spärrar och tömmer den så många noder samtidigt som antalet buffertnoder som anges.
- För långvariga poddar kan du konfigurera tidsgränsen för noddränering, vilket möjliggör anpassad väntetid vid borttagning av poddar och graciös avslutning per nod. Om det inte anges är standardvärdet 30 minuter. Minsta tillåtna timeout-värde är 5 minuter. Den maximala gränsen för timeout för avlopp är 24 timmar.
- När den gamla noden är helt tömd återskapas den för att ta emot den nya versionen och blir buffertnoden för följande nod som ska uppgraderas.
- Du kan också ange hur lång tid det tar att vänta mellan att tömma en nod och fortsätta att återskapa den och gå vidare till nästa nod. Med ett kort intervall kan du utföra andra uppgifter, till exempel att kontrollera programmets hälsa från en Grafana-instrumentpanel under uppgraderingsprocessen. Vi rekommenderar en kort tidsram för uppgraderingsprocessen, så nära 0 minuter som möjligt. Annars påverkar en högre nodblödningstid hur lång tid det tar innan du upptäcker ett problem. Det minsta värdet för blötläggningstid är 0 minuter, med högst 30 minuter. Om det inte anges är standardvärdet 0 minuter.
- Den här processen upprepas tills alla noder i klustret har uppgraderats.
- I slutet av processen tas den sista buffertnoden bort, vilket bibehåller det befintliga antalet agentnoder och zonsaldot.
Anteckning
Om ingen korrigering anges uppgraderas klustret automatiskt till den angivna delversionens senaste GA-korrigering. Om du till exempel ställer in --kubernetes-version
på resulterar det i att 1.28
klustret uppgraderas till 1.28.9
.
Mer information finns i Kubernetes-delversionsuppgraderingar som stöds i AKS.
Uppgradera klustret med hjälp av
az aks upgrade
kommandot .az aks upgrade \ --resource-group myResourceGroup \ --name myAKSCluster \ --kubernetes-version <KUBERNETES_VERSION>
Bekräfta att uppgraderingen lyckades med kommandot
az aks show
.az aks show --resource-group myResourceGroup --name myAKSCluster --output table
Följande exempelutdata visar att klustret nu kör 1.27.3:
Name Location ResourceGroup KubernetesVersion ProvisioningState Fqdn ------------ ---------- --------------- ------------------- ------------------- ---------------------------------------------- myAKSCluster eastus myResourceGroup 1.27.3 Succeeded myakscluster-dns-379cbbb9.hcp.eastus.azmk8s.io
Du kan ange en kanal för automatisk uppgradering i klustret. Mer information finns i Automatisk uppgradering av ett AKS-kluster.
Viktigt
Nodtoppar kräver prenumerationskvot för det begärda maximala antalet överspänningar för varje uppgraderingsåtgärd. Till exempel har ett kluster som har fem nodpooler, var och en med antalet fyra noder, totalt 20 noder. Om varje nodpool har ett maximalt överspänningsvärde på 50 %, krävs ytterligare beräknings- och IP-kvot på 10 noder (2 noder * 5 pooler) för att slutföra uppgraderingen.
Inställningen för maximal ökning på en nodpool är beständig. Efterföljande Kubernetes-uppgraderingar eller nodversionsuppgraderingar använder den här inställningen. Du kan när som helst ändra maximalt överspänningsvärde för dina nodpooler. För produktionsnodpooler rekommenderar vi en max-surge-inställning på 33 %.
Om du använder Azure CNI kontrollerar du att det finns tillgängliga IP-adresser i undernätet för att uppfylla IP-kraven för Azure CNI.
AKS konfigurerar uppgraderingar till överspänning med en extra nod som standard. Ett standardvärde på ett för inställningarna för maximal överbelastning gör det möjligt för AKS att minimera arbetsbelastningsstörningar genom att skapa en extra nod före avspärrning/avrinning av befintliga program för att ersätta en äldre versionsnod. Du kan anpassa maximalt överspänningsvärde per nodpool. När du ökar det maximala överspänningsvärdet slutförs uppgraderingsprocessen snabbare och du kan uppleva störningar under uppgraderingsprocessen.
Ett maximalt överspänningsvärde på 100 % ger till exempel den snabbaste möjliga uppgraderingsprocessen, men gör också att alla noder i nodpoolen töms samtidigt. Du kanske vill använda ett högre värde som det här för att testa miljöer. För produktionsnodpooler rekommenderar vi en max_surge
inställning på 33 %.
AKS accepterar både heltalsvärden och ett procentvärde för maximal ökning. Ett heltal som 5 anger att fem extra noder ska öka. Ett värde på 50 % anger ett överspänningsvärde på hälften av det aktuella nodantalet i poolen. Högsta ökningsprocentvärden kan vara minst 1 % och högst 100 %. Ett procentvärde avrundas upp till närmaste nodantal. Om det maximala överspänningsvärdet är högre än det antal noder som krävs för att uppgraderas används antalet noder som ska uppgraderas för det maximala överspänningsvärdet. Under en uppgradering kan det maximala överspänningsvärdet vara minst 1 och ett maximalt värde som är lika med antalet noder i nodpoolen. Du kan ange större värden, men du kan inte ange det maximala antalet noder som används för maximal ökning som är högre än antalet noder i poolen vid tidpunkten för uppgraderingen.
Ange maximala överspänningsvärden för nya eller befintliga nodpooler med hjälp av
az aks nodepool add
kommandot elleraz aks nodepool update
.# Set max surge for a new node pool az aks nodepool add --name mynodepool --resource-group MyResourceGroup --cluster-name MyManagedCluster --max-surge 33% # Update max surge for an existing node pool az aks nodepool update --name mynodepool --resource-group MyResourceGroup --cluster-name MyManagedCluster --max-surge 5
Ibland kan du ha en tidskrävande arbetsbelastning på en viss podd och det kan inte schemaläggas om till en annan nod under körningen, till exempel en minnesintensiv tillståndskänslig arbetsbelastning som måste slutföra körningen. I dessa fall kan du konfigurera en tidsgräns för noddränering som AKS kommer att respektera i uppgraderingsarbetsflödet. Om inget timeout-värde för noddränering har angetts är standardvärdet 30 minuter. Minsta tillåtna timeoutvärde för avlopp är 5 minuter och den maximala tidsgränsen för avlopp är 24 timmar.
Om timeout-värdet för avlopp förflutit och poddar fortfarande körs stoppas uppgraderingsåtgärden. Eventuella efterföljande PUT-åtgärder ska återuppta den stoppade uppgraderingen. Vi rekommenderar också att långvariga poddar konfigurerar [terminationGracePeriodSeconds
][https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/].
Ange tidsgränsen för noddränering för nya eller befintliga nodpooler med hjälp av
az aks nodepool add
kommandot elleraz aks nodepool update
.# Set drain timeout for a new node pool az aks nodepool add --name mynodepool --resource-group MyResourceGroup --cluster-name MyManagedCluster --drain-timeout 100 # Update drain timeout for an existing node pool az aks nodepool update --name mynodepool --resource-group MyResourceGroup --cluster-name MyManagedCluster --drain-timeout 45
Om du vill tillåta en tidsperiod att vänta mellan att tömma en nod och fortsätta att återskapa den och gå vidare till nästa nod, kan du ange förbrukningstiden till ett värde mellan 0 och 30 minuter. Om inget nodblödningstidsvärde anges är standardvärdet 0 minuter.
Ange tidsåtgång för noden för nya eller befintliga nodpooler med hjälp av
az aks nodepool add
kommandot ,az aks nodepool update
elleraz aks nodepool upgrade
.# Set node soak time for a new node pool az aks nodepool add --name MyNodePool --resource-group MyResourceGroup --cluster-name MyManagedCluster --node-soak-duration 10 # Update node soak time for an existing node pool az aks nodepool update --name MyNodePool --resource-group MyResourceGroup --cluster-name MyManagedCluster --max-surge 33% --node-soak-duration 5 # Set node soak time when upgrading an existing node pool az aks nodepool upgrade --name MyNodePool --resource-group MyResourceGroup --cluster-name MyManagedCluster --max-surge 33% --node-soak-duration 20
Visa uppgraderingshändelser med kommandot
kubectl get events
.kubectl get events
Följande exempelutdata visar några av ovanstående händelser som anges under en uppgradering:
... default 2m1s Normal Drain node/aks-nodepool1-96663640-vmss000001 Draining node: [aks-nodepool1-96663640-vmss000001] ... default 1m45s Normal Upgrade node/aks-nodepool1-96663640-vmss000001 Soak duration 5m0s after draining node: aks-nodepool1-96663640-vmss000001 ... default 9m22s Normal Surge node/aks-nodepool1-96663640-vmss000002 Created a surge node [aks-nodepool1-96663640-vmss000002 nodepool1] for agentpool nodepool1 ...
Information om hur du konfigurerar automatiska uppgraderingar finns i Konfigurera automatiska uppgraderingar för ett AKS-kluster.
En detaljerad beskrivning av metodtips för uppgradering och andra överväganden finns i AKS-korrigerings- och uppgraderingsvägledning.
Feedback om Azure Kubernetes Service
Azure Kubernetes Service är ett öppen källkod projekt. Välj en länk för att ge feedback: