Sieben Tage Sicherheitsnetz: Was EKS-Rollbacks leisten – und was nicht
TL;DR: Amazon EKS kann Kubernetes-Upgrades nun sieben Tage lang zurückrollen, doch Anwendungen, Daten, Add-ons und viele Worker Nodes bleiben in der Verantwortung des Betreibers.
Amazon hat seinem verwalteten Kubernetes-Dienst EKS eine Funktion spendiert, auf die viele Betriebsteams lange gewartet haben: Nach einem Upgrade lässt sich die Control Plane wieder auf die vorherige Kubernetes-Version zurücksetzen. Das macht einen bislang weitgehend gerichteten Vorgang erstmals begrenzt reversibel.
Für Unternehmen ist das eine relevante Verbesserung. Sie beseitigt aber nicht die Risiken eines Kubernetes-Upgrades – und sie macht einen Managed Service auch nicht automatisch zur besten Betriebsform.
Was AWS jetzt zurückrollen kann
Seit dem 1. Juli 2026 unterstützt Amazon EKS den Rollback auf die vorherige Kubernetes-Minor-Version. Wer beispielsweise von Version 1.35 auf 1.36 aktualisiert hat, kann innerhalb von sieben Tagen wieder auf 1.35 wechseln. Die Funktion ist laut AWS ohne Aufpreis in allen Regionen verfügbar, in denen EKS angeboten wird. AWS beschreibt die Neuerung als zusätzliches Sicherheitsnetz für Upgrades.
Vor dem eigentlichen Rollback untersucht EKS den Cluster. Die sogenannten Rollback Readiness Insights prüfen unter anderem verwendete APIs, Versionsabweichungen zwischen Komponenten, Add-on-Kompatibilität und den Zustand des Clusters. Fehler können den Vorgang blockieren; Warnungen lassen ihn weiterhin zu.
Zurückgesetzt werden der Kubernetes API Server, die Komponenten und Konfiguration der Control Plane sowie die EKS-Plattformversion. Bei EKS Auto Mode bezieht AWS auch die automatisch verwalteten Worker Nodes in den Ablauf ein und berücksichtigt dabei definierte Unterbrechungsbudgets für Anwendungen.
Das ist technisch anspruchsvoll und operativ hilfreich. Gerade Probleme mit veralteten APIs, Admission Webhooks, Controllern oder Versionsunterschieden werden manchmal erst unter realer Last sichtbar. Ein funktionierender Rückweg kann dann die Zeit bis zur Stabilisierung deutlich verkürzen.
Das Rollback hat klare Grenzen
Der Begriff „Rollback“ klingt umfassender, als die Funktion tatsächlich ist. EKS setzt in erster Linie die Control Plane zurück. Der komplette Zustand des Systems reist nicht automatisch sieben Tage in die Vergangenheit.
Die in etcd gespeicherten Cluster-Daten bleiben erhalten. Das gilt ebenso für laufende Workloads, Deployments, Services, Konfigurationen und persistente Volumes. Auch EKS-Add-ons verbleiben zunächst auf ihrer aktuellen Version. Selbst verwaltete Nodes, Hybrid Nodes und Managed Node Groups müssen Betreiber separat behandeln. Die EKS-Dokumentation grenzt genau ab, welche Komponenten zurückgesetzt werden.
Das ist grundsätzlich sinnvoll: Ein pauschales Zurückdrehen aller Anwendungs- und Nutzdaten wäre in einem produktiven System kaum beherrschbar. Es bedeutet aber auch, dass nach dem Rollback weiterhin Ressourcen vorhanden sein können, die erst mit der neueren Kubernetes-Version eingeführt oder verändert wurden.
Besonders vorsichtig sollten Teams mit der --force-Option umgehen. Sie kann bestimmte Erkenntnisse aus den Readiness Checks übergehen, beseitigt aber keine Inkompatibilität. AWS weist ausdrücklich darauf hin, dass die Sicherheit des Vorgangs in diesem Fall nicht garantiert werden kann.
Hinzu kommen formale Grenzen: Der Rollback ist nur auf die unmittelbar vorherige Minor-Version möglich, nur innerhalb von sieben Tagen und nur, wenn die Zielversion weiterhin von EKS unterstützt wird. Wurde der Cluster direkt mit der aktuellen Version erstellt oder bereits erneut aktualisiert, steht der Rückweg nicht zur Verfügung. Ein fehlgeschlagenes CloudFormation-Update löst ebenfalls nicht automatisch einen Kubernetes-Rollback aus.
Warum ein Rollback kein Backup ist
Ein Rollback beantwortet die Frage: „Wie bekommen wir die ältere Kubernetes Control Plane zurück?“ Ein Backup beantwortet eine andere: „Wie stellen wir verlorene oder beschädigte Zustände und Daten wieder her?“
Wenn ein Upgrade mit einer fehlerhaften Datenbankmigration, einer inkompatiblen Custom Resource Definition oder einer falschen Anwendungskonfiguration zusammenfällt, hilft das Zurücksetzen der Control Plane allein möglicherweise nicht. Persistent Volumes werden ausdrücklich nicht auf einen früheren Stand gebracht. Auch ein versehentlich gelöschtes Objekt kehrt dadurch nicht zurück.
Deshalb bleiben getestete etcd-Sicherungen, anwendungskonsistente Datenbank-Backups und dokumentierte Wiederherstellungsverfahren unverzichtbar. Entscheidend ist nicht nur, dass ein Backup existiert, sondern dass seine Wiederherstellung regelmäßig überprüft wird.
Dasselbe gilt für Upgrade-Tests. Ein Staging-Cluster, Kompatibilitätsprüfungen, Beobachtung veralteter APIs und ein kontrollierter Rollout reduzieren die Wahrscheinlichkeit, dass ein Rollback überhaupt notwendig wird. Das neue EKS-Feature ist die letzte Sicherungslinie, nicht der Anfang des Upgrade-Konzepts.
Sieben Tage sind ein Sicherheitsfenster, keine Teststrategie
AWS begründet das Zeitfenster damit, dass eine neue Version unter realen Produktionsbedingungen validiert werden kann. Das ist nachvollziehbar, sollte aber nicht als Einladung verstanden werden, Tests in die Produktion zu verlagern.
Manche Fehler zeigen sich sofort: Pods starten nicht, ein Controller fällt aus oder ein Admission Webhook blockiert neue Deployments. Andere Probleme treten nur in seltenen Prozessen, bei hoher Last oder nach mehreren Tagen auf. Ein sieben Tage lang möglicher Rückweg hilft nur, wenn das Team die entscheidenden Signale rechtzeitig beobachtet.
Für das Upgrade-Fenster braucht es daher konkretes Monitoring: Fehlerraten, Latenzen, Pod-Neustarts, ausstehende Workloads, Cluster-Events, API-Fehler und die Funktion geschäftskritischer Abläufe. Ebenso wichtig sind klar definierte Abbruchkriterien. Ohne sie wird aus einem Sicherheitsfenster schnell eine Diskussion darüber, ob die beobachteten Auffälligkeiten „schon schlimm genug“ für einen Rollback sind.
Der Erfolg eines Upgrades sollte deshalb nicht allein am Status Successful in der AWS-Konsole gemessen werden. Er ist erst erreicht, wenn Plattform und Anwendungen über einen festgelegten Zeitraum stabil arbeiten.
Managed EKS oder selbst betriebenes Kubernetes?
Die neue Funktion stärkt ein zentrales Argument für Managed Kubernetes: Der Cloudanbieter übernimmt komplexe Arbeiten an der Control Plane und stellt standardisierte Sicherheitsmechanismen bereit. Für Teams mit begrenzter Plattformkapazität kann das einen erheblichen betrieblichen Vorteil darstellen.
Es ist jedoch nicht die einzige sinnvolle Option. Kubernetes lässt sich auch auf eigener Infrastruktur oder auf Cloud-Servern anderer Anbieter betreiben, beispielsweise bei Hetzner. Hetzner stellt dafür unter anderem einen offiziellen Cloud Controller Manager zur Integration eines Kubernetes-Clusters mit den Cloud- und Robot-APIs bereit.
In einem selbst betriebenen Cluster liegen Upgrade, Control Plane, etcd, Worker Nodes, Netzwerk und Wiederherstellung vollständig beim verantwortlichen Team. Das erhöht die operative Verantwortung, schafft aber auch mehr Kontrolle über Architektur, Standort, Automatisierung, Kostenmodell und Anbieterabhängigkeit.
Ein vergleichbarer Ein-Klick-Rollback gehört dabei nicht automatisch zum Lieferumfang. Die Kubernetes-Dokumentation beschreibt für mit kubeadm betriebene Cluster einen kontrollierten Upgradepfad und eine feste Reihenfolge der Komponenten. Sie empfiehlt aktuelle Patchstände und begrenzt die erlaubten Versionsunterschiede zwischen API Server, Kubelet und weiteren Komponenten. Die offizielle Version-Skew-Policy zeigt, wie eng diese Abhängigkeiten geregelt sind.
Die eigentliche Entscheidung lautet deshalb nicht „AWS oder Kubernetes“. EKS ist selbst Kubernetes. Entscheidend ist, welches Betriebsmodell zu den eigenen Anforderungen, Fähigkeiten und Verantwortlichkeiten passt.
Die Rückfallstrategie beginnt vor dem Upgrade
Unabhängig von der Plattform sollten Verantwortliche vor einem Versionswechsel fünf Fragen beantworten können: Welche Komponenten verändern wir? Welche davon lassen sich separat zurücksetzen? Welche Daten bleiben erhalten? Woran erkennen wir einen Fehler? Und wer entscheidet über den Abbruch?
Bei EKS kommt nun eine weitere Frage hinzu: Sind Nodes und Add-ons mit der alten Version kompatibel, falls die Control Plane zurückgesetzt werden muss? AWS empfiehlt, betroffene Worker Nodes gegebenenfalls vor der Control Plane zurückzurollen. Das zeigt, dass selbst die verwaltete Variante weiterhin abgestimmte Handarbeit erfordern kann.
Für kritische Plattformen können zusätzlich parallele Cluster sinnvoll sein. Bei einem Blue-Green-Ansatz wird die neue Version getrennt aufgebaut und der Verkehr erst nach erfolgreicher Prüfung umgeschaltet. Dieses Verfahren benötigt mehr Ressourcen, bietet dafür aber eine stärkere Trennung als ein In-Place-Upgrade.
Welche Kombination angemessen ist, hängt von Ausfallkosten, Datenhaltung, Compliance, Teamgröße und Änderungsfrequenz ab. Ein pauschales Rezept gibt es nicht.
Kontext
Kubernetes veröffentlicht regelmäßig neue Minor-Versionen und unterstützt jeweils nur einen begrenzten Versionsbereich; dadurch gehören Upgrades dauerhaft zum Plattformbetrieb. Cloudanbieter versuchen, diesen wiederkehrenden Aufwand durch verwaltete Control Planes, Kompatibilitätsprüfungen und Automatisierung zu reduzieren, während selbst betriebene Cluster mehr Freiheit und Verantwortung beim Aufbau eigener Upgrade- und Wiederherstellungsverfahren bieten.
Worauf Unternehmen jetzt achten sollten
Für bestehende EKS-Cluster sollte die neue Funktion in Runbooks und Notfallabläufe aufgenommen werden. Teams sollten aber nicht nur dokumentieren, wie der API-Aufruf funktioniert, sondern auch, welche Nodes, Add-ons und Anwendungen separat behandelt werden müssen. Besonders wichtig ist ein realistischer Test des gesamten Ablaufs vor dem nächsten kritischen Versionswechsel.
Unternehmen, die ihre Kubernetes-Strategie neu bewerten, sollten das Feature als einen Faktor unter mehreren betrachten. EKS bietet einen komfortableren Rückweg für die Control Plane. Ein selbst betriebenes Kubernetes, etwa auf Hetzner, kann dennoch die passendere Lösung sein, wenn Kontrolle, Infrastrukturstandort oder ein unabhängigeres Betriebsmodell höher gewichtet werden.
ScalerIT unterstützt Unternehmen dabei, diese Entscheidung nicht anhand einzelner Produktfunktionen zu treffen. Von Architektur und Automatisierung über sichere Upgrades bis zu Monitoring, Backups und Wiederherstellungsplänen sollte die Plattform als zusammenhängendes Betriebssystem betrachtet werden. Wer prüfen möchte, ob Managed Kubernetes oder ein selbst betriebener Cluster besser zur eigenen Organisation passt, kann eine Kubernetes-Beratung bei ScalerIT anfragen.