Kubernetes 1.37 Garhwal: What Actually Changes for You #

Kubernetes 1.37, named Garhwal after a Himalayan region of Uttarakhand, shipped on 26 August 2026 with 67 enhancements: 16 graduated to stable, 23 to beta, 27 entered alpha, and one deprecation. Release notes at that size are not useful as a reading list, because most of those enhancements affect subsystems you will never configure. Four of them change decisions you are actively making about cost, security posture, and scheduling. Those are the ones below.

Scale to zero reaches beta, and it changes cluster economics #

The HorizontalPodAutoscaler can now scale a workload down to zero replicas, promoted to beta in this release. Until now, scaling to zero on vanilla Kubernetes meant reaching for Knative, KEDA, or a custom controller, because the built-in HPA would not go below one replica. A workload that ran 24 hours a day to serve traffic for two of them kept a pod resident the whole time.

For internal tooling, batch-adjacent services, staging environments, and anything with genuinely bursty traffic, this removes a standing cost floor across every namespace at once. It is also the feature most likely to surprise you, because scaling to zero reintroduces cold starts on a path that previously had none. A service that was always warm now pays initialization latency on the first request after an idle period, which is fine for an internal dashboard and not fine for a checkout service.

Treat the scale-down threshold and stabilization window as the important settings rather than the feature flag. The same conflict we documented in tuning HPA and VPA from production still applies: if the vertical autoscaler is adjusting the same workload on the same signal, the two will fight, and now the floor of that fight is zero.

Rootless kubelet goes beta #

Running the kubelet inside a user namespace, so the node agent itself does not run as root, moved to beta. This is a meaningful change in blast radius. A container escape on a node with a rootless kubelet lands in an unprivileged user namespace rather than on a root-owned process that can reconfigure the node.

The reason to care now rather than at GA is that adopting it late is painful. Anything that assumed root on the node, meaning privileged DaemonSets, host-path mounts, node-level agents from your observability or security vendors, has to be audited. Doing that audit while the feature is beta and optional is considerably cheaper than doing it under time pressure after it becomes the default.

The Metrics API is stable, and Storage Version Migration is on by default #

The Metrics API graduated to stable. If you have been treating metrics-server output as a convenience for kubectl top rather than something to build on, that hesitation is resolved: it is now a stable interface with the compatibility guarantees that implies.

Storage Version Migration being enabled by default is the change most likely to matter during the upgrade itself rather than after it. It migrates stored objects to the current storage version automatically, which is what you want long term, and which also means the API server is doing write work during and after the upgrade that it did not do before. On large clusters, schedule accordingly and watch etcd. This release also includes an etcd memory optimization for large list reads, which helps in the same area.

Dynamic Resource Allocation keeps landing #

DRA extended resource support reached GA in this release, the third consecutive release that moved DRA forward. If you schedule GPUs or other specialized devices, this is the path off the device-plugin model and toward requesting hardware the way you request any other resource. Given what accelerator capacity costs right now, scheduling that can express "this pod needs one of these specific devices" rather than a coarse integer count has a direct bill impact. Our GPU cloud comparison covers the pricing side of the same problem.

What to check before you upgrade #

Deprecations are the only part of a release that can break you without your participation. This release carries one removal, so the standard pre-upgrade pass is short:

bash.bash

# Find API versions in your manifests that the next release drops
$ kubectl api-resources --verbs=list -o name | sort > /tmp/current-apis.txt
$ kubectl get --raw /metrics | grep apiserver_requested_deprecated_apis

# Then confirm nothing in the cluster is still calling them
$ kubectl get events -A --field-selector reason=DeprecatedAPIUsed

The apiserver_requested_deprecated_apis metric is the reliable one. It tells you what is actually being called in your cluster right now, including by controllers you did not install yourself, which static manifest scanning will miss.

The decision, concretely #

Running managed Kubernetes? You are not upgrading today regardless. 1.37 is in the GKE rapid channel, and the stable channels of every managed provider trail by months. Use that time for the rootless audit.
Paying for idle replicas of internal or bursty services? Scale to zero is the reason to move, and it is worth testing in staging now rather than waiting for GA.
Running privileged node agents from a vendor? Start the rootless kubelet compatibility conversation with that vendor now, while the feature is optional.
Scheduling GPUs through device plugins? DRA extended resources hitting GA makes this the release to plan the migration, not the release to do it in production.

The call we'd make #

Upgrade on your normal cadence, which for most teams means the managed provider's stable channel and not this month. The one thing worth doing ahead of that schedule is testing HPA scale to zero in a staging cluster, because it is the change with a direct and immediate cost benefit, and because its failure mode is cold-start latency that you want to discover with a synthetic load test rather than with a customer. Everything else in 1.37 rewards reading the deprecation list carefully and otherwise waiting.

#Upgrades

Kubernetes 1.37 Garhwal: What Actually Changes for You