Zurücksetzen von Knotenpoolversionen in Azure Kubernetes Service (AKS)

Mit der Rollback-Funktion für die Knotenpool-Version in Azure Kubernetes Service (AKS) können Sie unerwartete Probleme nach Kubernetes-Upgrades beheben. Wenn Probleme auftreten, können Sie Knotenpools auf die vorherige Kubernetes-Version und knotenimage-Kombination zurücksetzen, um die Geschäftskontinuität sicherzustellen und Ausfallzeiten zu minimieren. In diesem Artikel wird erläutert, wann und wie Sie das Rollbackfeature, seine Funktionen und Einschränkungen sowie bewährte Methoden für Nachrollbackaktionen verwenden.

Voraussetzungen

• Azure CLI Version 2.88.0 oder höher. Suchen Sie Ihre Version mithilfe des az --version Befehls. Informationen zum Installieren oder Aktualisieren finden Sie unter Install Azure CLI. Die aks-preview Erweiterung ist nicht erforderlich.
• API-Version 2026-04-01 oder höher.

Unterstützte Features für das Rollback der Knotenpoolversion

Die Rollback-Funktion von Knotenpool-Versionen unterstützt folgende Fähigkeiten:

Einschränkungen und Aspekte bei Knotenpool-Rollbacks

Beachten Sie bei der Verwendung der Rollback-Funktion des Knotenpools die folgenden Einschränkungen:

• Nur auf Versionsänderungen beschränkt. Andere Knotenpooländerungen werden nicht rückgängig gemacht.
• Während des Rollbacks sind keine gleichzeitigen Vorgänge zulässig.
• Sie müssen den Kubernetes-Kanal für automatische Upgrades vor dem Rollback deaktivieren. Wenn der Knoten-Betriebssystemupgradekanal aktiviert ist, kann das Kubernetes-Versionsrollback fortgesetzt werden, das vorherige Knotenimage wird jedoch möglicherweise nicht wiederhergestellt. Deaktivieren Sie den Knotenbetriebssystem-Upgradekanal, wenn Sie sowohl das Kubernetes-Versions- als auch das Knotenimage zurücksetzen müssen.
• Nur sieben Tage nach Abschluss des Upgrades verfügbar.
• Es ist nicht möglich, aufeinanderfolgende Rollbacks auszuführen, um mehrere frühere Versionen wiederherzustellen.
• Rollback unterstützt das Wiederherstellen von Betriebssystem-SKU-Änderungen nicht. Wenn Sie die Betriebssystem-SKU Ihres Knotenpools (z. B. von Ubuntu zu Azure Linux) geändert haben, versucht der Rollback, die vorherige Knotenimageversion wiederherzustellen, die zu einer anderen Betriebssystem-SKU gehört und abgelehnt wird. Wenn Sie eine Betriebssystem-SKU-Änderung wiederherstellen möchten, verwenden Sie stattdessen den az aks nodepool update --os-sku Befehl.

Beachten Sie bei der Verwendung des Knotenpoolrollbacks die folgenden Überlegungen:

Gründe für die Verwendung von Rollback

Rollback bietet einen kritischen Wiederherstellungsmechanismus für Produktionsumgebungen:

• Geschäftskontinuität: Minimieren von Ausfallzeiten, wenn Upgrades unerwartete Probleme verursachen
• Risikominderung: Schnelle Wiederherstellung bekannter Konfigurationen ohne komplexe Wiederherstellungsverfahren
• Vereinfachte Wiederherstellung: Vermeiden manueller Interventionen oder Neuerstellen von Clustern aus Sicherungen

Wann der Knotenpool-Rollback verwendet werden sollte

Erwägen Sie das Rollback als Wiederherstellungsoption in den folgenden Szenarien:

• Upgradefehler treten auf: Infrastrukturprobleme, Ressourceneinschränkungen oder Kompatibilitätsprobleme verhindern erfolgreiche Upgrades.
• Anwendungen brechen ab: Arbeitslasten erleiden mit neueren Kubernetes-Versionen kritische Fehler oder Datenbeschädigungen.
• Leistungseinbußen: Neue Versionen verursachen inakzeptable Latenz, Durchsatzprobleme oder Ressourcenverbrauch.
• Testlücken ergeben sich: Probleme in der Produktion, die während der Vorproduktionstests nicht erfasst wurden.

Rollback-Workflow für Knotenpool

Das folgende Diagramm veranschaulicht den Workflow für den Knotenpoolrollback:

Der Rollbackvorgang stellt alle Knoten in einem Knotenpool in ihrem vorherigen Versionsstatus wieder her. Zu den wichtigsten Aspekten des Workflows gehören:

• All-or-nothing-Ansatz: Alle Knoten müssen erfolgreich auf die vorherige Version zurückgesetzt werden, damit das Rollback erfolgreich abgeschlossen wird. Wenn bei einem Knoten ein Rollback fehlschlägt, schlägt der gesamte Vorgang fehl, um den Status des Clusters deutlich zu kommunizieren, ähnlich wie beim Upgradevorgang.
• Progress tracking: Überwachen Sie den Rollbackstatus mithilfe des Azure-Aktivitätsprotokolls für den Vorgangsverlauf und der Vorgangsstatus-API für Echtzeitaktualisierungen.

Zurücksetzen einer Knotenpoolversion

Der Azure CLI Rollbackbefehl wählt automatisch die zuletzt aufgezeichnete Version aus, auch bekannt als N-1. Sie können den Befehl nicht verwenden, um eine beliebige Kubernetes- oder Knotenimageversion auszuwählen, und Sie können keine aufeinander folgenden Rollbacks ausführen, um mehrere frühere Versionen zu durchlaufen.

1. Überprüfen Sie die Konfiguration des automatischen Upgrades des Clusters.

   az aks show \
       --name myAKSCluster \
       --resource-group myResourceGroup \
       --query autoUpgradeProfile
   

   Deaktivieren Sie den Automatischen Upgradekanal kubernetes vor dem Rollback. Wenn Sie das vorherige Knotenimage wiederherstellen müssen, deaktivieren Sie auch den Knotenbetriebssystem-Upgradekanal.

2. Überprüfen Sie das verfügbare Rollbackziel mithilfe des az aks nodepool get-rollback-versions Befehls.

   az aks nodepool get-rollback-versions \
       --name myNodePool \
       --resource-group myResourceGroup \
       --cluster-name myAKSCluster
   

   Wenn der Befehl keine Versionen zurückgibt, verfügt der Knotenpool nicht über ein berechtigtes Rollbackziel. Der Knotenpool muss innerhalb der vorherigen sieben Tage aktualisiert worden sein, und die aufgezeichnete Kubernetes-Version muss von AKS weiterhin unterstützt werden.

3. Führen Sie einen Rollback des Knotenpools mithilfe des az aks nodepool rollback Befehls aus.

   az aks nodepool rollback \
       --name myNodePool \
       --resource-group myResourceGroup \
       --cluster-name myAKSCluster
   

4. Überprüfen Sie die Kubernetes-Version, die Knotenimageversion und den Bereitstellungsstatus nach Abschluss des Rollbacks.

   az aks nodepool show \
       --name myNodePool \
       --resource-group myResourceGroup \
       --cluster-name myAKSCluster \
       --query '{provisioningState:provisioningState,kubernetesVersion:currentOrchestratorVersion,nodeImageVersion:nodeImageVersion}'
   

   Ein erfolgreicher Rollback gibt zurück SucceededprovisioningState und zeigt die aufgezeichneten Kubernetes- und Knotenbildversionen an.

Wenn Sie die Einstellungen für das automatische Upgrade des Clusters vor dem Rollback geändert haben, stellen Sie die beabsichtigten Einstellungen wieder her, nachdem Sie das Upgradeproblem untersucht und behoben haben.

Überwachung des Rollback-Status des Knotenpools

Mit den folgenden Methoden können Sie den Status eines Rollbackvorgangs eines Knotenpools überwachen und ein erfolgreiches Rollback überprüfen:

• Nachschlagen von Aktivitätsprotokollen in Ihrem Cluster.
• Suchen Sie bestimmte Upgrade-bezogene Ereignisse in Ihrem Cluster.
• Abonnieren Sie AKS-Ereignisse mit Azure Event Grid.
• Wenn Sie einen Kanal für automatische Upgrades abonnieren, können Sie AKS Communication Manager für Upgradebenachrichtigungen verwenden.

Problembehandlung beim Rollback des Knotenpools

In der folgenden Tabelle werden allgemeine Rollbackprobleme und deren Behebung beschrieben:

Bewährte Methoden nach dem Rollback

Verwenden Sie nach dem erfolgreichen Zurücksetzen des Knotenpools die folgenden bewährten Verfahren, um Stabilität und Sicherheit zu gewährleisten:

• Untersuchen Sie die Ursache: Ermitteln Sie, warum das Upgrade fehlgeschlagen ist, bevor Sie ein anderes Upgrade versuchen. Überprüfen Sie Anwendungsprotokolle, Ressourcenmetriken und Kompatibilitätsanforderungen.
• Test in Nichtproduktion: Überprüfen Sie die neuere Version in einer Entwicklungs- oder Stagingumgebung, um Probleme zu reproduzieren und zu beheben, bevor Sie die Produktion erneut aktualisieren.
• Planen Sie Ihr erneutes Upgrade: Belassen Sie die Version nach dem Rollback nicht auf Dauer. Planen Sie ein erneutes Upgrade, um Sicherheitspatches und -support zu verwalten:
  • Bei kritischen Sicherheitsproblemen: Aktualisieren Sie das Upgrade innerhalb von Tagen nach der Überprüfung der Korrekturen erneut.
  • Bei Anwendungskompatibilitätsproblemen: Aktualisieren Sie das Upgrade innerhalb von Wochen nach Codeanpassungen erneut.
  • Maximal empfohlener Zeitrahmen: 30 Tage, um die Akkumulation von Sicherheitsrisiken zu vermeiden.

Häufig gestellte Fragen (FAQs)

Kann ich während eines Knotenpoolrollbacks andere Vorgänge ausführen?

Nein, das Rollback muss abgeschlossen werden, bevor andere Vorgänge gestartet werden. Wenn Sie verschiedene Vorgänge ausführen möchten, beenden Sie zuerst das Rollback.

Wird beim Rollback des Knotenpools sowohl die Kubernetes-Version als auch das Knotenabbild zurückgesetzt?

Ja, der Rollback wird auf die zuletzt verwendete Kubernetes-Version und das entsprechende Knotenimage zurückgesetzt. Wenn beide Komponenten geändert wurden, stellt das System die vorherige Kubernetes-Version mit dem letzten kompatiblen Knotenimage für diese Version wieder her.

Kann ich nur das Knotenimage zurücksetzen, ohne die Knotenpoolversion zu ändern?

Ja, wenn Sie innerhalb der letzten sieben Tage nur ein Knotenimage-Update durchgeführt haben (ohne ein Upgrade der Knotenpoolversion), wird das vorherige VHD-Image durch ein Rollback wiederhergestellt, während dieselbe Kubernetes-Version beibehalten wird.

Kann ich ein Rollback auf eine Version durchführen, die nicht mehr unterstützt wird?

Nein, Sie können kein Rollback auf eine Kubernetes-Version durchführen, die von AKS nicht mehr unterstützt wird. Wenn sich Ihr Knotenpool beispielsweise auf Version 1.27.9 (jetzt nicht mehr unterstützt) befand und Sie auf 1.28.5 aktualisiert haben, können Sie kein Rollback auf 1.27.9 durchführen, da es sich nicht mehr in der Liste der unterstützten Versionen befindet. Überprüfen Sie immer die AKS Kubernetes-Versionsunterstützungsrichtlinie , um die Versionsverfügbarkeit zu überprüfen.

Muss ich das automatische Upgrade deaktivieren, bevor ich ein Rollback eines Knotenpools durchführe?

Ja, Sie müssen den Kubernetes-Kanal für automatische Upgrades deaktivieren, bevor Sie ein Rollback ausführen. Wenn Sie nur den Knoten-Betriebssystemupgradekanal aktivieren, kann das Kubernetes-Versionsrollback fortgesetzt werden, das vorherige Knotenimage wird jedoch möglicherweise nicht wiederhergestellt. Deaktivieren Sie den Knotenbetriebssystem-Upgradekanal, wenn Sie sowohl das Kubernetes-Versions- als auch das Knotenimage zurücksetzen müssen.

Wenn der Cluster in einer Updategruppe in einem Azure Kubernetes Fleet Manager-Autoupgradeprofil enthalten ist, müssen Sie den Cluster auch aus der Updategruppe entfernen, bevor Sie das Rollback ausführen. Andernfalls kann der Autoupgrade-Prozess den Knotenpool nach Abschluss des Rollbacks automatisch erneut aktualisieren.

Kann ich nach einer Änderung der Betriebssystem-SKU (z. B. von Ubuntu zu Azure Linux) wieder auf den vorherigen Zustand zurückkehren?

Nein. Das Rollback des Knotenpools ist auf Versionsänderungen beschränkt und setzt keine Betriebssystem-SKU-Änderungen zurück. Nach der Migration von einer Betriebssystem-SKU zu einer anderen (z. B. Ubuntu zu Azure Linux) gehört die vorherige Knotenimageversion zur alten Betriebssystem-SKU und ist mit der aktuellen Konfiguration nicht kompatibel. Der Rollbackvorgang lehnt die vorherige Bildversion mit einem Fehler ab, der einem ähnlichen Fehler wie folgt ähnelt:

NodeImageVersion 'AKSUbuntu-2204gen2containerd-202602.13.5' is not accepted. NodeImageVersion can only be current version 'AKSAzureLinux-V3gen2-202602.13.5' or 'latest'

Verwenden Sie zum Wiederherstellen der Betriebssystem-SKU den az aks nodepool update Befehl mit dem --os-sku Parameter. Weitere Informationen finden Sie unter Zurücksetzen der Betriebssystemversion.

Verwandte Inhalte

Weitere Informationen zu Knotenpoolupgrades in AKS finden Sie in den folgenden Artikeln:

• Konfigurieren Sie Blue-Green-Upgrades für den Knotenpools im Azure Kubernetes Service (AKS)
• Konfigurieren Sie rollierende Aktualisierungen für Azure Kubernetes Service (AKS) Knotenpools
• Automatische Aktualisierung von Knoten-Betriebssystemabbildern in Azure Kubernetes Service (AKS)