Durchführen eines Upgrades für einen Azure Kubernetes Service-Cluster (AKS)
Im Rahmen des AKS-Clusterlebenszyklus müssen regelmäßige Upgrades auf die aktuelle Kubernetes-Version ausgeführt werden. Es ist wichtig, jeweils die aktuellen Sicherheitsversionen und Upgrades anzuwenden, um die neuesten Features zu erhalten. In diesem Artikel erfahren Sie, wie Sie auf Upgrades für Ihren AKS-Cluster überprüfen und diese anwenden.
Upgrades von Kubernetes-Versionen
Beim Upgrade eines unterstützten AKS-Clusters können Sie Nebenversionen von Kubernetes nicht überspringen. Sie müssen alle Upgrades nacheinander nach der Hauptversionsnummer ausführen. Upgrades zwischen 1.14.x und >1.15.x oder 1.15.x und >1.16.x sind beispielsweise zulässig. 1.14.x und >1.16.x ist nicht zulässig. Sie können nur dann mehrere Versionen überspringen, wenn Sie ein Upgrade von einer nicht unterstützten Version auf eine unterstützte Version vornehmen. Sie können z. B. ein Upgrade von einer nicht unterstützten 1.10.x auf eine unterstützte 1.12.x durchführen, falls verfügbar.
Wenn Sie ein Upgrade von einer nicht unterstützten Version durchführen, das zwei oder mehr Nebenversionen überspringt, hat das Upgrade keine Garantie hinsichtlich der Funktionalität und ist von den Vereinbarungen zum Servicelevel und der eingeschränkten Garantie ausgeschlossen. Wenn Ihre Version erheblich veraltet ist, empfehlen wir Ihnen, Ihren Cluster stattdessen neu zu erstellen.
Voraussetzungen
- Bei Verwendung der Azure CLI ist für diesen Artikel Azure CLI-Version 2.34.1 oder höher erforderlich. Führen Sie
az --versionaus, um die Version zu ermitteln. Informationen zum Durchführen einer Installation oder eines Upgrades finden Sie bei Bedarf unter Installieren der Azure CLI. - Wenn Sie Azure PowerShell verwenden, erfordert dieser Artikel die Azure PowerShell-Version 5.9.0 oder höher. Führen Sie
Get-InstalledModule -Name Azaus, um die Version zu ermitteln. Falls Sie eine Installation oder ein Upgrade ausführen müssen, finden Sie unter Installieren von Azure PowerShell weitere Informationen. - Das Ausführen von Upgradevorgängen erfordert die RBAC-Rolle
Microsoft.ContainerService/managedClusters/agentPools/write. Weitere Informationen zu Azure RBAC-Rollen finden Sie unter Vorgänge mit dem Azure-Ressourcenanbieter. - Ab Version 1.30 von Kubernetes und 1.27 LTS-Versionen werden die Beta-APIs standardmäßig deaktiviert, wenn Sie ein Upgrade auf sie durchführen.
Warnung
Durch ein AKS-Clusterupgrade werden Ihre Knoten als nicht planbar markiert und entleert (cordon/drain). Wenn Sie nur über ein geringes Computekontingent verfügen, kann das Upgrade möglicherweise nicht durchgeführt werden. Weitere Informationen finden Sie unter Anfordern einer Kontingenterhöhung.
Suchen nach verfügbaren AKS-Clusterupgrades
Hinweis
Wenn Sie über AKS-Fixes, -Versionen und -Updates auf dem neuesten Stand bleiben möchten, ziehen Sie den AKS Release-Tracker zu Rate.
Überprüfen Sie, welche Kubernetes-Releases für Ihren Cluster verfügbar sind, indem Sie den Befehl
az aks get-upgradesverwenden.az aks get-upgrades --resource-group myResourceGroup --name myAKSCluster --output tableDie folgende Beispielausgabe zeigt die aktuelle Version als 1.26.6 an und führt die verfügbaren Versionen unter
upgradesauf:{ "agentPoolProfiles": null, "controlPlaneProfile": { "kubernetesVersion": "1.26.6", ... "upgrades": [ { "isPreview": null, "kubernetesVersion": "1.27.1" }, { "isPreview": null, "kubernetesVersion": "1.27.3" } ] }, ... }
Problembehandlung bei Fehlermeldungen zu AKS-Clusterupgrades
Die folgende Beispielausgabe bedeutet, dass die Erweiterung appservice-kube nicht mit Ihrer Azure CLI-Version kompatibel ist (mindestens Version 2.34.1 ist erforderlich):
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.
Wenn Sie diese Ausgabe erhalten, müssen Sie Ihre Azure CLI-Version aktualisieren. Der Befehl az upgrade wurde in Version 2.11.0 hinzugefügt und funktioniert nicht mit Versionen vor 2.11.0. Sie können ältere Versionen durch eine Neuinstallation der Azure CLI aktualisieren (siehe Installieren der Azure CLI). Wenn Ihre Azure CLI-Version 2.11.0 oder höher ist, führen Sie az upgrade aus, um Azure CLI auf die neueste Version zu aktualisieren.
Wenn Ihre Azure CLI aktualisiert wird und Sie die folgende Beispielausgabe erhalten, bedeutet dies, dass keine Upgrades verfügbar sind:
ERROR: Table output unavailable. Use the --query option to specify an appropriate query. Use --debug for more info.
Wenn kein Upgrade verfügbar ist, erstellen Sie einen neuen Cluster mit einer unterstützten Version von Kubernetes, und migrieren Sie Ihre Workloads vom vorhandenen Cluster zum neuen Cluster. AKS unterstützt das Upgrade eines Clusters auf eine neuere Kubernetes-Version nicht, wenn az aks get-upgrades anzeigt, dass keine Upgrades verfügbar sind.
Aktualisieren eines AKS-Clusters
Während des Clusterupgradeprozesses führt AKS die folgenden Vorgänge aus:
- AKS fügt dem Cluster, auf dem die angegebene Kubernetes-Version ausgeführt wird, einen neuen Pufferknoten (oder die in max surge konfigurierte Anzahl von Knoten) hinzu.
- Führen Sie eine Absperrung und einen Ausgleich eines der alten Knotenpunkte durch, um die Unterbrechung der ausgeführten Anwendungen zu minimieren. Wenn Sie „max surge“ verwenden, werden so viele Knoten gleichzeitig abgesperrt und ausgeglichen, wie die Anzahl der angegebenen Pufferknoten beträgt.
- Für zeitintensive Pods können Sie das Timeout für den Knotenausgleich konfigurieren, wodurch benutzerdefinierte Wartezeiten für die Entfernung von Pods und eine ordnungsgemäße Beendigung pro Knoten möglich sind. Sofern nicht angegeben, wird der Wert standardmäßig auf 30 Minuten festgelegt. Der kleinste zulässige Timeoutwert beträgt 5 Minuten.
- Wenn der alte Knoten vollständig ausgeglichen wurde, wird für diesen ein Reimaging durchgeführt, damit er die neue Version erhält. Er wird dann zum Pufferknoten, damit der folgende Knoten aktualisiert werden kann.
- Optional können Sie eine Zeitspanne festlegen, die zwischen der Entleerung eines Knotens und dem erneuten Aufspielen des Knotens und dem Übergang zum nächsten Knoten vergehen soll. Ein kurzes Intervall ermöglicht es Ihnen, während des Upgrade-Prozesses andere Aufgaben zu erledigen, wie z. B. die Überprüfung des Anwendungsstatus über ein Grafana-Dashboard. Wir empfehlen einen kurzen Zeitrahmen für den Upgrade-Prozess, der so nah wie möglich an 0 Minuten liegt. Andernfalls wirkt sich eine höhere Knotendurchlaufzeit darauf aus, wie lange es dauert, bis Sie ein Problem entdecken. Der Mindestwert für die Durchlaufzeit liegt bei 0 Minuten, der Höchstwert bei 30 Minuten. Wenn Sie hier nichts angeben, lautet der Standardwert 0 Minuten.
- Dieser Prozess wird wiederholt, bis alle Knoten im Cluster aktualisiert sind.
- Am Ende des Vorgangs wird der letzte Pufferknoten gelöscht, sodass die Anzahl der vorhandenen Agent-Knoten und der Zonensaldo beibehalten werden.
Hinweis
Ist kein Patch angegeben, wird der Cluster automatisch auf den neuesten GA-Patch der angegebenen Nebenversion aktualisiert. Wenn Sie beispielsweise --kubernetes-version auf 1.28 festlegen, wird ein Upgrade des Clusters auf 1.28.9 durchgeführt.
Weitere Informationen finden Sie unter Unterstützte Kubernetes-Nebenversionsupgrades in AKS.
Führen Sie ein Upgrade Ihres Clusters mithilfe des Befehls
az aks upgradedurch.az aks upgrade \ --resource-group myResourceGroup \ --name myAKSCluster \ --kubernetes-version <KUBERNETES_VERSION>Überprüfen Sie mit dem Befehl
az aks show, ob das Upgrade erfolgreich war.az aks show --resource-group myResourceGroup --name myAKSCluster --output tableDie Ausgabe im folgenden Beispiel zeigt, dass im Cluster nun Version 1.27.3 ausgeführt wird:
Name Location ResourceGroup KubernetesVersion ProvisioningState Fqdn ------------ ---------- --------------- ------------------- ------------------- ---------------------------------------------- myAKSCluster eastus myResourceGroup 1.27.3 Succeeded myakscluster-dns-379cbbb9.hcp.eastus.azmk8s.io
Festlegen des Kanals für automatische Upgrades
Sie können einen Kanal für automatische Upgrades für Ihren Cluster festlegen. Weitere Informationen finden Sie unter Automatisches Upgraden eines AKS-Clusters.
Anpassen des Upgrades für Knotenanstiege
Wichtig
Knotenanstiege erfordern ein Abonnementkontingent für die angeforderte maximale Anstiegsanzahl für jeden Upgradevorgang. Beispielsweise umfasst ein Cluster mit fünf Knotenpools, von denen jeder vier Knoten enthält, insgesamt 20 Knoten. Wenn für jeden Knotenpool ein maximaler Anstiegswert von 50 % gilt, sind zusätzliche Compute- und IP-Kontingente von 10 Knoten (2 Knoten * 5 Pools) erforderlich, um das Upgrade abzuschließen.
Die Einstellung des maximalen Anstiegs für einen Knotenpools ist persistent. Diese Einstellung wird bei nachfolgenden Kubernetes-Upgrades oder bei Knotenversionsupgrades verwendet. Sie können den maximalen Anstiegswert für Ihre Knotenpools jederzeit ändern. Für Produktionsknotenpools wird ein maximaler Anstiegswert von 33 % empfohlen.
Wenn Sie Azure CNI verwenden, stellen Sie sicher, dass im Subnetz IPs verfügbar sind, um die IP-Anforderungen von Azure CNI zu erfüllen.
AKS konfiguriert Upgrades standardmäßig für einen Anstieg mit einem zusätzlichen Knoten. Ein Standardwert von 1 für die Einstellung des maximalen Anstiegs ermöglicht AKS das Minimieren von Workloadunterbrechungen, indem vor dem Absperren/Ausgleichen vorhandener Anwendungen ein zusätzlicher Knoten erstellt wird, um einen Knoten einer älteren Version zu ersetzen. Sie können den maximalen Anstiegswert pro Knotenpool anpassen. Wenn Sie den Wert für den maximalen Anstieg (max surge) erhöhen, wird der Upgradevorgang schneller abgeschlossen, und es kann zu Unterbrechungen während des Upgradevorgangs führen.
Beispielsweise ermöglicht ein maximaler Anstiegswert von 100 % den schnellstmöglichen Upgradevorgang, führt aber auch dazu, dass alle Knoten im Knotenpool gleichzeitig ausgeglichen werden. Sie könnten für Testumgebungen einen höheren Wert verwenden. Für Produktionsknotenpools wird als Einstellung für max_surge33 % empfohlen.
Für den maximalen Anstieg akzeptiert AKS sowohl ganzzahlige Werte als auch einen prozentualen Wert. Eine ganze Zahl wie 5 gibt für den Anstieg fünf zusätzliche Knoten an. Der Wert 50 % gibt einen Anstiegswert der Hälfte der aktuellen Knotenanzahl im Pool an. Die Prozentwerte für den maximalen Anstieg können mindestens 1 % und maximal 100 % lauten. Ein Prozentwert wird auf die nächste Knotenanzahl aufgerundet. Wenn der „Max Surge“-Wert höher als die erforderliche Anzahl von Knoten ist, die aktualisiert werden soll, wird die Anzahl der Knoten, die aktualisiert werden soll, für den „Max Surge“-Wert verwendet. Während eines Upgrades kann der maximale Anstiegswert mindestens 1 betragen und maximal der Anzahl von Knoten in Ihrem Knotenpool entsprechen. Sie können größere Werte festlegen, aber die maximale Anzahl von Knoten, die für den maximalen Anstieg verwendet wird, kann nicht auf einen Wert größer als die Anzahl der Knoten im Pool zum Zeitpunkt des Upgrades gesetzt werden.
Festlegen des maximalen Anstiegswerts
Legen Sie die maximalen Anstiegswerte für neue oder vorhandene Knotenpools mit dem
az aks nodepool add- oderaz aks nodepool update-Befehl fest.# 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
Festlegen des Timeoutwerts für den Knotenausgleich
Es kann vorkommen, dass Sie auf einem bestimmten Pod eine zeitintensive Arbeitslast haben, die während der Laufzeit nicht auf einen anderen Knoten verlagert werden kann, z. B. eine speicherintensive zustandsabhängige Arbeitslast, die zu Ende laufen muss. In diesen Fällen können Sie ein Timeout für den Knotenausgleich konfigurieren, das von AKS im Upgrade-Workflow berücksichtigt wird. Wenn kein Timeoutwert für den Knotenausgleich angegeben ist, beträgt der Standardwert 30 Minuten. Der kleinste zulässige Timeoutwert für den Ausgleich beträgt 5 Minuten.
Wenn der Timeoutwert entwässert und Pods noch ausgeführt werden, wird der Upgradevorgang beendet. Jeder nachfolgende PUT-Vorgang setzt das angehaltene Upgrade fort. Es wird auch empfohlen, für Pods mit langer Laufzeit die [terminationGracePeriodSeconds][https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/] zu konfigurieren.
Legen Sie ein Timeout für den Knotenausgleich für neue oder vorhandene Knotenpools mit dem
az aks nodepool add- oderaz aks nodepool update-Befehl fest.# 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
Festlegen des Werts für die Knotendurchlaufzeit
Um eine Zeitdauer zuzulassen, die zwischen der Entleerung eines Knotens und dem erneuten Aufspielen des Knotens und dem Übergang zum nächsten Knoten vergehen soll, können Sie eine Knotendurchlaufzeit von 0 bis 30 Minuten festlegen. Wenn kein Wert für die Auslaufzeit des Knotens angegeben wird, beträgt der Standardwert 0 Minuten.
Legen Sie eine Knotendurchlaufzeit für neue oder vorhandene Knotenpools mit dem
az aks nodepool add-,az aks nodepool update- oderaz aks nodepool upgrade-Befehl fest.# 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
Anzeigen von Upgradeereignissen
Zeigen Sie Upgradeereignisse mithilfe des
kubectl get events-Befehls an.kubectl get eventsDie folgende Beispielausgabe zeigt einige der oben aufgeführten Ereignisse während eines Upgrades:
... 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 ...
Nächste Schritte
Informationen zum Konfigurieren von automatischen Upgrades finden Sie unter Konfigurieren automatischer Upgrades für einen AKS-Cluster.
Eine ausführliche Erläuterung zu bewährten Methoden für Upgrades und anderen Überlegungen finden Sie unter AKS Patch- und Upgradeanleitungen.
Azure Kubernetes Service