Unterstützung für die Verbesserung dieser Seite beitragen

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Um zu diesem Benutzerhandbuch beizutragen, wählen Sie den GitHub Link Diese Seite bearbeiten unter, der sich im rechten Bereich jeder Seite befindet.

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Einen Cluster auf eine frühere Kubernetes-Version zurücksetzen

Mit dem Amazon EKS-Versions-Rollback können Sie die Kubernetes-Steuerungsebene Ihres Clusters auf die vorherige Nebenversion zurücksetzen, nachdem Sie ein direktes Upgrade durchgeführt haben. Wenn Sie nach dem Upgrade auf Probleme stoßen, wie z. B. Anwendungsinkompatibilitäten, veraltete API-Nutzung oder unerwartetes Verhalten, können Sie ein Rollback durchführen, um Ihren Cluster in einen zweifelsfrei funktionierenden Zustand zurückzusetzen.

Während eines Rollbacks setzt Amazon EKS den Kubernetes-API-Server und die Komponenten der Steuerungsebene auf die vorherige Version zurück, während alle etcd-Daten, Kunden-Workloads und persistenten Volumes erhalten bleiben.

Was wird rückgängig gemacht

Für die folgenden Komponenten wird ein Rollback durchgeführt:

Was wird NICHT zurückgesetzt

Für die folgenden Komponenten wird kein Rollback durchgeführt:

Voraussetzungen

Bevor Sie ein Cluster-Rollback durchführen können, müssen alle folgenden Bedingungen erfüllt sein:

Zusätzlich zu den oben genannten Anforderungen gibt es bestimmte Bedingungen, die ein Rollback unmöglich machen, selbst wenn die Flagge aktiviert ist. --force Zu diesen Bedingungen gehören die folgenden: Der Cluster wurde mit der aktuellen Version erstellt, seit dem Upgrade sind mehr als 7 Tage vergangen, der Cluster wurde bereits erneut auf eine neuere Version aktualisiert oder eine abwärtsinkompatible EKS-Funktion wurde an der aktuellen Versionsgrenze aktiviert.

Zusammenfassung

Im Folgenden finden Sie eine allgemeine Zusammenfassung des Amazon EKS-Cluster-Rollback-Prozesses:

Schritt 1: Überprüfen Sie die Erkenntnisse zur Rollback-Bereitschaft

Amazon EKS bewertet Ihren Cluster automatisch anhand einer Reihe von Überprüfungen der Rollback-Bereitschaft zu einem bestimmten Zeitpunkt und deckt alle Probleme anhand der Cluster-Einblicke in die Kategorie auf. ROLLBACK_READINESS Diese Erkenntnisse werden angezeigt, nachdem Sie ein Upgrade durchgeführt haben, und bleiben während des 7-tägigen Zeitfensters, in dem das Rollback berechtigt ist, verfügbar.

Einblicke in die Bereitschaft zum Rollback anzeigen

AWS Konsole:

AWS CLI:

aws eks list-insights \
  --cluster-name my-cluster \
  --region us-west-2 \
  --filter '{"categories": ["ROLLBACK_READINESS"]}'

Um Details zu einem bestimmten Einblick zu erhalten:

aws eks describe-insight \
  --cluster-name my-cluster \
  --region us-west-2 \
  --id <insight-id>

Erfrischende Erkenntnisse

Amazon EKS aktualisiert die Erkenntnisse alle 24 Stunden. Sie können nach der Behebung von Problemen manuell eine Aktualisierung auslösen, indem Sie in der Amazon EKS-Konsole auf die Schaltfläche Aktualisieren klicken oder die CLI verwenden:

aws eks start-insights-refresh \
  --cluster-name my-cluster \
  --region us-west-2

Verhalten beim Insight-Status

In der folgenden Tabelle werden die Bedeutung der einzelnen Insight-Status und ihre Auswirkung auf das Rollback beschrieben:

Insights mit dem Status ERROR oder UNKNOWN blockieren das Rollback. Insights mit dem Status PASSING oder WARNING hindern Sie nicht daran, einen Rollback durchzuführen.

Überprüfungen der Bereitschaft zum Rollback

Amazon EKS führt im Rahmen der Erkenntnisse zur Rollback-Bereitschaft eine Reihe von Prüfungen durch. Bei diesen Prüfungen werden die API-Nutzungskompatibilität (einschließlich der Erkennung von Änderungen auf Feldebene), der Cluster-Zustand, der Kubelet-Versionsversatz, der Kube-Proxy-Versionsversatz und die Kompatibilität der Zusatzversionen bewertet. Bei Clustern, auf denen der EKS-Automatikmodus ausgeführt wird, werden bei zusätzlichen Prüfungen die Budgets für Unterbrechungen, Anmerkungen und Konfigurationen bewertet, bei denen keine NodePool Störungen auftreten. PodDisruptionBudget

Verwenden Sie das Flag --force

Wenn Rollback Readiness Insights den Status ERROR anzeigen und Sie fortfahren möchten, ohne die Probleme zu lösen, können Sie das --force Flag verwenden, um alle Insight-Checks zu umgehen:

aws eks update-cluster-version \
  --name my-cluster \
  --kubernetes-version 1.30 \
  --force \
  --region us-west-2

Die --force Flagge umgeht nur Insight-Checks. Es umgeht keine erforderlichen Validierungen wie das 7-Tage-Fenster, die Versionsprüfung bei der Erstellung oder die sequentielle Rollback-Überprüfung. Bei Clustern im automatischen Modus werden Unterbrechungskontrollen --force nicht außer Kraft gesetzt. NodePool Unterbrechungsbudgets, PDBs und Anmerkungen, die nicht unterbrochen werden dürfen, werden weiterhin berücksichtigt.

Schritt 2: Bereiten Sie die Worker-Knoten vor

Stellen Sie vor dem Rollback der Steuerungsebene sicher, dass Ihre Worker-Knoten mit der Zielversion kompatibel sind. Die Kubernetes-Richtlinie zur Versionsverzerrung verlangt, dass auf den Worker-Knoten keine neuere Version als die Steuerungsebene ausgeführt werden kann.

EKS Auto Mode

Es ist keine Aktion erforderlich. Wenn Sie das Rollback einleiten, führt Amazon EKS automatisch ein Rollback der Auto-Mode-Knoten vor der Steuerungsebene durch. Weitere Informationen finden Sie unter Rollback EKS-Automodus-Cluster.

Verwaltete Knotengruppen (MNG)

Sie müssen Ihre verwalteten Knotengruppen auf die vorherige Version zurücksetzen, bevor Sie ein Rollback der Steuerungsebene durchführen. Verwenden Sie die UpdateNodegroupVersion API:

aws eks update-nodegroup-version \
  --cluster-name my-cluster \
  --nodegroup-name my-nodegroup \
  --kubernetes-version 1.30 \
  --region us-west-2

Das Knotengruppen-Update berücksichtigt Ihre konfigurierten Aktualisierungseinstellungen (maxUnavailableodermaxUnavailablePercentage) und Ihre Aktualisierungsstrategie (Rolling oder Force).

Self-managed Knoten und Hybridknoten

Sie sind für das Rollback von selbstverwalteten Knoten und Hybridknoten verantwortlich. Aktualisieren Sie Ihre Knoten-AMIs oder -Konfigurationen so, dass sie die vorherige Kubernetes-Version verwenden, bevor Sie ein Rollback der Steuerungsebene durchführen.

Fargate

Das Versions-Rollback wird für Fargate-Worker-Knoten nicht unterstützt. Sie können die Steuerungsebene eines Clusters, der Fargate verwendet, rückgängig machen, aber Fargate-Pods, auf denen dieselbe Kubernetes-Version wie die Steuerungsebene ausgeführt wird, lösen den Skew-Insight der Kubelet-Version mit dem Status ERROR aus.

Amazon EKS kann Fargate-Pods nicht automatisch auf eine ältere Kubelet-Version zurücksetzen.

Problemumgehung: Wenn Sie Fargate-Pods haben, auf denen dieselbe Kubernetes-Version wie auf der Steuerungsebene ausgeführt wird, löschen Sie diese Pods, bevor Sie das Rollback einleiten. Rollen Sie dann Ihre Kontrollebene zurück. Alle verbleibenden Pods werden mit der Rollback-Version gestartet, wenn Sie sie erneut bereitstellen.

Verwenden Sie es alternativ, --force um den Insight-Check zu umgehen. Wenn Sie jedoch mit einer Kubelet-Versionsverzerrungsverletzung fortfahren, kann dies zu unerwartetem Verhalten Ihrer Fargate-Workloads führen, bis diese Pods ersetzt werden.

Schritt 3: Führen Sie die Cluster-Steuerungsebene zurück

Sie können ein Rollback mithilfe der AWS Konsole, der AWS CLI oder der EKS-API initiieren.

Führen Sie ein Rollback eines Clusters durch, indem Sie den AWS Konsole

Das Rollback dauert mehrere Minuten. Bei Clustern im automatischen Modus kann die Node-Rollback-Phase länger dauern. Weitere Informationen finden Sie unter Rollback EKS-Automodus-Cluster.

Führen Sie ein Rollback eines Clusters durch, indem Sie den AWS CLI

Verwenden Sie den vorhandenen update-cluster-version Befehl mit der vorherigen (N-1) Kubernetes-Version:

aws eks update-cluster-version \
  --name my-cluster \
  --kubernetes-version 1.30 \
  --region us-west-2

Beispielantwort:

{
    "update": {
        "id": "e4091a28-ea14-48fd-a8c7-975aeb469e8a",
        "status": "InProgress",
        "type": "VersionRollback",
        "params": [
            {
                "type": "Version",
                "value": "1.30"
            },
            {
                "type": "PlatformVersion",
                "value": "eks.16"
            }
        ],
        "createdAt": "2026-05-12T16:56:01.082000-04:00",
        "errors": []
    }
}

Schritt 4: Überwachen Sie den Fortschritt des Rollbacks

Sie können den Status Ihres Cluster-Rollbacks mithilfe der Amazon EKS-Konsole oder der AWS CLI überwachen.

AWS CLI:

aws eks describe-update \
  --name my-cluster \
  --region us-west-2 \
  --update-id e4091a28-ea14-48fd-a8c7-975aeb469e8a

AWS Konsole:

Statusübergänge

Für Standardcluster (ohne Automatik-Modus):

InProgress → Successful
InProgress → Failed

Bei Clustern im automatischen Modus bleibt der Cluster-Status bestehen, ACTIVE während die Knoten zurückgesetzt werden, und er wechselt UPDATING erst, wenn das Rollback der Steuerungsebene beginnt. Wird verwendetdescribe-update, um den gesamten Fortschritt des Rollbacks zu verfolgen. Weitere Informationen finden Sie unter Rollback EKS-Automodus-Cluster.

Wenn ein Successful Status angezeigt wird, ist das Rollback abgeschlossen.

Überlegungen und Warnungen

Erkenntnisse werden nach bestem Wissen erstellt und sind zeitnah

Cluster-Erkenntnisse werden zu dem Zeitpunkt ausgewertet, zu dem das Rollback ausgelöst wird. Wenn Sie Änderungen an Ihrem Cluster vornehmen, nachdem die Insights überprüft wurden, aber bevor das Rollback abgeschlossen ist (z. B. indem Sie Ressourcen mithilfe neuer APIs erstellen), werden diese Änderungen bei der ersten Insight-Prüfung nicht erfasst und können nach Abschluss des Rollbacks zu Problemen führen.

etcd Datenerhaltung

Amazon EKS bewahrt etcd-Daten während des Rollbacks auf. Inkompatible Ressourcen, die mithilfe des --force Flags umgangen werden, bleiben bestehen und werden nicht gelöscht.

Erweiterte Support-Gebühren

Wenn Sie ein Rollback von einer Version mit Standardsupport auf eine Version mit erweitertem Support durchführen, fallen für Ihren Cluster allmählich Gebühren für erweiterten Support an. Wenn Sie beispielsweise ein Upgrade von 1.30 (erweiterter Support) auf 1.31 (Standardsupport) durchführen und dann auf 1.30 zurücksetzen, fallen die Gebühren für den erweiterten Support wieder an.

Modell der geteilten Verantwortung für Rollback

Amazon EKS setzt die Kubernetes-Steuerungsebene auf die gewünschte Version zurück. Im Rahmen des Modells der gemeinsamen Verantwortung sind Sie dafür verantwortlich, die Anwendungskompatibilität mit der Vorgängerversion zu überprüfen:

CloudFormation Verhalten beim Stack-Rollback

Wenn ein CloudFormation AWS-Stack-Update fehlschlägt und ein Stack-Rollback auslöst, löst das Zurücksetzen auf eine frühere Vorlagenversion, die eine niedrigere Kubernetes-Version angibt, kein Rollback der Clusterversion aus. Das Versions-Rollback muss explizit über die UpdateClusterVersion API, CLI oder Konsole initiiert werden.

Rollback und Add-Ons

Amazon EKS führt während eines Rollbacks der Cluster-Version kein automatisches Rollback von Add-On-Versionen durch. Sie müssen Zusatzversionen separat verwalten.

Bevor Sie die Steuerungsebene zurücksetzen:

Zugehörige Ressourcen