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 auf, 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.

Rollback des Clusters auf vorherige Kubernetes-Version

Mit dem Amazon EKS-Versions-Rollback können Sie die Kubernetes-Steuerebene Ihres Clusters auf die vorherige Nebenversion zurücksetzen, nachdem Sie ein direktes Upgrade durchgeführt haben. Wenn nach dem Upgrade Probleme auftreten, wie z. B. Anwendungsinkompatibilitäten, veraltete API-Nutzung oder unerwartetes Verhalten, können Sie einen Rollback durchführen, um Ihren Cluster auf 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, wobei alle etcd-Daten, Kunden-Workloads und persistenten Volumes beibehalten werden.

Was wird zurückgesetzt

Was wird NICHT zurückgesetzt

Voraussetzungen

Bevor Sie einen Cluster rückgängig machen können, müssen alle der folgenden Bedingungen erfüllt sein:

Zusätzlich zu den oben genannten Anforderungen machen bestimmte Bedingungen ein Rollback auch mit der Markierung unmöglich. --force Dazu gehören: 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 an der aktuellen Versionsgrenze wurde eine abwärtsinkompatible EKS-Funktion aktiviert.

Zusammenfassung

Die allgemeine Zusammenfassung des Amazon EKS-Cluster-Rollback-Prozesses lautet wie folgt:

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

Amazon EKS bewertet Ihren Cluster automatisch anhand einer Reihe von zeitpunktbezogenen Rollback-Bereitschaftsprüfungen und deckt alle Probleme anhand von Cluster-Erkenntnissen unter der Kategorie auf. ROLLBACK_READINESS Diese Erkenntnisse werden angezeigt, nachdem Sie ein Upgrade durchgeführt haben, und stehen während des 7-tägigen Rollback-Berechtigungsfensters weiterhin zur Verfügung.

Einblicke in die Rollback-Bereitschaft anzeigen

AWS Konsole:

AWS CLI:

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

Um Einzelheiten zu einem bestimmten Einblick zu erhalten:

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

Erfrischende Einblicke

EKS aktualisiert die Erkenntnisse alle 24 Stunden. Sie können manuell eine Aktualisierung auslösen, nachdem Sie Probleme behoben haben, indem Sie die Schaltfläche Aktualisieren in der Amazon EKS-Konsole verwenden oder die CLI verwenden:

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

Verhalten des Insight-Status

Insights mit dem Status FEHLER oder UNBEKANNT blockieren den Rollback. Erkenntnisse mit dem Status PASSING oder WARNING hindern Sie nicht daran, ein Rollback durchzuführen.

Prüfungen, ob ein Rollback bereit ist

Amazon EKS führt im Rahmen von Rollback Readiness Insights eine Reihe von Prüfungen durch. Bei diesen Prüfungen werden die Kompatibilität der API-Nutzung (einschließlich der Erkennung von Änderungen auf Feldebene), die Cluster-Integrität, die Kubelet-Versionsabweichung, die Kube-Proxy-Versionsabweichung und die Kompatibilität der Add-On-Versionen bewertet. Bei Clustern, auf denen der automatische EKS-Modus ausgeführt wird, werden durch zusätzliche Prüfungen die Budgets für Störungen, Anmerkungen und Konfigurationen bewertet, die nicht NodePool gestört werden müssen. PodDisruptionBudget

Verwenden des Flags --force

Wenn Rollback Readiness Insights den Status FEHLER anzeigt 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 Markierung 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 zur Nichtunterbrechung werden weiterhin berücksichtigt.

Schritt 2: Worker-Knoten vorbereiten

Stellen Sie vor dem Rollback der Steuerungsebene sicher, dass Ihre Worker-Knoten mit der Zielversion kompatibel sind. Die Richtlinie „Version Skew“ von Kubernetes verlangt, dass Worker-Knoten keine neuere Version als die Kontrollebene ausführen dürfen.

EKS Auto Mode

Es ist keine Aktion erforderlich. Wenn Sie das Rollback initiieren, führt EKS automatisch ein Rollback der Knoten im automatischen Modus 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 die Steuerungsebene zurücksetzen können. 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, sodass sie die vorherige Kubernetes-Version verwenden, bevor Sie die Kontrollebene zurücksetzen.

Fargate

Ein 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 Kontrollebene ausgeführt wird, lösen die Kubelet-Version Skew Insight mit dem Status ERROR aus.

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. Führen Sie dann ein Rollback Ihrer Steuerungsebene durch. Alle verbleibenden Pods werden mit der Rollback-Version gestartet, wenn Sie sie erneut bereitstellen.

Verwenden Sie diese Option alternativ, --force um die Insight-Prüfung zu umgehen. Wenn Sie jedoch mit einem Verstoß gegen die Kubelet-Versionsverzerrung fortfahren, kann dies zu unerwartetem Verhalten für Ihre Fargate-Workloads führen, bis diese Pods ersetzt werden.

Schritt 3: Rollback der Cluster-Steuerungsebene

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

Rollback-Cluster mit dem AWS Konsole

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

Rollback-Cluster mit dem 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 mit 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 automatischen Modus):

InProgress → Successful
InProgress → Failed

Bei Clustern im automatischen Modus bleibt der Clusterstatus ACTIVE während des Rollbacks der Knoten bestehen und ändert sich UPDATING erst, wenn das Rollback der Steuerungsebene beginnt. Wird verwendetdescribe-update, um den gesamten Rollback-Fortschritt 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 und zum richtigen Zeitpunkt erstellt

Cluster-Erkenntnisse werden zu dem Zeitpunkt ausgewertet, zu dem ein Rollback ausgelöst wird. Wenn Sie nach der Überprüfung der Erkenntnisse, aber vor Abschluss des Rollbacks Änderungen an Ihrem Cluster vornehmen (z. B. beim Erstellen von Ressourcen mithilfe neuer APIs), werden diese Änderungen bei der ersten Prüfung der Erkenntnisse nicht erfasst und können nach Abschluss des Rollbacks zu Problemen führen.

etcd Datenerhaltung

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

Gebühren für erweiterten Support

Wenn Sie von einer Version mit Standard-Support zu einer Version mit erweitertem Support zurückkehren, fallen für Ihren Cluster zusätzliche Support-Gebühren an. Wenn Sie beispielsweise ein Upgrade von 1.30 (erweiterter Support) auf 1.31 (Standardsupport) durchführen und dann auf 1.30 zurückkehren, fallen die Gebühren für den erweiterten Support weiter an.

Modell der geteilten Verantwortung für Rollback

EKS setzt die Kubernetes-Steuerebene 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 Stack-Update fehlschlägt und ein Stack-Rollback auslöst, löst die Rückkehr zu einer früheren Vorlagenversion, die eine niedrigere Kubernetes-Version angibt, kein Rollback der Cluster-Version aus. Das Versions-Rollback muss explizit über die UpdateClusterVersion API, CLI oder Konsole initiiert werden.

Rollback und Add-Ons

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

Bevor Sie die Steuerungsebene zurücksetzen:

aws eks update-addon \
  --cluster-name my-cluster \
  --addon-name vpc-cni \
  --addon-version v1.12.0-eksbuild.2 \
  --region us-west-2

+. Stellen Sie nach Abschluss des Rollbacks der Steuerungsebene sicher, dass alle Add-Ons ordnungsgemäß funktionieren.

Zugehörige Ressourcen