Kubernetes 1.37 is now available as the project’s second minor release of 2026. Code-named Garhwal, the release contains 67 enhancements: 16 graduating to Stable, 23 moving to Beta, 27 entering Alpha and one deprecation or removal.
The headline features include scale-to-zero support for the HorizontalPodAutoscaler, a Stable metrics.k8s.io API, Stable KYAML output and new building blocks for AI and high-performance computing workloads. However, administrators should pay just as much attention to changes involving SELinux volumes, cgroup v1 and StatefulSet rollouts before upgrading a production cluster.
Key takeaways
- Kubernetes 1.37 was released on 26 August 2026 and is actively supported.
- HorizontalPodAutoscaler scale-to-zero is Beta, enabled by default and limited to object or external metrics.
metrics.k8s.io/v1, KYAML and StorageVersionMigration are now Stable.- The Stable SELinux mount behavior can prevent Pods with different labels from sharing one volume on the same node.
- Administrators still using cgroup v1 should treat migration to cgroup v2 as urgent.
Kubernetes 1.37 release summary
| Item | Kubernetes 1.37 detail |
|---|---|
| Code name | Garhwal |
| Release date | 26 August 2026 |
| Enhancements | 67 total |
| Feature stages | 16 Stable, 23 Beta and 27 Alpha |
| Support status | Actively supported |
| First planned patch | 1.37.1, targeted for 15 September 2026 |
The name Garhwal refers to the Himalayan region of Uttarakhand, India. According to the official Kubernetes 1.37 announcement, its woven release theme represents the way code, reviews, testing, documentation and coordination combine into one release.
Ten Kubernetes 1.37 changes administrators should check
1. HorizontalPodAutoscaler can scale suitable workloads to zero
HorizontalPodAutoscaler scale-to-zero has graduated to Beta and is enabled by default. A workload using object or external metrics can set spec.minReplicas: 0, remain at zero while idle and return when the relevant metric reports demand. Likely uses include queue consumers, batch workers and some GPU workloads.
This does not enable scale-to-zero based on CPU or memory, because those metrics require running Pods. Teams should also confirm that their metrics pipeline continues reporting while the target workload has no active replicas.
2. The metrics API is finally Stable
After almost nine years in Beta, metrics.k8s.io has reached Stable. The API supplies Pod and Node CPU and memory measurements used by tools such as kubectl top and by the HorizontalPodAutoscaler.
The existing v1beta1 API remains available during the transition, so this is not an immediate breaking change. Operators and tool maintainers can begin testing metrics.k8s.io/v1 without rushing an unplanned migration.
3. KYAML output reaches Stable
KYAML is a deliberately restricted, less ambiguous subset of YAML designed for Kubernetes configuration. Every KYAML document remains valid YAML, so existing manifests and pipelines do not need to be rewritten. In Kubernetes 1.37, kubectl get -o kyaml is Stable.
This gives administrators a more predictable display format without introducing a new manifest language. It is especially helpful when generated output needs to be reviewed or committed to version control.
4. SELinux volume handling requires an upgrade check
SELinuxMount and SELinuxChangePolicy are Stable and enabled by default. When a CSI driver opts in through CSIDriver.spec.seLinuxMount: true, Kubernetes can mount a volume with an SELinux context rather than recursively relabeling its files.
The faster behavior comes with an important compatibility concern: one mount can carry only one SELinux context. Pods with different SELinux labels that share the same volume on one node may fail to start. Affected workloads can set spec.seLinuxChangePolicy: Recursive to retain the older relabeling behavior. Clusters that do not use SELinux are unaffected.
5. Storage Version Migration becomes built in and Stable
The storagemigration.k8s.io/v1 API is Stable and enabled by default. It lets administrators declare a migration that rewrites stored built-in or custom resources into the current preferred API storage version.
This can replace error-prone kubectl get/replace scripts and the separate kube-storage-version-migrator component. It is also useful after changing encryption-at-rest configuration, when existing data must be rewritten using the new encryption settings.
6. Memory QoS moves to Beta and is enabled by default
Memory QoS now uses cgroup v2 controls including memory.min, memory.low and memory.high to provide protection and throttling. The feature gate is enabled by default, although the default settings are intended to avoid surprising throttling during an upgrade.
Operators should still review the kubelet’s memoryReservationPolicy and memoryThrottlingFactor before changing the defaults, then test memory-sensitive workloads on representative nodes.
7. Native gang scheduling advances for AI and HPC jobs
Gang scheduling has reached Beta through the Workload API and PodGroup model. Instead of scheduling parts of a distributed job while the remaining Pods wait for capacity, Kubernetes can apply an all-or-nothing strategy when sufficient resources are available for the group.
This is particularly relevant to AI training and HPC jobs, where partially scheduled workers can waste expensive GPU or accelerator time. Kubernetes 1.37 also adds workload-aware preemption and PodGroup queueing, but teams should confirm how their workload controllers integrate with the new APIs before adopting them.
8. Pod checkpoint and restore arrives as Alpha
A new Alpha capability extends the Container Runtime Interface with CheckpointPod and RestorePod RPCs. Compatible runtimes can use these calls to capture and restore an entire Pod rather than working only at individual-container level.
This is experimental and requires support from the container runtime. It should be evaluated in a test environment rather than enabled broadly in production.
9. StatefulSet maxUnavailable is enabled again
The maxUnavailable field for StatefulSets is enabled by default again after a bug caused the feature to be turned off in Kubernetes 1.36. It can permit multiple StatefulSet Pods to be unavailable during a rolling update, potentially making controlled rollouts faster.
Review existing StatefulSet update strategies and disruption assumptions. A field that previously had no effect because its gate was disabled may affect rollout concurrency after the upgrade.
10. cgroup v1 is living on borrowed time
The kubelet has defaulted to refusing nodes that rely on cgroup v1 since Kubernetes 1.35. Kubernetes 1.37 still permits a temporary override:
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
failCgroupV1: falseThis is a temporary escape hatch, not a long-term configuration. Features including Memory QoS depend on cgroup v2, and Kubernetes plans to remove cgroup v1 support in a future release. Inventorying nodes and moving incompatible operating systems or workloads should be part of the 1.37 upgrade project.
Kubernetes 1.37 upgrade checklist
Kubernetes supports version-skew rules and recommends upgrading one minor version at a time. Before touching production, administrators should read the complete Kubernetes 1.37 changelog and the project’s version-skew policy.
- Confirm the current version: run
kubectl versionand inventory every control-plane and worker node. - Check cgroup mode: use
stat -fc %T /sys/fs/cgroup/;cgroup2fsindicates cgroup v2. - Audit SELinux storage: identify CSI drivers opting into SELinux mounts and volumes shared by differently labelled Pods.
- Review StatefulSets: inspect any use of
maxUnavailableand test rollout behavior. - Test autoscaling: verify external or object metrics remain available when a workload reaches zero replicas.
- Check API consumers: find monitoring tools that hard-code
metrics.k8s.io/v1beta1and plan their move tov1. - Back up etcd: create and verify a control-plane datastore snapshot before the upgrade.
- Upgrade a staging cluster first: validate networking, storage, admission policies, monitoring and rollback procedures.
Administrators building containers for the cluster may also find LinuxPanda’s guides to building a Docker image with a Dockerfile, pushing a Docker image to Docker Hub and hardening a Linux server useful.
Should production clusters upgrade immediately?
Kubernetes 1.37.0 is a supported final release, not a preview. Even so, production teams generally benefit from validating the first release on staging and watching for early ecosystem compatibility reports. The project currently targets Kubernetes 1.37.1 for 15 September 2026.
Clusters that need scale-to-zero, Stable storage migration or the latest AI workload scheduling improvements have clear reasons to begin testing now. Clusters using SELinux-labelled shared volumes, older cgroup v1 nodes or complex StatefulSets should prioritise compatibility testing over a quick rollout.
Common questions
Is Kubernetes 1.37 a stable release?
Yes. Kubernetes 1.37.0 was officially released on 26 August 2026 and is listed as actively supported. Individual Alpha and Beta features inside the release retain their respective maturity levels.
Can Kubernetes 1.37 scale applications to zero Pods?
Yes, when the HorizontalPodAutoscaler uses object or external metrics. Scale-to-zero does not work with CPU or memory metrics because those measurements depend on running Pods.
Does Kubernetes 1.37 require cgroup v2?
The kubelet refuses cgroup v1 by default, although a temporary failCgroupV1: false override remains. Administrators should migrate to cgroup v2 because newer resource-management features depend on it and cgroup v1 support is planned for removal.
Will existing YAML manifests stop working?
No. KYAML becoming Stable does not replace YAML or require manifests to be rewritten. KYAML is a restricted subset of YAML, and kubectl get -o kyaml is an optional output format.
Comments