Kubernetes 1.37 Garhwal: Three Breaking Changes Cluster Operators Must Know Now

Kubernetes 1.37 “Garhwal” is here — along with three breaking changes that cluster operators should not ignore. On August 26, 2026, the Kubernetes project released the 37th minor version, named after the Garhwal Himalayan region in Uttarakhand, India. 67 enhancements are included in this release: 16 reach Stable, 23 have grown to Beta, 27 start as Alpha, and one deprecation is formalized. For most clusters, the upgrade is a routine matter. Three changes, however, can massively disrupt a smooth update path — or prevent the kubelet from starting at all.

cgroup v1: The Hard Stop

The most operationally impactful change concerns the Linux kernel mechanism cgroup v1. Since Kubernetes 1.35, the feature gate failCgroupV1 has been set to true by default. This means: Starting from 1.37, the kubelet simply will not start on nodes that still use cgroup v1, unless the admin explicitly sets the override --fail-on-cgroup-v1=false. However, this override will only exist temporarily — the complete removal of cgroup v1 in the kubelet is already planned.

The good news: cgroup v2 has long been standard on all modern Linux distributions. Ubuntu 22.04+, Debian 12, Fedora 31+, and RHEL 9 boot with v2 by default. The risk lies with clusters using older base images — Ubuntu 20.04, Debian 11, RHEL 8, or custom-built images that still rely on the old cgroup API.

Every admin should check each node before the control plane upgrade:

stat -fc %T /sys/fs/cgroup/
# „cgroup2fs" = cgroup v2 (sicher)
# „tmpfs" = cgroup v1 (Handlungsbedarf)

The Kubernetes release blog recommends an OS upgrade to a distribution with cgroup v2 as standard for affected nodes. The temporary override is intended only as a migration aid.

IPVS kube-proxy mode: The countdown is running

Kube-proxy in IPVS mode is formally marked as deprecated in 1.37. Introduced in Kubernetes 1.11 in 2017 as a more powerful alternative to iptables, IPVS is now being phased out in favor of the newer nftables backend. nftables uses set-based lookups that do not require the kernel module ip_vs or the userspace tools ipvsadm. Actual removal is planned for Kubernetes 1.39 (expected mid-2027).

To check the current proxy mode:

kubectl -n kube-system get configmap kube-proxy -o yaml | grep mode
# oder
ps aux | grep kube-proxy | grep -o '\-\-proxy-mode=[a-z]*'

Anyone still seeing mode: ipvs should plan migration to mode: nftables (preferred as of kernel 5.13) or back to mode: iptables. The migration is done via a ConfigMap update and a rolling restart of the kube-proxy DaemonSet — a manageable effort that should not be postponed.

Static Pods: No more Secrets

The perhaps most insidious change: Static Pods, which the kubelet manages directly from manifest files in the directory /etc/kubernetes/manifests/, may no longer contain Secret or ConfigMap references as of 1.37. The feature gate PreventStaticPodAPIReferences, which initially made this restriction optional, has been removed. The behavior