By Kubernetes 1.37 “Garhwal” is out today, August 26, carrying 67 enhancements — 16 graduating to stable, 23 to beta, and 27 new alpha features. Most of the coverage will land on containerd 2.0 requirements and cgroup v1 deprecation. Those matter. But the upgrade-killer teams are going to miss is buried in static pod manifests, and it has been hiding in plain sight for years.
Three Things That Break Before You Get to the Good Stuff
Static Pods Can No Longer Reference Secrets or ConfigMaps
This is the sneaky one. A bug in the kubelet has quietly allowed static pod manifests to reference Kubernetes API objects — Secrets, ConfigMaps — via fields like configMapRef and secretRef. Static pods are managed directly by the kubelet and were never designed to reach the API server. The bug is now fixed, and the PreventStaticPodAPIReferences feature gate that let you opt out has been removed entirely.
In practice: any manifest under /etc/kubernetes/manifests/ that uses these references is now rejected by the kubelet — no mirror pod is created. If that manifest is etcd.yaml or kube-apiserver.yaml, your control plane does not start. Audit before you upgrade:
grep -r "configMapRef\|secretRef" /etc/kubernetes/manifests/If you get hits, move those values to environment variables or use a different injection method. This only bites teams who inherited manifests that accidentally relied on the bug — but those teams exist, and they are going to have a bad day.
containerd 1.x Is Dead on Arrival
The v1.37 kubelet requires containerd 2.0 or later. Nodes still running containerd 1.7 will fail to start kubelet after upgrading. The Kubernetes project aligned this cutoff with the end of containerd 1.7 LTS, giving operators the full v1.36 cycle to complete the migration. That window is now closed. Check your nodes:
containerd --versionFor most standard setups, the containerd 1.7 to 2.0 migration is straightforward. The pain point is self-managed clusters and older base images where containerd 1.7 was baked into the OS package.
cgroup v1 Nodes Need an Explicit Override
cgroup v1 has been deprecated since v1.35. In v1.37, kubelet refuses to start on cgroup v1 nodes unless you explicitly set failCgroupV1: false in the kubelet configuration. This hits bare metal clusters and older VMs hardest — anything built on a CentOS 7-era base where cgroup v1 was the default. Check your cgroup version:
stat -fc %T /sys/fs/cgroup/If the output is cgroup2fs, you are fine. If it returns tmpfs, you are on cgroup v1 and need either a migration plan or the override flag before upgrading.
What Graduated to Stable
DRA Device Taints: GPU Health Management Is Now Production-Grade
Dynamic Resource Allocation’s device taint model graduates to general availability in 1.37. DRA drivers — or DeviceTaintRules you write yourself — can now taint individual devices. A NoSchedule taint blocks new pods from using a specific GPU; a NoExecute taint evicts pods already using it. Workloads that still need access can add a matching toleration directly to their ResourceClaim.
This replaces the blunt hammer of cordoning an entire node when a single GPU is overheating or being drained. For AI and ML teams running heterogeneous GPU fleets, this is the feature that turns Kubernetes into something that actually understands hardware health, not just node health.
The Rest of the Stable Graduation Class
The Metrics API — the API behind kubectl top and the Horizontal Pod Autoscaler’s CPU and memory metrics — finally reaches stable. Pod-level resource specifications (CPU, memory, hugepages set at the pod rather than per-container) also graduate, useful for sidecar-heavy deployments where the total resource envelope matters more than individual container limits.
Per-container ulimits reach stable via a new ulimits field in Container.SecurityContext, giving fine-grained control over POSIX limits like open file counts and process limits. Previously this required init containers or node-level tuning. And KYAML — a stricter, footgun-free YAML subset that kills the “Norway problem” and other silent YAML parsing bugs — is now stable output via kubectl --output=kyaml.
Alpha Features Worth Watching
The nftables story is the one to track for infrastructure teams. ipvs mode now logs a deprecation warning at kubelet startup in v1.37. The plan: disabled by default in v1.40, removed in v1.43. nftables outperforms both iptables and ipvs on large clusters and requires Linux kernel 5.13 or higher. If your cluster is on ipvs mode, this is not an emergency today, but check your kernel version and start a migration plan. Tigera’s migration guide covers the mechanics.
StatefulSet picks up a new Recreate update strategy in alpha. Where RollingUpdate gets stuck waiting for a Pod to become ready — a common deadlock when a pod holds a resource the new version needs — Recreate terminates all Pods at once, waits for full shutdown, then starts the new spec. PVCs are preserved. The trade-off is intentional downtime, but that is often preferable to a stuck rollout that requires manual intervention at 2 AM.
Pre-Upgrade Checklist
Before running the upgrade on any cluster:
- Audit static manifests:
grep -r "configMapRef|secretRef" /etc/kubernetes/manifests/ - Check containerd:
containerd --version— must be 2.0+ - Check cgroup version:
stat -fc %T /sys/fs/cgroup/— must returncgroup2fs - Check kube-proxy mode — if ipvs, note the deprecation warning and start planning
Managed Kubernetes users on EKS, GKE, or AKS get most node-side checks handled automatically, but the static pod audit applies to anyone running custom control-plane manifests. The full release blog is at kubernetes.io. The DRA device taints KEP covers the full taint model, and the ipvs deprecation KEP has the complete nftables migration timeline.
