EKS Version Rollback: Kubernetes-Upgrades auf AWS endlich rückgängig machen

Wer einen Amazon-EKS-Cluster auf eine neue Kubernetes-Version aktualisiert hat, kannte bisher nur eine Richtung: vorwärts. Lief nach dem Upgrade ein Admission-Webhook nicht mehr, reagierte ein Controller auf die neue API anders als erwartet oder brach ein Add-on unter dem neuen kubelet zusammen, blieb als Ausweg entweder ein Support-Ticket oder der Neuaufbau des Clusters mit anschließender Workload-Migration. Seit dem 1. Juli 2026 gibt es eine dritte Option: den EKS Version Rollback. Innerhalb von sieben Tagen nach einem In-Place-Upgrade kann die Control Plane auf die vorherige Minor-Version zurückgesetzt werden – ohne Aufpreis, ohne Cluster-Neuaufbau.

Dieser Artikel erklärt, was das Feature genau tut, wo seine Grenzen liegen und was es für eine sinnvolle Upgrade-Strategie bedeutet.

Was der EKS Version Rollback zurücksetzt – und was nicht

Der Rollback bewegt die von AWS verwaltete Control Plane von Version N zurück auf N-1. Laut AWS-Dokumentation werden dabei zurückgesetzt:

• Die Kubernetes-API-Server-Version
• Control-Plane-Komponenten und deren Konfiguration
• Die Platform-Version (auf die aktuellste Platform-Version der vorherigen Kubernetes-Version)

Ausdrücklich nicht zurückgesetzt werden:

• EKS-Add-ons – deren Versionen bleiben unverändert und müssen separat verwaltet werden
• Managed Node Groups – diese müssen vor dem Control-Plane-Rollback manuell auf N-1 zurückgesetzt werden
• Self-managed Nodes und Hybrid Nodes – liegen vollständig in der Verantwortung des Betreibers
• Fargate-Pods – für Fargate-Worker-Nodes wird kein automatisches Rollback unterstützt (dazu mehr im nächsten Abschnitt)
• Persistent Volumes und etcd-Daten – alle Workload-Daten bleiben erhalten

Das Shared-Responsibility-Modell gilt also auch hier: AWS übernimmt die Control Plane, der Betreiber ist für die Datenebene, Add-ons und Anwendungskompatibilität verantwortlich. Wer das vor dem ersten Rollback-Versuch nicht eingeplant hat, erlebt eine unangenehme Überraschung.

Wie der Rollback-Prozess abläuft

Bevor der eigentliche Rollback startet, prüft EKS automatisch die Rollback Readiness Insights – eine Reihe automatisierter Checks, die API-Kompatibilität, Version-Skew zwischen Control Plane und Nodes, Add-on-Kompatibilität und den allgemeinen Cluster-Zustand bewerten. Wer die Checks kennt und die Situation bereits eingeschätzt hat, kann sie mit dem Flag --force überspringen.

Der Rollback-Befehl selbst ist identisch mit dem Upgrade-Befehl – nur mit der vorherigen Version als Ziel:

aws eks update-cluster-version \
  --name my-cluster \
  --kubernetes-version 1.34 \
  --region eu-central-1

Alternativ steht der EKS-Console-Workflow zur Verfügung: Cluster auswählen → Tab „Update history" → Rollback initiieren.

EKS Auto Mode: vollständig automatisierter Node-Rollback

Für Cluster, die im EKS Auto Mode betrieben werden, geht der Rollback einen Schritt weiter. EKS koordiniert dabei zuerst den Rollback der Worker-Nodes – gesteuert durch Karpenter und unter Berücksichtigung konfigurierter Pod-Disruption-Budgets – bevor die Control Plane zurückgesetzt wird. Der Cluster bleibt während des gesamten Prozesses im Status ACTIVE und bedient weiterhin Traffic. Laut AWS-Ankündigung vom 1. Juli 2026 dauerte der Control-Plane-Rollback in einem Demo-Cluster etwa 20 Minuten – vergleichbar mit einem normalen Upgrade. Wie lange der Prozess in der Praxis dauert, hängt von der Cluster-Größe und den konfigurierten Disruption-Budgets ab.

Managed Node Groups: manueller Schritt zuerst

Bei Clustern mit Managed Node Groups muss der Betreiber die Node Groups vor dem Control-Plane-Rollback auf die Zielversion zurücksetzen. Der Grund: Kubernetes erlaubt keine Worker-Nodes, die eine neuere Version als die Control Plane führen. Der entsprechende Befehl:

aws eks update-nodegroup-version \
  --cluster-name my-cluster \
  --nodegroup-name my-nodegroup \
  --kubernetes-version 1.34 \
  --region eu-central-1

Das Node-Group-Update respektiert die konfigurierten Update-Einstellungen (maxUnavailable, Update-Strategie).

Die Grenzen, die man kennen muss

Der EKS Version Rollback ist ein nützliches Sicherheitsnetz – aber kein universelles Undo. Wer die folgenden Einschränkungen nicht kennt, riskiert, das Fenster zu verpassen oder in eine Situation zu geraten, in der der Rollback schlicht nicht möglich ist.

7-Tage-Fenster, hart begrenzt. Das Rollback-Fenster beginnt mit dem Abschluss des Upgrades und endet nach sieben Tagen. Danach ist kein Rollback mehr möglich – weder mit noch ohne --force. Wer ein Upgrade am Freitagabend einspielt und erst am übernächsten Montag ein Problem bemerkt, hat möglicherweise noch Zeit. Wer zwei Wochen wartet, nicht mehr.

Nur eine Minor-Version zurück (N→N-1). Multi-Version-Rollbacks werden nicht unterstützt. Wer von 1.33 auf 1.34 und dann auf 1.35 aktualisiert hat, kann nur auf 1.34 zurück, nicht auf 1.33. Außerdem muss der Cluster durch ein In-Place-Upgrade auf die aktuelle Version gekommen sein – ein Cluster, der von Anfang an auf Version N erstellt wurde, hat keinen Rollback-Pfad.

Kein Rollback nach automatischem Upgrade am Ende des Extended Support. Wenn AWS einen Cluster am Ende des Extended-Support-Zeitraums automatisch aktualisiert, ist kein Rollback möglich. Wer hingegen am Ende des Standard-Supports automatisch aktualisiert wurde, kann zurückrollen – muss aber vorher die Upgrade-Policy auf EXTENDED setzen.

Fargate: kein automatisches Node-Rollback. EKS kann Fargate-Pods nicht automatisch auf eine ältere kubelet-Version zurücksetzen. Laufen Fargate-Pods auf derselben Version wie die Control Plane, löst das nach dem Rollback einen ERROR-Status im kubelet-Version-Skew-Insight aus. Der empfohlene Workaround laut AWS-Dokumentation: betroffene Pods vor dem Control-Plane-Rollback löschen, damit sie nach dem Rollback mit der zurückgesetzten Version neu starten.

IaC-Timeouts. Wer EKS-Cluster über Terraform oder CloudFormation verwaltet, sollte wissen, dass diese Tools eigene Client-seitige Timeouts haben, die kürzer sein können als das 7-Tage-Rollback-Fenster. Ein Rollback-Vorgang, der länger als das Tool-Timeout dauert, kann zu inkonsistenten IaC-Zuständen führen. Das ist kein Showstopper, aber ein Punkt, den man vor dem ersten Rollback in der Produktion durchdenken sollte.

EKS-Features, die nur auf der neuen Version verfügbar sind. Hat man nach dem Upgrade ein Feature aktiviert, das auf der vorherigen Version nicht unterstützt wird, schlägt der Rollback fehl – und dieser Check lässt sich auch mit --force nicht umgehen.

Was das für Ihre Upgrade-Strategie bedeutet

Der EKS Version Rollback verändert die Risikorechnung bei Kubernetes-Upgrades – aber er ersetzt keine sorgfältige Vorbereitung. AWS selbst formuliert es in den Best Practices klar: „Rollback complements testing, it does not replace it."

Konkret ergeben sich drei Konsequenzen für den Betrieb:

Blue/Green-Cluster als reinen Rollback-Mechanismus überdenken. Wer bisher parallele Cluster hauptsächlich deshalb betrieben hat, um im Notfall auf die alte Version zurückwechseln zu können, kann diesen Ansatz für In-Place-Upgrades neu bewerten. Ein In-Place-Upgrade mit Rollback-Option kostet weniger Infrastruktur, behält denselben API-Endpunkt und OIDC-Provider und ist operativ einfacher – sofern die Einschränkungen des Rollback-Fensters akzeptabel sind.

Früher upgraden, statt Extended Support zu zahlen. Extended Support kostet laut AWS-Preisseite $0,60 pro Cluster und Stunde statt $0,10 im Standard-Support. Die Differenz von $0,50 pro Stunde summiert sich bei einem Cluster, der rund um die Uhr läuft, auf über $4.000 pro Jahr – und das pro Cluster, unabhängig von der Node-Anzahl. Das Rollback-Feature nimmt einen der häufigsten Gründe für verzögerte Upgrades weg: die Angst, nach dem Upgrade nicht mehr zurückzukönnen. Wer früher upgradet, bleibt im Standard-Support und spart die Mehrkosten.

Rollback als Sicherheitsnetz einplanen, nicht als Routine. Das 7-Tage-Fenster ist für Probleme gedacht, die erst unter Produktionslast sichtbar werden – ein inkompatibler Webhook, ein Controller, der eine deprecated API noch aufruft, ein Node-Treiber, der gegen das neue kubelet bricht. Es ist kein Ersatz für Pre-Upgrade-Tests in einer Nicht-Produktionsumgebung und kein Backup-Mechanismus für Workload-Daten.

Was Sie jetzt tun sollten

Wenn Sie EKS-Cluster betreiben, sind drei Schritte sinnvoll:

Prüfen Sie zunächst, welche Ihrer Cluster noch auf Versionen laufen, die sich im Extended Support befinden oder kurz davor stehen. Der Rollback macht das Upgrade-Risiko beherrschbarer – aber er ändert nichts daran, dass ein Upgrade auf eine Standard-Support-Version die günstigere Option ist.

Testen Sie den Rollback-Prozess in einer Nicht-Produktionsumgebung, bevor Sie ihn in der Produktion brauchen. Das schließt den Node-Group-Rollback, die Add-on-Kompatibilitätsprüfung und – falls Sie Fargate nutzen – den Pod-Lösch-Workaround ein. Ein Rollback, den man noch nie durchgeführt hat, ist kein Sicherheitsnetz.

Passen Sie Ihre Upgrade-Playbooks an: Das 7-Tage-Fenster sollte explizit als Bake-Period eingeplant sein, in der Monitoring-Dashboards, Admission-Webhooks und kritische Controller aktiv beobachtet werden. Wer das Fenster ungenutzt verstreichen lässt, hat den Vorteil des Features nicht genutzt.

Wie Sie Ihre EKS-Cluster systematisch auf dem aktuellen Stand halten und dabei Breaking Changes sicher navigieren, beschreibt unser Artikel Kubernetes v1.37 „Garhwal": Was EKS-Betreiber vor dem nächsten Upgrade wissen müssen. Wer den Ingress-NGINX-Abkündigungspfad noch vor sich hat, findet in unserem Beitrag zur Ingress-NGINX-Migration auf EKS und der Kubernetes Gateway API eine strukturierte Anleitung.