Kubernetes v1.37, codenamed Garhwal, ships with 67 enhancements: 16 Stable, 23 Beta, 27 Alpha, and one deprecation. The logo is a window onto the Garhwal Himalaya in Uttarakhand.
Sixteen enhancements graduated to Stable, most of them completing work begun in earlier releases. Dynamic Resource Allocation’s core is now Stable, the API server no longer overloads etcd on restart, and admission policy can be loaded from disk.
The core of Dynamic Resource Allocation goes Stable
Four DRA enhancements reach Stable in v1.37.
ResourceClaim device status (KEP-4817) lets a driver report device-specific status for each allocated device on .status.devices. The motivating case is networking, where before this field a Pod could request a network device through DRA and nothing else in the system could learn the IP address assigned to it. DRA is now usable for attaching secondary network interfaces to Pods, which telco and NFV workloads have been waiting on.
Extended resource requests through a DRA driver (KEP-5004) lets a DRA driver satisfy a request written the old way. Assign an extended resource name directly to a DeviceClass, and a Pod asking for abc.example/gpu: 3 gets a device allocated through DRA with no ResourceClaim in the workload and no device plugin. Existing manifests keep working while the allocation path changes underneath, which makes this the migration route off device plugins.
Device taints and tolerations (KEP-5055) bring a familiar primitive down to the device level. A driver can taint one device, or an administrator can write a DeviceTaintRule that taints by selection criteria, such as every device managed by one driver. Draining a bad GPU no longer means draining the node it sits in.
A standard numaNode attribute (KEP-6072) registers resource.kubernetes.io/numaNode as the shared name for device NUMA placement, so devices from different drivers can be compared directly.
Alongside those, resource health status for Pods (KEP-4680) reaches Stable. We covered it here when it entered beta in v1.36, and the advice then was to adopt allocatedResourcesStatus before you needed it. It now carries a stability commitment and works across both the older Device Plugins framework and DRA.
More DRA work is already in progress. Sharing claims across a group of Pods reaches Beta (KEP-5729), so one workload can hold a single claim where it previously needed one per Pod. If you run accelerators at scale, these alpha features are worth tracking.
- Node-allocatable resource requests (KEP-5517) unify standard and DRA accounting, so the same node capacity stops being counted twice.
- Derived attributes (KEP-6080) let a CEL expression build a shared value such as a NUMA identifier, so GPUs and NICs can be co-located even when their drivers name things differently.
- Device compatibility groups (KEP-5963) let a driver declare which devices can be allocated together, so the scheduler stops pairing configurations that cannot coexist on one GPU, such as MIG and vGPU.
The API server no longer overloads etcd at startup
Resilient watchcache initialization (KEP-4568) completes in v1.37. The ResilientWatchCacheInitialization gate went Stable in v1.34; the remaining WatchCacheInitializationPostStartHook gate graduates now and is locked on, having defaulted to enabled since v1.36.
Large clusters hit the problem during recovery, when the watch cache initializes or reinitializes and generates a spike of list and watch traffic against etcd. That spike could exhaust API Priority and Fairness capacity and take the control plane down mid-recovery. The API server now delegates bounded requests safely and rejects the rest with HTTP 429 while the cache warms.
Requests that would previously have been served slowly are now refused outright. Any controller or operator you run needs to handle 429 Too Many Requests by respecting Retry-After and backing off exponentially. Controllers written against a client library that does this already are fine. Hand-rolled clients, and anything that treats a non-200 as a fatal error, will fail while the control plane is recovering.
Admission policy on disk
Manifest-based admission control configuration (KEP-5793) reaches Beta. Admission webhooks and CEL-based policies can now be loaded from files on disk, through a staticManifestsDir field in AdmissionConfiguration. Previously they lived only as objects in the API.
Policies load at API server startup, so no window opens early in a restart where the cluster serves requests with no policy attached. They keep working while etcd is unavailable, so an etcd outage does not also become a gap in policy enforcement. And they can protect the API-based admission resources themselves, closing the path where an attacker with enough privilege deletes the policy that would have stopped them.
Continuous enforcement through an etcd outage is what matters for DORA, NIS2, or EU AI Act evidence. “Our controls were enforced continuously” is easier to defend when enforcement doesn’t depend on the datastore being healthy.
Deprecations and removals
The v1.37 cycle carries one formal deprecation and several changes that will interrupt an upgrade if you have not read them.
kube-dnsis deprecated. CoreDNS has been the default cluster DNS add-on since v1.13 andkube-dnshas not kept pace, lacking EndpointSlices and dual-stack Service support. The subproject is already retired andnode-local-dnshas been split into its own repository, where it continues to be maintained and works with CoreDNS. No new packages are expected forkube-dnsafter v1.40. If you still run it, start planning the move to CoreDNS.kube-proxy’sipvsmode is deprecated. It arrived in v1.8 to solveiptablesperformance problems, but the kernelipvsAPI cannot fully implement Kubernetes Services on its own, soipvsmode has continued to useiptablesunderneath. Clusters running it now log a deprecation warning at startup.ipvsmode is expected to be disabled by default by v1.40 and removed entirely by v1.43 (KEP-5495). Check which mode you are on withkubectl -n kube-system get configmap kube-proxy -o jsonpath='{.data.config\.conf}' | grep 'mode'.- Static Pods can no longer reference Secrets or ConfigMaps. Static Pods were never meant to read API resources, and a bug allowed it through fields like
configMapRefandsecretRef. As of v1.37 those references are prohibited and thePreventStaticPodAPIReferencesgate that let you opt out has been removed. A static Pod relying on this will fail after the upgrade. kubectl run --filename/-fis being deprecated, since the generated Pod is built purely from CLI arguments such asNAMEand--image.- cgroup v1 support continues to wind down.
failCgroupV1has defaulted to true since v1.35, so the kubelet refuses to start on nodes still using cgroup v1 unless you override it. The override is still available in v1.37 and is a short-term fix; memory QoS and in-place scaling for memory-backed volumes only work on cgroup v2 (KEP-5573).
SELinuxMount and SELinuxChangePolicy reach Stable and are enabled by default (KEP-1710), and the change can stop Pods starting after an upgrade. Where a CSI driver opts in via .spec.seLinuxMount: true, volumes are now mounted with -o context=<label>, and recursive relabelling stops. A mount carries one SELinux context, so Pods with different SELinux labels sharing a volume on the same node, which used to coexist under recursive relabelling, can now fail to start. Setting .spec.seLinuxChangePolicy: Recursive on the Pod restores the old behaviour, and the change is not locked until v1.38. Clusters without SELinux are unaffected.
Read the v1.37 changelog before upgrading, and give particular attention to anything that has been beta for more than two releases.
What this means for Kubermatic users
KKP 2.31 supports Kubernetes 1.33 through 1.36, so v1.37 is not available on KKP yet. That changes when each of these becomes your problem.
Audit your controllers for 429 handling now. This one does not wait for 1.37. Resilient watchcache initialization has defaulted to enabled since Kubernetes 1.36, so a KKP cluster running 1.36 already rejects with 429 while the cache warms. v1.37 graduates the gate to Stable and locks it on; the behaviour itself is already live. A controller that retries immediately or exits on a non-200 can misbehave during a control-plane recovery today, and that applies to anything you wrote yourselves as much as anything you run from a vendor. Fleet operators feel this first, because the number of controllers pointed at a control plane scales with the number of clusters you run.
Plan the move off device plugins for when 1.37 arrives. The DRA graduations need 1.37, so treat this as scheduling work for a later quarter. The extended-resource support means the migration will not require rewriting workload manifests when it comes. Resource health status entered beta in 1.36, so you can start surfacing device health on a supported version now. On the cost side, KKP 2.31 added GPU project quotas, an early-stage Enterprise capability for KubeVirt environments that has to be enabled explicitly.
Community
The v1.37 cycle ran 15 weeks, from 18 May to 26 August 2026, under release lead Dipesh Rawat. Contributions came from as many as 212 companies and 1,754 individuals. Our thanks to everyone who wrote code, reviewed it, fixed documentation, drafted a KEP, or shadowed a release-team role. The full roster is in the release-1.37 repository.
Looking forward
Test a controller against an API server that rejects requests, so you learn how it behaves outside an incident.
HorizontalPodAutoscaler scale-to-zero reaches Beta and is enabled by default (KEP-2021). Setting spec.minReplicas: 0 lets a workload driven by object or external metrics drop to no Pods when idle and come back when work arrives, which cuts cost for queue consumers, batch jobs and GPU workloads that spend most of the day waiting. CPU and memory metrics need running Pods to measure, so they’re out of scope. The HPA records a ScaledToZero condition, so a workload it parked is distinguishable from one somebody switched off.
Schedule the kube-dns and ipvs migrations together. Both change cluster networking, so both need a maintenance window and a tested rollback, and the v1.40 and v1.43 deadlines leave room to do that without hurrying.
