Am 26. August 2026 hat das Kubernetes-Projekt Version 1.37 veröffentlicht, Codename „Garhwal" nach einer Himalaya-Region in Uttarakhand, Indien. Das Release enthält 67 Enhancements: 16 graduieren zu Stable, 23 zu Beta, 27 sind neu in Alpha, und eine Funktion wird entfernt. Kein einzelnes Feature dominiert das Release – stattdessen zahlt das Projekt Beta-Schulden zurück, macht den API-Server bei großen Clustern spürbar schneller und bringt GPU-Scheduling einen entscheidenden Schritt weiter. Gleichzeitig enthält 1.37 drei Breaking Changes, die ohne Vorbereitung aus einem geplanten Upgrade-Fenster einen Incident machen können.
Dieser Artikel fasst zusammen, was für Teams relevant ist, die EKS betreiben oder einen Upgrade-Plan für die nächsten Monate aufstellen.
Zwei Änderungen am API-Server sind in v1.37 standardmäßig aktiv und wirken sich direkt auf das Startverhalten großer Cluster aus.
ConcurrentWatchObjectDecode war seit v1.31 als Beta-Feature vorhanden, aber standardmäßig deaktiviert. In v1.37 wird es eingeschaltet. Das Feature verlagert den Decode- und Transform-Schritt beim Aufbau des Watch-Caches auf einen Pool von Worker-Goroutinen (standardmäßig 10) statt ihn sequenziell abzuarbeiten. Laut dem offiziellen Release-Blog reduziert das allein die Cache-Initialisierung in Benchmarks über 150.000 Pods um rund 40 Prozent – kombiniert mit EtcdRangeStream sogar um rund 55 Prozent.
Der Caveat: Wer Conversion Webhooks betreibt, die ihre eigene Parallelität auf unter 10 begrenzen, sollte das vor dem Upgrade prüfen. Die Gesamtzahl der Webhook-Aufrufe bleibt gleich, aber bis zu 10 können jetzt gleichzeitig während der Cache-Initialisierung ankommen statt nacheinander.
EtcdRangeStream (Feature Gate EtcdRangeStream) ist Beta und in v1.37 standardmäßig aktiv. Statt eine vollständige Collection aus etcd in einem Stück zu lesen und im Speicher zu halten, streamt der API-Server die Daten in Chunks – snapshot-konsistent, aber ohne den gesamten Datensatz gleichzeitig im RAM zu halten. Voraussetzung ist etcd v3.7 oder neuer; mit älteren etcd-Versionen fällt der API-Server automatisch auf den bisherigen paginierten Range-Pfad zurück.
Dynamic Resource Allocation (DRA) ist seit v1.34 stabil. In v1.37 erreicht ein wichtiges Teilfeature GA: DRA Extended Resource Support. Es erlaubt einem DRA-Treiber, Anfragen zu bedienen, die über die klassische Extended-Resource-Syntax gestellt werden – also nvidia.com/gpu: 1 im Pod-Spec, ohne dass ein separates ResourceClaim im Workload-Manifest nötig ist.
Praktisch bedeutet das: Ein Cluster-Administrator weist einer DeviceClass einen Extended-Resource-Namen zu. Bestehende Workloads, die Geräte über resources.requests anfordern, funktionieren weiterhin unverändert, während die Allokation im Hintergrund über DRA läuft. Das ist der dokumentierte Migrationspfad weg von Device Plugins – ohne Rewrite der Workload-Manifeste.
Ebenfalls in v1.37 stabil: Device Taints und Tolerations. Treiber oder Administratoren können ein einzelnes Gerät – etwa eine GPU mit ECC-Fehlern – als tainted markieren, sodass der Scheduler es aus dem Pool nimmt, ohne den Node drainieren zu müssen. Für Teams, die GPU-Nodes betreiben, ist das ein erheblicher operativer Gewinn.
Die folgenden drei Punkte sind keine optionalen Features – sie können nach einem Upgrade zu Ausfällen führen, wenn sie nicht vorher adressiert werden.
1. SELinuxMount ist jetzt GA und standardmäßig aktiv. Volumes werden auf SELinux-aktivierten Clustern jetzt mit -o context=<label> gemountet statt rekursiv relabelt – aber nur, wenn der CSI-Treiber über .spec.seLinuxMount: true im CSIDriver-Objekt opt-in ist. Ein Mount kann nur einen SELinux-Kontext tragen. Pods mit unterschiedlichen SELinux-Labels, die sich auf demselben Node ein Volume teilen, können nach dem Upgrade im Zustand ContainerCreating hängen bleiben. Wer das alte Verhalten für einzelne Workloads behalten möchte, setzt seLinuxChangePolicy: Recursive im Pod-Spec. Cluster ohne SELinux sind nicht betroffen.
2. kube-proxy IPVS-Modus ist formal deprecated. Seit v1.35 gab es Warnzeichen; in v1.37 loggt kube-proxy beim Start eine Deprecation-Warnung, wenn IPVS konfiguriert ist. Der Zeitplan laut Release-Blog: In v1.40 wird IPVS standardmäßig deaktiviert, in v1.43 vollständig entfernt. Der empfohlene Nachfolger ist der nftables-Modus (ab Linux-Kernel 5.13+). Den aktuellen Modus prüfen:
kubectl -n kube-system get configmap kube-proxy \
-o jsonpath='{.data.config\.conf}' | grep 'mode:'3. Static Pods dürfen keine Secrets oder ConfigMaps mehr referenzieren. Die Lücke, die das bisher erlaubte, ist in v1.37 geschlossen. Das Feature Gate PreventStaticPodAPIReferences, mit dem man das Verhalten opt-out konnte, ist entfernt. Wer Static Pod-Manifeste in /etc/kubernetes/manifests hat, die configMapRef oder secretRef verwenden, muss diese vor dem Upgrade anpassen.
Amazon EKS unterstützt zum Zeitpunkt dieser Veröffentlichung Kubernetes 1.36 als neueste verfügbare Version (EKS-Release-Datum: 2. Juni 2026). Bis EKS 1.37 verfügbar ist, bleibt Zeit für Vorbereitung – aber die Breaking Changes oben gelten auch für den Upgrade-Pfad von 1.36 auf 1.37, sobald dieser freigegeben wird.
Relevant für die Upgrade-Planung ist das im Juli 2026 allgemein verfügbar gewordene EKS Version Rollback. Laut AWS haben Cluster-Administratoren nach einem Versions-Upgrade sieben Tage Zeit, auf die vorherige Minor-Version zurückzurollen. Bei EKS Auto Mode übernimmt AWS auch das Rollback der Worker Nodes; bei Managed Node Groups muss das Rollback der Nodes manuell über die UpdateNodegroupVersion-API angestoßen werden, bevor die Control Plane zurückgerollt wird. Fargate-Nodes werden beim Rollback nicht unterstützt.
Ein weiterer Faktor ist das Versions-Support-Modell. EKS berechnet $0,10 pro Cluster-Stunde im Standard-Support und $0,60 pro Cluster-Stunde im Extended Support – also das Sechsfache. Kubernetes 1.33 ist seit dem 29. Juli 2026 im Extended Support; wer noch auf dieser Version läuft, zahlt bereits den höheren Tarif. Das ist ein konkreter finanzieller Grund, Upgrade-Zyklen nicht zu verschleppen.
Bevor EKS 1.37 verfügbar wird, sind vier Schritte sinnvoll:
/etc/kubernetes/manifests nach configMapRef und secretRef. Auf EKS-Clustern ist das selten, aber bei selbstverwalteten Nodes oder Bootstrapping-Setups kann es vorkommen.Das EKS Version Rollback-Feature gibt Ihnen ein Sicherheitsnetz für sieben Tage nach dem Upgrade. Es ersetzt aber keine Vorbereitung: Wer die Breaking Changes erst nach dem Upgrade entdeckt, verliert wertvolle Zeit aus dem Rollback-Fenster mit der Fehlersuche.