The Cloud Native Computing Foundation has released Kubernetes 1.37, code-named “Garhwal,” with a mix of stability, security, and workload-management updates that touch everything from autoscaling to node hardening. The headline changes include the general availability of the Metrics API and the move of Kubelet in user namespace, or rootless mode, to beta.
Kubernetes 1.37 focuses on stability and operational control
According to the release announcement, Kubernetes 1.37 includes 67 enhancements in total, with 27 alpha features, 23 graduating to beta, 16 becoming generally available or stable, and one deprecation or removal. The release is framed around three broad priorities: stability, security, and AI/ML workload optimization.
That emphasis is visible in several of the changes promoted in this version. Some features are now mature enough for production use, while others are still gated behind feature flags so operators can test them carefully before enabling them broadly.
Metrics API reaches general availability
One of the most notable changes in Kubernetes 1.37 is the general availability of the Metrics API. The metrics.k8s.io API provides a standard way to monitor and measure node and pod health, and it is already used by familiar Kubernetes functions such as the Horizontal Pod Autoscaler, Vertical Pod Autoscaler, and kubectl top.
Moving the Metrics API to stable matters because it gives cluster operators a more reliable foundation for scaling and visibility tooling. In practical terms, it strengthens the data path that helps Kubernetes decide when to add resources, shrink workloads, or report current usage in a consistent way.
Rootless Kubelet reaches beta
Kubelet in user namespace, also described as rootless mode, graduated to beta in this release. The KubeletInUserNamespace feature gate is enabled by default, allowing core node components such as the kubelet to run as non-root on the host by using Linux user namespaces.
The security benefit is straightforward: if an attacker escapes a container, running kubelet without root privileges can help reduce the impact. Kubernetes is not eliminating risk, but it is narrowing the blast radius of some classes of compromise by making the node agent less privileged.
Autoscaling and AI/ML workloads get attention
HorizontalPodAutoscaler scale-to-zero support also graduated to beta in Kubernetes 1.37 and is enabled by default. The release notes say this can help reduce costs, especially for AI/ML workloads that rely on GPUs in cloud environments.
That detail is important because AI and machine learning deployments often have uneven demand. Being able to scale workloads down to zero when they are idle can limit unnecessary spend, while still allowing clusters to scale back up when jobs resume.
New alpha features add more scheduling and recovery options
Several features enter alpha in Kubernetes 1.37, giving early adopters new capabilities to test. One is workload-aware scheduling, exposed through the InPlacePodVerticalScalingSchedulerPreemption feature gate. It is designed to free resources on a node at capacity by preempting low-priority workloads, which can make room for pending in-place resizing of higher-priority applications.
That can be useful in dense clusters where resources are tightly packed and critical workloads need to grow without waiting for a node to be completely free. Since the feature is still alpha, it remains experimental and should be approached as a preview rather than a default operating mode.
Another alpha addition is pod-level checkpoint and restore. This allows the kubelet to create a checkpoint and restore a pod from it, making it easier for practitioners to capture a snapshot of a running container’s memory, process trees, and related state for debugging or security analysis.
Checkpointing can be especially useful when diagnosing difficult failures that are hard to reproduce. It also offers a path for more advanced forensic inspection, although the feature is still early and not positioned as a finished recovery mechanism.
Kubernetes 1.37 also introduces the Recreate strategy for StatefulSet rollouts as an alpha feature. The deployment option deletes all existing pods, which can help with clean recovery for stuck or pending pods during updates without requiring manual pod deletion.
Because this strategy is off by default and tied to a feature flag, it gives operators a way to experiment with a more forceful rollout approach while keeping current behavior unchanged unless they deliberately opt in.
Control plane resilience improves with watchcache changes
Resilient watchcache initialization is now generally available and enabled by default. The release notes describe a problem that existed before this change: if the kube-apiserver restarted or lost its cache connection in a large cluster, it could flood etcd with requests, potentially causing performance issues and even control plane outages.
With the new behavior enabled, kube-apiserver will safely delegate bounded requests and reject others with HTTP 429 responses when necessary. That matters because it gives the system a more graceful way to absorb startup pressure instead of overwhelming the backend datastore. Hoon Jo, a CNCF ambassador and tech evangelist at Megazone Corp, highlighted the change in a recent LinkedIn post, saying: “Resilient watchcache initialization is stable and locked on so that the kube-apiserver no longer floods etcd at startup.”
Pod certificates become stable
Pod certificates also graduated to stable in Kubernetes 1.37. This provides native support for secure pod-to-pod communication without depending on external tools to bootstrap mTLS between internal services.
For teams running service-heavy applications, that reduces the amount of custom infrastructure needed to establish trust between pods. It also aligns with the broader trend in Kubernetes toward more built-in security primitives rather than relying solely on add-ons or external certificate workflows.
What operators should take away from this release
Kubernetes 1.37 is not a single dramatic overhaul, but it does continue the platform’s steady move toward safer defaults and more practical operations. The most immediately relevant changes for many users are the stable Metrics API, rootless Kubelet reaching beta, the beta graduation of scale-to-zero, and the now-stable resilience improvements around watchcache initialization.
For platform teams, the release also adds more experimental tools for scheduling, rollout recovery, and pod inspection. That gives operators more options to evaluate as they plan for scaling, debugging, and hardening their clusters.
Release cadence continues toward Kubernetes 1.38
The Kubernetes project said users can join the release team on Wednesday, September 23, 2026, at 11:00 AM CDT for a live online webinar. The next version, Kubernetes 1.38, is expected by December 2026.
As with previous releases, the official release notes remain the best place to review the full list of enhancements, deprecations, and removals before upgrading. For teams running large or security-sensitive clusters, that review is especially important because even incremental changes can affect scheduling, autoscaling, and control-plane behavior in meaningful ways.
Source: Original report
Was this helpful?
Explore more: DevOps Services More Cloud & DevOps Tech News
Last Modified: September 21, 2026 at 10:32 pm
0 views
