Freigeben über

Upgradeoptionen für AKS-Cluster (Azure Kubernetes Service)

  • Artikel

In diesem Artikel wurden verschiedene Upgradeoptionen für AKS-Cluster behandelt. Informationen zu einfachen Kubernetes-Versionsupgrades finden Sie unter Upgraden eines AKS-Clusters.

Informationen zu AKS-Clustern, für die mehrere Knotenpools oder Windows Server-Knoten verwendet werden, finden Sie unter Durchführen eines Upgrades für einen Knotenpool in AKS. Informationen zum Upgrade eines bestimmten Knotenpools, ohne ein Upgrade des Kubernetes-Clusters durchzuführen, finden Sie unter Upgrade eines bestimmten Knotenpools.

Durchführen manueller Upgrades

Sie können manuelle Upgrades durchführen, um zu steuern, wann Ihr Cluster auf eine neue Kubernetes-Version upgegradet wird. Manuelle Upgrades sind hilfreich, wenn Sie eine neue Kubernetes-Version testen möchten, bevor Sie Ihren Produktionscluster upgraden. Sie können auch manuelle Upgrades verwenden, um Ihr Cluster auf eine bestimmte Kubernetes-Version upzugraden, die nicht die neueste verfügbare Version ist.

Informationen zu manuellen Upgrades finden Sie in den folgenden Artikeln:

Konfigurieren automatischer Upgrades

Sie können automatische Upgrades so konfigurieren, dass Ihr Cluster automatisch auf die neueste verfügbare Kubernetes-Version upgegradet wird. Automatische Upgrades sind nützlich, wenn Sie sicherstellen möchten, dass Ihr Cluster immer die neueste Kubernetes-Version ausführt. Sie können automatische Upgrades auch verwenden, um sicherzustellen, dass Ihr Cluster immer eine unterstützte Kubernetes-Version ausführt.

Informationen zum Konfigurieren von automatischen Upgrades finden Sie in den folgenden Artikeln:

Besondere Überlegungen für Knotenpools, die sich über mehrere Verfügbarkeitszonen erstrecken

AKS verwendet Best-Effort-Zonenausgleich in Knotengruppen. Während eines Upgradeanstiegs sind die Zonen für die Surge-Knoten in Virtual Machine Scale Sets im Vorfeld unbekannt. Dies kann während eines Upgrades vorübergehend zu einer unausgewogenen Zonenkonfiguration führen. AKS löscht jedoch die Surge-Knoten, sobald das Upgrade abgeschlossen ist, und wahrt das ursprüngliche Zonengleichgewicht. Wenn Ihre Zonen bei Upgrades ausgeglichen bleiben sollen, können Sie den Anstieg auf ein Vielfaches von drei Knoten erhöhen. Virtual Machine Scale Sets gleicht dann Ihre Knoten über Verfügbarkeitszonen hinweg mit dem bestmöglichen Zonenausgleich aus. Beim bestmöglichen Zonengleichgewicht versucht die Skalierungsgruppe, das horizontale Herunter- und Hochskalieren durchzuführen, während das Gleichgewicht beibehalten wird. Falls dies aus bestimmten Gründen nicht möglich ist (wenn beispielsweise eine Zone ausfällt und die Skalierungsgruppe in dieser Zone keine neue VM erstellen kann), lässt die Skalierungsgruppe ein vorübergehendes Ungleichgewicht zu, um das erfolgreiche Ab- und Aufskalieren zu ermöglichen.

Persistent Volume Claims (PVCs), die von lokal redundanten Azure-Speicherdatenträgern (LRS) unterstützt werden, sind an eine bestimmte Zone gebunden und können möglicherweise nicht sofort wiederhergestellt werden, wenn der Anstiegsknoten nicht mit der PVC-Zone übereinstimmt. Wenn die Zonen nicht übereinstimmen, kann dies zu einer Downtime Ihrer Anwendung führen, wenn der Upgradevorgang weiterhin Knoten ausgleicht, die PVs jedoch an eine Zone gebunden sind. Um diesen Fall zu bewältigen und hohe Verfügbarkeit aufrechtzuerhalten, konfigurieren Sie für Ihre Anwendung ein Budget für die Unterbrechung von Pods, damit Kubernetes Ihre Verfügbarkeitsanforderungen während des Entleerungsvorgangs berücksichtigen kann.

Optimieren für das Verhalten von nicht drainbaren Knoten (Vorschau)

Sie können das Upgradeprozessverhalten für Drain-Fehler konfigurieren. Das Standardupgradeverhalten ist Schedule, welches aus einem Drain-Fehler eines Knotens besteht, der dazu führt, dass der Upgradevorgang fehlschlägt, wobei die nicht gedrainten Knoten in einem planbaren Zustand verbleiben. Alternativ können Sie das Cordon-Verhalten auswählen, das Knoten überspringt, die nicht gedraint werden, indem Sie sie in einem isolierten Zustand platzieren, sie als kubernetes.azure.com/upgrade-status:Quarantined beschriften und mit dem Upgrade der verbleibenden Knoten fortfahren. Dieses Verhalten stellt sicher, dass alle Knoten aktualisiert oder isoliert werden. Mit diesem Ansatz können Sie Fehler beim Drain beheben und die isolierten Knoten elegant verwalten.

Wie lege ich das neue Cordon-Verhalten fest?

Verwenden Sie die CLI-Vorschau, und installieren Sie die aks-preview-Erweiterung 9.0.0b3 oder höher.

Sie können die folgenden Befehle verwenden, um die aks-preview-Erweiterung zu aktualisieren oder zu installieren:

az extension update --name aks-preview

az extension add --name aks-preview

Aktualisieren Sie das Verhalten des Knotenpools für nicht drainbare Knoten auf Cordon:

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

Die folgende Beispielausgabe zeigt das Verhalten eines nicht drainbaren Knotens, der aktualisiert wurde:

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

Überprüfen Sie die Bezeichnungen auf allen blockierten Knoten. Wenn beim Upgrade ein Drain-Fehler auf einem Knoten auftritt, verwenden Sie den folgenden Befehl:

kubectl get nodes --show-labels=true

Die blockierten Knoten sind für Pods ungeplant und mit der Beschriftung "kubernetes.azure.com/upgrade-status: Quarantined" gekennzeichnet. Die maximale Anzahl von Knoten, die blockiert werden können, darf nicht mehr als der Max-Surge-Wert sein.

Wie entferne ich die blockierten Knoten?

Beheben Sie zuerst das Problem, das den Drain verursacht. Im folgenden Beispiel wird der verantwortliche PDB entfernt:

kubectl delete pdb nginx-pdb
poddisruptionbudget.policy "nginx-pdb" deleted.

Löschen Sie dann den blockierten Knoten mithilfe des Befehls az aks nodepool delete-machines. Dieser Befehl ist nützlich, wenn Sie beabsichtigen, den Knotenpoolbedarf zu verringern, indem Knoten entfernt werden, die ältere Versionen haben.

az aks nodepool delete-machines --cluster-name MyCluster --machine-names aks-nodepool1-test123-vmss000000 --name nodepool1 --resource-group TestRG

Nachdem Sie diesen Schritt abgeschlossen haben, können Sie den Clusterstatus abgleichen, indem Sie einen Aktualisierungsvorgang ohne die optionalen Felder ausführen, wie hier beschrieben.

Beispiel für einen -Befehl:

az aks update --resource-group TestRG --name MyCluster

Alternativ können Sie den Knotenpool auf dieselbe Anzahl von Knoten skalieren wie die Anzahl der aktualisierten Knoten. Diese Aktion stellt sicher, dass der Knotenpool seine beabsichtigte Originalgröße erhält. AKS priorisiert die Entfernung der blockierten Knoten. Mit diesem Befehl wird auch der Clusterbereitstellungsstatus auf Succeeded wiederhergestellt. Im angegebenen Beispiel ist 2 die Gesamtanzahl der aktualisierten Knoten.

az aks nodepool scale --resource-group TestRG --cluster-name MyCluster --name nodepool1 --node-count 2

Optimieren von Upgrades zur Verbesserung der Leistung und Minimierung von Unterbrechungen

Die Kombination aus Geplantem Wartungsfenster, Maximalem Anstiegswert, Pod-Unterbrechungsbudget, Knotenablauftimeout und Knotendurchlaufzeit kann die Wahrscheinlichkeit eines erfolgreichen Abschlusses von Knotenupgrades bis zum Ende des Wartungsfensters erheblich erhöhen und gleichzeitig Unterbrechungen minimieren.

  • Das geplante Wartungsfenster ermöglicht Serviceteams, das automatische Upgrade während eines vordefinierten Fensters, in der Regel in einem Zeitraum mit geringem Datenverkehr, zu planen, um die Auswirkungen auf die Arbeitsauslastung zu minimieren. Es wird ein Zeitfenster von mindestens vier Stunden empfohlen.
  • Der maximale Anstiegswert für den Knotenpool ermöglicht das Anfordern eines zusätzlichen Kontingents während des Upgradevorgangs und schränkt die Anzahl der gleichzeitig für das Upgrade ausgewählten Knoten ein. Ein höherer maximaler Anstiegswert führt zu einem schnelleren Upgradevorgang. Es wird nicht empfohlen, diesen auf 100 % festzulegen, da dann alle Knoten gleichzeitig aktualisiert werden, was zu Unterbrechungen bei der Ausführung von Anwendungen führen kann. Es wird empfohlen, ein maximales Kontingent von 33 % für Produktionsknotenpools festzulegen.
  • Das Pod-Unterbrechungsbudget wird für Dienstanwendungen festgelegt und begrenzt die Anzahl von Pods, die während freiwilliger Unterbrechungen ausfallen können, z. B. bei AKS-gesteuerte Knotenupgrades. Es kann als minAvailable-Replikate konfiguriert werden, was die Mindestanzahl von Anwendungspods angibt, die aktiv sein müssen, oder als maxUnavailable-Replikate, was die maximale Anzahl von Anwendungspods angibt, die beendet werden können, um die Hochverfügbarkeit für die Anwendung sicherzustellen. Weitere Informationen finden Sie in der bereitgestellten Anleitung zum Konfigurieren von Pod-Unterbrechungsbudgets (Pod Disruption Budgets, PDBs). PDB-Werte sollten überprüft werden, um die Einstellungen zu ermitteln, die für Ihren spezifischen Dienst am besten funktionieren.
  • Mit dem Knotenablauftimeout im Knotenpool können Sie die Wartezeit für die Entfernung von Pods und eine ordnungsgemäße Beendigung pro Knoten während eines Upgrades konfigurieren. Diese Option ist hilfreich beim Umgang mit Workloads mit langer Ausführung. Wenn das Timeout des Knotens angegeben ist (in Minuten), berücksichtigt AKS das Warten auf Pod-Unterbrechungsbudgets. Sofern nicht angegeben, wird der Timeout-Wert standardmäßig auf 30 Minuten festgelegt.
  • Knotendurchlaufzeit hilft dabei, Knotenupgrades auf kontrollierte Weise zu staffeln und Anwendungsausfallzeiten während eines Upgrades zu minimieren. Sie können eine Wartezeit angeben, vorzugsweise möglichst nahe 0 Minuten, um die Anwendungsbereitschaft zwischen Knotenupgrades zu überprüfen. Wenn Sie hier nichts angeben, ist der Standardwert 0 Minuten. Die Knoteneinweichzeit arbeitet mit den im Knotenpool verfügbaren maximalen Auf- und Knoten-Entwässerungstimeout-Eigenschaften zusammen, um die richtigen Ergebnisse in Bezug auf Upgradegeschwindigkeit und Anwendungsverfügbarkeit zu erzielen.

Nächste Schritte

In diesem Artikel wurden verschiedene Upgradeoptionen für AKS-Cluster aufgeführt. Eine ausführliche Erläuterung zu Best Practices für Upgrades und anderen Überlegungen finden Sie unter Patch- und Upgradeanleitungen für AKS.