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 wendet in Knotengruppen den bestmöglichen Zonenausgleich an. 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 Zonenausgleich versucht die Skalierungsgruppe, das Ab- und Aufskalieren durchzuführen und dabei das Gleichgewicht zu erhalten. 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.

PVCs (Persistent Volume Claims, persistente Volumeansprüche), die von Azure-Datenträgern mit lokal redundantem Speicher (LRS) unterstützt werden, sind an eine bestimmte Zone gebunden und können möglicherweise nicht sofort wiederhergestellt werden, wenn der Knoten mit dem Anstieg 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 Pod Disruption Budget, damit Kubernetes Ihre Verfügbarkeitsanforderungen während des Drain-Vorgangs berücksichtigen kann.

Optimieren für das Verhalten von nicht entladbaren 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 Entladen beheben und die isolierten Knoten ordnungsgemäß verwalten.

Festlegen des neuen Absperrverhaltens

Sie müssen die aks-preview-Erweiterung 9.0.0b3 oder höher verwenden, um das neue cordon-Verhalten festzulegen.

  1. Installieren oder aktualisieren Sie die aks-preview Erweiterung mit dem Befehl [az extension add][az-extension-add] oder [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

  2. Aktualisieren Sie mithilfe des Befehls [Cordon][az-aks-nodepool-update] das Verhalten des nicht entladbaren Knotens im Knotenpool in 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

    Die folgende Beispielausgabe zeigt das aktualisierte Verhalten eines nicht entladbaren Knotens:

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

  3. Überprüfen Sie mit dem Befehl kubectl get die Bezeichnung aller blockierten Knoten, wenn beim Upgrade ein Knotenentladungsfehler auftritt.

    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.

Auflösen nicht entladbarer Knoten

  1. Beheben Sie zuerst das zugrunde liegende Problem, das den Drain verursacht. Im folgenden Beispiel wird die zuständige PDB entfernt.

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

  2. Wenn Sie sicher sind, dass das Problem jetzt behoben ist, können Sie die Bezeichnung "kubernetes.azure.com/upgrade-status: Quarantined" auf nicht entladbaren Knoten mit dem Befehl kubectl label entfernen.

    kubectl label nodes <node-name> <label-key>-

    Alle nachfolgenden PUT-Vorgänge zuerst versuchen, den Failed Provisioning Status im Cluster auf Success abzustimmen. Die in Quarantäne befindlichen Knoten werden für nachfolgende Put- oder Abstimmungsvorgänge nicht berücksichtigt. Sie müssen die Labels explizit entfernen, wie zuvor erwähnt, damit alle blockierten Knoten berücksichtigt werden.

  3. Sie können den blockierten Knoten auch mithilfe des Befehls [az aks nodepool delete-machines][az-aks-nodepool-delete-machines] löschen. Dieser Befehl ist nützlich, wenn Sie beabsichtigen, den Umfang des Knotenpools zu verringern, indem Sie Knoten entfernen, die in älteren Versionen zurückgeblieben sind.

    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

  4. 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. 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.

    # 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

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.
  • Mit Max. nicht verfügbar (Vorschau) im Knotenpool können Upgrades durchgeführt werden, indem die vorhandenen Knoten gesperrt und entladen werden, ohne Anstiegsknoten hinzuzufügen. Ein höheres Maximum an nicht verfügbaren Knoten führt zu einem schnelleren Upgrade, verursacht aber auch mehr Workloadunterbrechungen im Knotenpool. Dieses Feature wird für Kunden mit Kapazitätsbeschränkungen empfohlen, da keine zusätzliche SKU-Kapazität in der Region oder bei Kontingentproblemen besteht.
  • Das Pod-Unterbrechungsbudget wird für Serviceanwendungen festgelegt und begrenzt die Anzahl von Pods, die während freiwilliger Unterbrechungen, wie z. B. bei AKS-gesteuerten Knotenupgrades, ausfallen können. 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. Siehe die bereitgestellte Anleitung zum Konfigurieren von 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 Node Drain Timeout im Knotenpool können Sie die Wartezeit für die Räumung von Pods und eine sanfte Beendigung pro Knoten während eines Upgrades konfigurieren. Diese Option ist nützlich für lange laufende Arbeitslasten. Wenn das Entladetimeout 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 Knotendurchlaufzeit kann zusammen mit den im Knotenpool verfügbaren maximalen Timeouteigenschaften für Anstieg und Knotenentladung dafür sorgen, die richtigen Ergebnisse in Bezug auf Upgradegeschwindigkeit und Anwendungsverfügbarkeit zu erzielen.
Upgradeeinstellungen Verfügbare Ressourcen für den Anstieg Erwartetes Verhalten
maxSurge = 5maxUnavailable = 0 5 Knoten für Anstieg verfügbar 5 Knoten werden vergrößert, um den Knotenpool zu upgraden.
maxSurge = 5maxUnavailable = 0 0–4 Knoten für Anstieg verfügbar Der Upgradevorgang verursacht Fehler, da nicht genügend Knoten zum Erfüllen von maxSurge vorhanden sind.
maxSurge = 0maxUnavailable = 5 N/A, da keine Überspannungsknoten benötigt werden Der Vorgang verwendet fünf Knoten aus dem vorhandenen Knotenpool, ohne neue Knoten hinzuzufügen, um den Knotenpool zu aktualisieren.

Validierungen, die heute im Upgradeprozess verwendet werden

Wenn Sie einen Upgradevorgang über API, Azure CLI oder Azure-Portal initiieren, führt Azure Kubernetes Service (AKS) vor dem Starten des Upgrades eine Reihe von Überprüfungen vor dem Upgrade durch. Diese Überprüfungen stellen sicher, dass sich der Cluster in einem fehlerfreien Zustand befindet und erfolgreich aktualisiert werden kann.

  • API Breaking Changes: Identifiziert, ob veraltete APIs in Gebrauch sind, die sich auf Workloads auswirken können.
  • Kubernetes Upgrade-Version: Stellt sicher, dass die Zielversion gültig ist (z. B. keine Sprünge größer als drei Nebenversionen, keine Downgrades und Kompatibilität mit der Steuerungsebene).
  • Überprüfung auf fehlerhafte PDB-Konfiguration: Überprüft auf falsch konfigurierte PDBs (Pod Disruption Budgets) wiemaxUnavailable = 0, die keine Unterbrechung von Knoten zulassen.
  • Kontingent: Bestätigt, dass während des Upgradevorgangs ein ausreichendes Kontingent für Knotenanstiege vorhanden ist.
  • Subnetz: Überprüft, ob genügend allokierbare IP-Adressen für das Upgrade vorhanden sind oder ob Anpassungen der Subnetzgröße erforderlich sind.
  • Zertifikate/Dienstprinzipale: Erkennt abgelaufene Zertifikate oder Dienstprinzipale, die sich auf den Upgradeprozess auswirken könnten.

Diese Prüfungen tragen dazu bei, Upgradefehler zu minimieren und Benutzern frühzeitige Einblicke in potenzielle Probleme zu geben, die eine Lösung benötigen, bevor Sie fortfahren.

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.