The short answer
Kubernetes v1.37 “Garhwal” (August 26, 2026) contains three breaking changes that require immediate infrastructure review: (1) nodes using cgroup v1 refuse to start the kubelet — a hard block, not a warning; (2) kube-dns is retired with a migration deadline at v1.40; (3) IPVS in kube-proxy enters its deprecation clock toward removal in v1.43. On the positive side, the metrics.k8s.io API — which powers HorizontalPodAutoscaler and kubectl top — graduates from Beta to Stable (v1) after nine years of production use. Teams on managed cloud Kubernetes with current node images are largely unaffected. Self-managed clusters on older node images should treat this upgrade as an infrastructure modernization project, not a routine version bump.
67 enhancements: what shipped
The v1.37 release cycle ran 15 weeks — May 18 to August 26, 2026 — with contributions from 1,754 individuals across 212 companies. The final count: 67 enhancements, of which 16 graduated to Stable, 23 to Beta, 27 entered Alpha, and 1 moved to deprecation or removal. Named “Garhwal” after a Himalayan region of Uttarakhand, India, the release logo depicts snow-capped peaks and a winding river — imagery chosen to reflect how “every layer, route, and contribution is connected” across the project’s many SIGs.
Among the stable graduations beyond the metrics API, the most operationally relevant are KYAML output for kubectl, pod-level resource definitions, and device-level taints and tolerations for Dynamic Resource Allocation (DRA). That last item is particularly significant for teams running GPU or custom accelerator workloads: DRA is becoming the foundational mechanism for heterogeneous hardware scheduling in AI/ML pipelines, and the new Alpha additions in v1.37 are worth reviewing now ahead of future stable graduation. For teams running Kubernetes clusters in production, though, the upgrade decision typically rests on breaking changes, not new features — and this release has three.
cgroup v1 removal: the hard block
Since Kubernetes v1.35, nodes using cgroup v1 have generated startup warnings. In v1.37, the behavior hardens: if the kubelet detects cgroup v1 at startup, the node does not initialize. There is no graceful degradation. Upgrading an affected cluster will brick those nodes immediately.
To check a node, run stat -fc %T /sys/fs/cgroup/. Output of tmpfs means cgroup v1; cgroup2fs means cgroup v2 and the node is safe. Distributions that default to cgroup v1 include CentOS 7, RHEL 7 (EL7 kernel 3.10), and Ubuntu 18.04. Most cloud-managed node images on EKS, GKE, and AKS migrated to cgroup v2 between 2022 and 2023, so teams on current cloud-provider-managed node pools are generally unaffected.
A failCgroupV1: false field in KubeletConfiguration can suppress the hard block. The Kubernetes project labels this dangerous: it locks the node out of Memory QoS, Pressure Stall Information (PSI) metrics, and certain swap configurations that require cgroup v2, and it will be removed in a future release. It is migration insurance, not a permanent configuration.
The practical path is a node image upgrade before touching the Kubernetes version. On-premises teams should move to RHEL 8+, Rocky Linux, AlmaLinux 8+, or Ubuntu 20.04+. Cloud teams on self-managed node groups should update the AMI or VM image. The cloud & DevOps engineering effort here is real but well-bounded: cgroup v2 has been stable for years and the migration path is well-documented.
kube-dns and IPVS deprecation timeline
kube-dns is retired in v1.37. CoreDNS, which has been the default since Kubernetes 1.13 (2018), replaces it entirely. Clusters still running kube-dns have until Kubernetes 1.40 to migrate — after that, cluster DNS will stop functioning. CoreDNS migration involves replacing the kube-dns DaemonSet with a CoreDNS Deployment and updating ConfigMaps to use Corefile syntax. Most managed cloud Kubernetes services automated this migration years ago. If your cluster shows kube-dns pods in kube-system, schedule the migration this quarter.
IPVS in kube-proxy enters its formal deprecation clock in v1.37, with removal targeted for v1.43. The replacement is nftables, which offers better performance, richer rule expressions, and active upstream maintenance. If your networking team has monitoring, alerting, or custom tooling built around IPVS counters, plan the nftables migration before the v1.43 cutoff — roughly four release cycles, or approximately 12–18 months at the current release cadence.
Metrics API graduates to stable
The metrics.k8s.io API, which provides CPU and memory usage for pods and nodes, graduates from Beta to Stable (v1) in v1.37. Release Lead Dipesh Rawat noted the irony directly: “Despite the Beta label, the metrics.k8s.io API has been widely used in production for years.” The API is what makes kubectl top nodes, kubectl top pods, HorizontalPodAutoscaler (HPA), and VerticalPodAutoscaler (VPA) work.
The practical consequence of the stable graduation is that the metrics.k8s.io v1 API surface is now committed to the Kubernetes compatibility guarantee — it will not change in a breaking way for the foreseeable future. For teams that have quietly carried a note in their runbooks warning that HPA relies on a Beta API, you can remove it. The autoscaling surface your reliability team depends on is now part of the Kubernetes compatibility contract.
What it means for US & EU software teams
The cgroup v1 removal is the most operationally urgent item in this release. Unlike most Kubernetes breaking changes, which affect API versions or manifest schemas, this one targets node-level infrastructure. That means it requires coordination between your platform team and whoever owns node image management — cloud infrastructure team, on-premises ops, or whoever provisions VM images. Engineering leads should run the stat -fc %T /sys/fs/cgroup/ check across all cluster nodes this week and classify the findings before the next upgrade window.
On-premises and hybrid clusters carry the highest risk. Companies running Kubernetes on older enterprise Linux distributions — particularly RHEL 7-era infrastructure — may face a double migration: upgrading the Linux distribution alongside the Kubernetes version. In regulated industries (FinTech, HealthTech, insurance, public sector), OS major version upgrades typically require security team sign-off, vulnerability scan clearance, and sometimes change management board approval. Build that lead time into your planning now rather than at the upgrade window.
The kube-dns and IPVS timelines are softer but not indefinite. v1.40 for kube-dns and v1.43 for IPVS give several release cycles of runway, but these items should enter your backlog this planning cycle rather than at the last minute. Kubernetes release cadence has been accelerating; the gap between comfortable runway and hard deadline closes faster than it used to.
The metrics.k8s.io stable graduation benefits FinTech and HealthTech teams specifically. Regulated organizations often document API dependencies and their stability guarantees for compliance auditors. The graduation of the metrics API to stable simplifies that documentation: the autoscaling mechanism your reliability team depends on is now covered by the Kubernetes compatibility contract, not a best-effort Beta feature.
Planning a Kubernetes upgrade or cgroup v2 node migration?
Our engineers scope and execute Kubernetes cluster upgrades, cgroup v2 node migrations, and CoreDNS transitions for US and EU product teams — including regulated industries where OS upgrades require compliance sign-off. We identify the breaking changes relevant to your specific cluster configuration before you touch a node.
Talk to an engineerWhat engineering leads should do now
| Action | Timeline | Notes |
|---|---|---|
Run stat -fc %T /sys/fs/cgroup/ across all cluster nodes | This week | Output tmpfs = cgroup v1; node will fail kubelet on upgrade. Audit before any v1.37 upgrade attempt. |
| Upgrade node images on cgroup v1 nodes before upgrading Kubernetes | Before next upgrade window | Target RHEL 8+, Rocky Linux 8+, AlmaLinux 8+, Ubuntu 20.04+, or current cloud-provider AMI. cgroup v2 must be active on the OS before the kubelet upgrade. |
| Verify DNS: confirm CoreDNS is running, not kube-dns | This sprint | Run kubectl get pods -n kube-system | grep dns. kube-dns must be migrated before v1.40 or cluster DNS breaks. |
| Audit kube-proxy configuration for IPVS mode | This sprint | Check kubectl get configmap kube-proxy -n kube-system -o yaml for mode: ipvs. If set, plan nftables migration before v1.43. |
| Review DRA Alpha features if running GPU or accelerator workloads | This planning cycle | Device-level taints and tolerations reached Stable. Evaluate DRA Alpha additions to reduce custom scheduling complexity in AI/ML pipelines. |
| Update HPA runbooks to reflect metrics API stable status | Next planning cycle | Remove Beta-related caveats. The metrics.k8s.io v1 API is now covered by the Kubernetes compatibility guarantee. |
Sources: Kubernetes v1.37: Garhwal — Official release blog (kubernetes.io, August 26, 2026); Kubernetes cleans house, bins legacy kube-dns, IPVS, and cgroup v1 (The Register, August 26, 2026).
FAQ
What is cgroup v1 and why does Kubernetes 1.37 remove it?
cgroup v1 is the original Linux control groups mechanism Kubernetes uses to group and limit CPU, memory, and I/O resources for containers. Since v1.35, Kubernetes has emitted startup warnings for nodes still using cgroup v1. In v1.37, the behavior becomes a hard block: if the kubelet detects cgroup v1 at startup, the node will not initialize. cgroup v2 — available since Linux kernel 4.5 and default in most modern distributions since 2021 — offers a unified hierarchy, better memory QoS, Pressure Stall Information (PSI) metrics, and more efficient swap management. The Kubernetes project concluded that maintaining dual support was no longer justified.
How do I check if my nodes are using cgroup v1?
Run stat -fc %T /sys/fs/cgroup/ on each node. Output of tmpfs means cgroup v1; cgroup2fs means cgroup v2 and the node is safe to upgrade. On v1.35 and v1.36 nodes, cgroup v1 detection also generates a warning in the kubelet log. Distributions that default to cgroup v1 include CentOS 7, RHEL 7 (EL7 kernel 3.10), and Ubuntu 18.04. Most cloud-managed node images on EKS, GKE, and AKS moved to cgroup v2 between 2022 and 2023.
What is the failCgroupV1 workaround and should I use it?
KubeletConfiguration includes a failCgroupV1 field that can be set to false to suppress the hard startup block. The Kubernetes project explicitly labels this dangerous: it locks the node out of Memory QoS features, PSI metrics, and swap configurations that require cgroup v2. The field will be removed in a future release. Use it only as short-term migration insurance while you prepare the node image upgrade, not as a permanent configuration.
What happens to kube-dns and IPVS in Kubernetes 1.37?
kube-dns is retired in v1.37 in favor of CoreDNS, which has been the default DNS solution since Kubernetes 1.13 (2018). Clusters still using kube-dns must migrate before Kubernetes 1.40 or cluster DNS will stop functioning. Separately, IPVS support in kube-proxy is deprecated in v1.37 and will be removed in v1.43, replaced by nftables. If your kube-proxy ConfigMap shows mode: ipvs, plan the nftables migration before the v1.43 cutoff.
What does the metrics.k8s.io stable graduation mean for HPA?
The metrics.k8s.io API — powering kubectl top, HorizontalPodAutoscaler (HPA), and VerticalPodAutoscaler (VPA) — graduates from Beta to Stable (v1) in Kubernetes 1.37 after nine years of production use in Beta. The stable graduation means the API surface is now committed to the Kubernetes compatibility guarantee and will not change in a breaking way. For teams relying on HPA for autoscaling, this formalizes a foundation that was already de facto stable in production.