--- title: "Kubernetes v1.37 „Garhwal\": Was EKS-Betreiber vor dem nächsten Upgrade wissen müssen" description: "Kubernetes v1.37 „Garhwal\" ist seit dem 26. August 2026 verfügbar. Was EKS-Teams über Breaking Changes, DRA GA und den schnelleren API-Server wissen müssen." --- [DMoove Blog](https://dmoove.com/blog) # [Kubernetes v1.37 „Garhwal": Was EKS-Betreiber vor dem nächsten Upgrade wissen müssen](https://dmoove.com/blog/kubernetes-v1-37-garhwal-eks-upgrade-guide) Geschrieben von [Yannick Tresch](https://dmoove.com/blog/author/yannick-tresch) | Sep 14, 2026, 7:00:00 AM ## 67 Enhancements, ein Release-Datum – und drei Dinge, die Ihren Cluster brechen können 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](https://kubernetes.io/blog/2026/08/26/kubernetes-v1-37-release/). 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. ## Schnellerer API-Server: ConcurrentWatchObjectDecode und EtcdRangeStream 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](https://kubernetes.io/blog/2026/08/26/kubernetes-v1-37-release/) 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](https://kubernetes.io/blog/2026/09/01/kubernetes-v1-37-etcd-range-stream/); mit älteren etcd-Versionen fällt der API-Server automatisch auf den bisherigen paginierten Range-Pfad zurück. ## DRA wird erwachsen: GPU-Scheduling ohne Device Plugins Dynamic Resource Allocation (DRA) ist seit v1.34 stabil. In v1.37 erreicht ein wichtiges Teilfeature GA: [**DRA Extended Resource Support**](https://kubernetes.io/blog/2026/09/03/kubernetes-v1-37-dra-updates/). 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. ## Drei Breaking Changes, die vor dem Upgrade geprüft werden müssen 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=