Kubernetes 1.37, codenamed Garhwal, shipped this week with 67 enhancements. The release leans hard into two themes that matter for production clusters: security hardening and stability under load. Rootless kubelet moves to beta, the Metrics API reaches general availability, and a long-standing startup crash scenario in large clusters finally gets a proper fix.
Rootless Kubelet Goes to Beta
The KubeletInUserNamespace feature gate is enabled by default in 1.37. This means the kubelet, the node agent responsible for managing pods and containers, can run as a non-root process using Linux user namespaces. The security motivation is direct: if an attacker escapes a container, a root kubelet gives them root on the host. A non-root kubelet limits the blast radius.
User namespaces work by mapping a process's view of the filesystem and process tree to a different set of IDs on the host. The kubelet thinks it is root inside its namespace. The host sees a regular user. This is the same mechanism that has protected containers from each other for years, now extended to the node agent itself.
The feature has been in alpha since Kubernetes 1.25. Moving to beta with the gate on by default means the broader ecosystem will start testing it in real clusters. Expect the next few months to surface compatibility issues with third-party CNI plugins, storage drivers, and monitoring agents that assume root access on the node. The security win is real, but the transition will require careful validation in each environment.
Resilient Watchcache Initialization
Before 1.37, a kube-apiserver restart in a large cluster could trigger a cascade failure. The apiserver would lose its in-memory cache of watch events and flood etcd with requests to rebuild it. Under load, this caused etcd latency spikes, control plane instability, and in the worst cases, full outages. The problem was well-known and had no built-in mitigation.
The fix is now stable and locked on by default. When the apiserver restarts, it delegates bounded requests and rejects excess traffic with HTTP 429 responses. The 429 status code is the standard signal for "too many requests, try again later." Clients that respect retry logic will back off and retry after the cache is warm. Clients that do not respect 429 will fail, but that failure is preferable to a cascading etcd overload that takes down the entire control plane.
Hoon Jo, a CNCF ambassador at Megazone Corp, called out the feature's significance. For operators running clusters with thousands of nodes, this is one of those changes that prevents 3 AM pages. The apiserver restarts cleanly, the cache warms gradually, and etcd stays healthy.
Metrics API Reaches General Availability
The metrics.k8s.io API is now stable. This is the interface that powers kubectl top, the Horizontal Pod Autoscaler, and the Vertical Pod Autoscaler. Before GA, the API was subject to change between releases, which made it risky to build automation on top of it. Stability means the contract is locked: the resource types, the fields, and the behavior will not change without a deprecation cycle.
For teams running autoscaled workloads, especially AI/ML pipelines that need GPU-based scaling, this matters. HPA scale-to-zero, which graduated to beta in 1.27 and is enabled by default, already reduces costs by scaling GPU pods down to zero when idle. A stable metrics API means the scaling logic can rely on consistent, predictable data. The days of rewriting HPA configurations because the metrics endpoint changed shape are over.
Workload-Aware Scheduling and StatefulSet Recovery
Two alpha features address scheduling flexibility. The first, InPlacePodVerticalScalingSchedulerPreemption, lets the scheduler preempt low-priority workloads to free resources for in-place resizing of high-priority pods. In-place resizing means changing a pod's CPU and memory requests without restarting it. The scheduler can now make room for that resize by evicting lower-priority pods on the same node. This is particularly relevant for AI/ML workloads that need to scale up quickly during training and scale down during inference.
The second alpha feature adds a Recreate strategy for StatefulSet rollouts. This strategy deletes all existing pods before creating new ones. It sounds destructive, and it is, but it solves a real problem: stuck or pending pods during updates that require manual intervention to clear. The feature is off by default, available for operators who need a clean slate during StatefulSet updates.
Pod Checkpoint and Restore
The new pod-level checkpoint and restore feature, also alpha, lets the kubelet snapshot a running container's memory, process trees, and other state. The primary use case is debugging and security analysis. An operator can checkpoint a pod, inspect the checkpoint offline, and restore it later without losing the container's state.
This capability has existed in tools like CRIU for years, but it was not integrated into the kubelet. Having it as a first-class Kubernetes feature means debugging production containers no longer requires reproducing the exact conditions that triggered the issue. You checkpoint the pod at the moment of interest, analyze it offline, and restore it when done.
Pod Certificates and Secure Communication
Pod certificates reached stable in 1.37. This provides native support for mTLS between pods without external tools like service meshes. The kubelet provisions certificates for pods, and the API server manages the trust chain. For teams that previously relied on Istio, Linkerd, or custom certificate bootstrapping to secure pod-to-pod traffic, this reduces the operational overhead significantly.
The combination of pod certificates and rootless kubelet represents a meaningful shift in Kubernetes security posture. The node agent runs unprivileged, and internal service communication is encrypted and authenticated by default. These are not new capabilities, but they are now stable and enabled by default, which changes the calculus for teams that previously treated them as optional.
The Release in Numbers
Kubernetes 1.37 includes 67 enhancements. Of those, 27 are alpha (early experimental), 23 are graduating to beta (enabled by default but subject to change), 16 are generally available or stable (locked contract), and 1 is a deprecation or removal. The skew toward stability and beta graduation over new alpha features reflects the project's current phase: the core platform is mature, and the focus is on hardening and operational reliability rather than adding new surface area.
The next release, Kubernetes 1.38, is expected in December 2026. The release team is hosting a live webinar on September 23 for a walkthrough of the changes.