By Kubernetes 1.37 “Garhwal” shipped August 26 with 67 enhancements. Most of them are additions — DRA hits general availability, KYAML stabilizes, Memory QoS turns on by default. Three of those 67 are not additions. Three will silently break your cluster on upgrade day if you skip the pre-flight checks. The good news: each one is a five-minute audit. The bad news: most teams will skip it anyway.
Managed clusters on EKS, GKE, and AKS are mostly insulated — providers have already defaulted to cgroup v2, containerd 2.x, and up-to-date feature sets. Self-managed, on-premises, and hybrid clusters are the danger zone. If your nodes have been running for more than a year without a fresh image rebuild, read this before you touch the upgrade button.
Breaking Change 1: cgroup v1 Nodes Will Not Start
This one has been coming since v1.25. In Kubernetes 1.37, if any node in your cluster is still on cgroup v1, the kubelet refuses to initialize. Not a warning. Not a degraded mode. A hard stop. The failCgroupV1 flag has defaulted to true since v1.35 — 1.37 simply maintains that posture.
Check before you upgrade:
stat -fc %T /sys/fs/cgroup/
# "cgroup2fs" = cgroup v2, you are fine
# "tmpfs" = cgroup v1, fix this firstThe real fix is to rebuild your nodes on a modern OS image. Ubuntu 24.04 LTS, Flatcar, and Talos all ship cgroup v2 by default. If you need a temporary escape hatch, you can set failCgroupV1: false in KubeletConfiguration — but understand the cost: that disables Memory QoS (now beta-on-by-default in 1.37), PSI metrics, and swap management. You are borrowing time, not solving the problem.
Breaking Change 2: Static Pods Can No Longer Reference Secrets or ConfigMaps
The PreventStaticPodAPIReferences feature gate was removed outright in Kubernetes 1.37. This is not a gate flip — the gate is gone. The behavior is now unconditional: any static pod manifest that references a Secret or ConfigMap via secretRef or configMapRef will fail to start after the upgrade. The error message is not helpful. The manifest looks valid. The pod just does not come up.
This mostly affects self-managed clusters that bootstrap control-plane credentials through static pod manifests — a pattern that was never officially supported but worked for years through a combination of happenstance and lenient validation. Audit now:
grep -r "secretRef\|configMapRef" /etc/kubernetes/manifests/If you find hits, move the secrets to node-local files or use init containers. There is no temporary workaround here — the gate is gone.
Breaking Change 3: 25 Feature Gates and 18 Kubelet Flags Were Removed
Kubernetes 1.37 removes 25 feature gates and 18 kubelet configuration flags. If any component in your cluster — a Helm chart value, a kustomization, an operator config — starts with a removed gate in its arguments, that component refuses to start. The removed gates include SidecarContainers, JobSuccessPolicy, PodLifecycleSleepAction, and SchedulerQueueingHints, among others.
The kubelet flag removal is tied to KubeletCgroupDriverFromCRI, which graduated to GA in v1.36. Kubelet now detects the cgroup driver from the container runtime automatically — the manual flags are gone. If anything in your bootstrapping pipeline still sets those flags explicitly, it will fail.
grep -rE "SidecarContainers|JobSuccessPolicy|PodLifecycleSleepAction|SchedulerQueueingHints" \
/etc/kubernetes/ ~/.kube/ ./helm-values/Watch: IPVS Deprecation Clock Is Now Running
Not a blocker in 1.37, but worth noting: kube-proxy’s IPVS mode now logs a deprecation warning on startup. The timeline is disabled by default in 1.40 and removed in 1.43. The successor is nftables — a modern, map-based API with incremental updates that eliminates the dual-maintenance burden that motivated the deprecation. You have roughly 18 months. Start planning the migration now rather than scrambling when 1.40 lands.
The Good Stuff in Kubernetes 1.37
Once you clear the upgrade blockers, 1.37 is a legitimately strong release for GPU and AI workloads.
DRA Extended Resource support hits GA — the mechanism that lets DRA drivers satisfy existing example.com/gpu-style requests without requiring a separate device plugin. Existing GPU workloads can migrate to DRA drivers without touching a single pod manifest. Device taints and tolerations also reach GA, giving platform teams a proper hardware lifecycle model: mark degraded GPUs, block new scheduling, evict existing pods cleanly.
KYAML stabilizes — kubectl get -o kyaml is now production-ready with conformance testing complete. It fixes the “Norway bug” (where NO gets parsed as false) and other YAML footguns that have caused quiet incidents for years. Memory QoS moves to beta and enables by default — but only on cgroup v2 clusters. Which brings us back to where we started.
Before You Upgrade: The Five-Minute Checklist
- Run
stat -fc %T /sys/fs/cgroup/on every node type. Fix any cgroup v1 nodes first. - Audit
/etc/kubernetes/manifests/forsecretRefandconfigMapRefin static pods. - Search your Helm values, kustomizations, and operator configs for removed feature gates.
- Check for IPVS usage in kube-proxy config — note the deprecation, plan the migration.
- Verify containerd is on version 2.0 or higher on all nodes.
For managed clusters, check availability before scheduling the upgrade: aws eks describe-addon-versions, az aks get-upgrades, or the GKE server config API. Managed providers typically trail the open-source release by several weeks. Full release notes are on the Kubernetes blog.
Kubernetes 1.37 is a good release. Upgrade blockers tend to feel unfair until you realize most of them were announced two or three versions ago and the deprecation notices were sitting in the changelog the whole time. Run the checklist.
