Kubernetes 1.37 bei EKS, AKS und GKE: Upgrade-Fristen und Support-Kosten 2026

Kubernetes 1.37 „Garhwal" ist upstream seit dem 26. August 2026 verfügbar — doch für die meisten Teams zählt weniger das Release-Datum als der Moment, in dem der eigene Managed-Anbieter die Version produktiv ausrollt. Dieser Moment ist im Oktober 2026 gekommen: Amazon hat 1.37 auf EKS freigegeben, Microsoft zieht mit AKS nach, Google hält sich vorerst mit dem Rapid Channel zurück. Gleichzeitig läuft eine deutlich dringlichere Frist ab: Das Ende des Standard-Supports für Kubernetes 1.34 — wer dann nicht upgradet, zahlt bei EKS den sechsfachen Cluster-Preis.

EKS, AKS, GKE: Der Stand bei Kubernetes 1.37

AWS hat Kubernetes 1.37 Anfang Oktober 2026 für Amazon EKS und EKS Distro freigegeben — in allen Regionen, in denen EKS verfügbar ist, einschließlich der GovCloud-Regionen und Frankfurt. Neue Cluster lassen sich direkt mit 1.37 anlegen, bestehende über Konsole, eksctl oder Infrastructure-as-Code aktualisieren. Drei Neuerungen hebt AWS in der Ankündigung hervor: Die Metrics API ist mit metrics.k8s.io/v1 in General Availability übergegangen, Dynamic Resource Allocation (DRA) kann Geräte wie GPUs per Taints und Tolerations belegen, und der Horizontal Pod Autoscaler skaliert mit minReplicas: 0 bei Objekt- oder External-Metriken bei Bedarf auf null Pods (Beta, standardmäßig aktiv).

Microsoft zieht dicht auf: Bei AKS ist 1.37 seit September in der Preview, die GA ist laut Versionskalender für Oktober 2026 vorgesehen. Google hält sich zurück: Laut GKE-Release-Notes steht 1.37 Anfang Oktober nur im Rapid Channel bereit. Damit ist EKS bei der breiten Nutzung der neuen Minor-Version der erste der großen Drei.

Die dringlichere Frist: Ende des Standard-Supports für 1.34

Der wichtigere Termin für viele Cluster-Betreiber ist nicht das 1.37-Upgrade, sondern der Support-Ablauf von 1.34. Auf EKS endet der Standard-Support am 2. Dezember 2026. Danach wechselt der Cluster automatisch in den Extended Support, der standardmäßig aktiv ist. Statt 0,10 USD kostet der Cluster dann 0,60 USD pro Stunde; bei 730 Stunden im Monat sind das rechnerisch gut 365 USD Mehrkosten pro Cluster. Bei AKS endet 1.34 ebenfalls im November 2026; mit aktiviertem Long-Term Support (LTS) bleibt die Version dort bis November 2027 nutzbar.

Die Versionspolitiken der Anbieter unterscheiden sich dabei deutlich. EKS garantiert 14 Monate Standard-Support pro Minor-Version und danach 12 weitere Monate Extended Support — aktuell vier Versionen im Standard (1.34 bis 1.37), drei im Extended Support. AKS folgt einer Zwölf-Monats-Politik für GA-Versionen, mit optionalem LTS als Verlängerung um ein Jahr. Wer mehrere Clouds parallel betreibt, sollte diese Kalender von Anfang an in die Upgrade-Planung einrechnen — sie sind inzwischen genauso wichtig wie die Feature-Entscheidungen des Upstream-Projekts.

Upgrade-Praxis: SELinux, Version-Skew und Rollback

Beim Sprung auf 1.37 gibt es aus Betriebssicht drei Dinge zu beachten. Erstens die SELinux-Änderung: Pods, die sich ein Volume mit unterschiedlichen Labels teilen, können nach dem Upgrade in ContainerCreating hängen bleiben; Nodes ohne SELinux sind nicht betroffen. 1.37 sollte daher vor dem Produktiv-Rollout in einer Nicht-Produktionsumgebung getestet werden, idealerweise mit Blick auf SELinux-fähige Nodes. Zweitens der Version-Skew: Die Kubernetes-Policy erlaubt bis zu drei Minor-Versionen Differenz zwischen Control Plane und Nodes, empfohlen ist aber der identische Stand — Node-Gruppen werden bei EKS nicht automatisch mit dem Control Plane aktualisiert und müssen separat gehoben werden. Drittens der Rollback: Ein In-Place-Upgrade lässt sich bei EKS innerhalb von sieben Tagen auf die vorherige Minor-Version zurücknehmen; nach dem automatischen Upgrade am Ende des Extended Support ist das nicht mehr möglich.

Upstream ist 1.37 mit 67 Enhancements eines der umfangreichsten Releases der jüngeren Zeit. Wer eine Version über das Support-Ende hinaus betreibt, sollte sich bewusst sein, dass die Community nach etwa einem Jahr keine CVE-Patches mehr veröffentlicht — ungepatchte Control Planes sind dann ein Sicherheitsrisiko ohne offizielle Remediation. Genau deshalb aktualisieren die Anbieter am Ende des Extended Support automatisch, ohne vorherige Benachrichtigung.

Fazit

Der Oktober 2026 zeigt, wie stark Managed Kubernetes inzwischen von Versionspolitik geprägt ist: EKS und AKS rollen 1.37 aus, GKE folgt über den Rapid Channel — und parallel läuft die Uhr für 1.34. Für Teams heißt das: den Upgrade-Kalender des eigenen Anbieters als Betriebsdisziplin ernst nehmen, einen Minor-Sprung pro Upgrade einplanen und Extended Support nur als teuren Aufschub, nicht als Dauerzustand betrachten. Die nächste Runde kommt planmäßig — das Kubernetes-Projekt veröffentlicht im Schnitt alle vier Monate eine neue Minor-Version, 1.38 ist daher für Dezember 2026 zu erwarten.

Quellen

• Amazon EKS and Amazon EKS Distro now support Kubernetes version 1.37 (AWS, Oktober 2026)
• Understand the Kubernetes version lifecycle on EKS (Amazon EKS User Guide)
• Supported Kubernetes versions in Azure Kubernetes Service (AKS) (Microsoft Learn)
• Kubernetes v1.37: Garhwal (kubernetes.io Blog, 26.08.2026)
• EKS Kubernetes 1.37: Support bis Dezember 2028 (kubernetes-anbieter.de, Oktober 2026)