Kubernetes 1.37 Released: Three Upgrade Blockers for Platform Teams

Marcus Chen Staff Engineer (Backend & Cloud), YuSMP Group · Works with US and EU engineering teams on Kubernetes, cloud migration and platform architecture

Release in brief

Breaking change 1: IPVS mode is now formally deprecated

The IPVS proxy mode for kube-proxy has operated as a supported option since Kubernetes 1.8. In v1.37, the project formally deprecates it under KEP-5495. If kube-proxy starts in IPVS mode, it will now emit a deprecation warning on startup. The cluster continues to function, but the warning is not cosmetic — it marks the beginning of a removal timeline.

The planned schedule is: v1.40 — IPVS disabled by default behind a feature gate; v1.43 — IPVS removed entirely. Given that Kubernetes releases four versions per year, v1.43 is roughly three years from now. That is enough runway to migrate, but not enough to defer the planning conversation.

The reason for deprecation is architectural: the kernel IPVS API alone cannot fully implement Kubernetes Services. The current implementation layers iptables rules on top of IPVS, combining the operational complexity of both without the consistency of either. The recommended migration targets are the iptables mode (the current default) or the newer nftables mode, which was promoted to GA in v1.35 and handles large-cluster rule-sets more efficiently than iptables.

To check which mode your cluster runs: kubectl get cm -n kube-system kube-proxy -o yaml | grep mode. If the output shows mode: ipvs, schedule the migration before v1.40.

Breaking change 2: cgroup v1 nodes refuse to start kubelet by default

This one has been in progress since v1.35, but v1.37 extends the enforcement surface. Since v1.35, failCgroupV1 defaults to true in KubeletConfiguration. A kubelet on a cgroup v1 node will not start unless the operator explicitly sets failCgroupV1: false as a temporary override.

In v1.37, the legacy --cgroup-driver and --cgroup-root command-line flags are removed entirely. Any node startup script, systemd unit, or tooling that passes these flags directly to kubelet will now fail to parse. The replacement is the KubeletCgroupDriverFromCRI feature gate (stable since v1.36), which instructs kubelet to detect the cgroup driver from the container runtime rather than accepting it as a flag.

Before upgrading, run stat -fc %T /sys/fs/cgroup on each node. If the output is cgroup2fs, the node runs cgroup v2 and is unaffected. If the output is tmpfs, the node is still on cgroup v1 and will require either a kernel upgrade or the temporary failCgroupV1: false escape hatch in KubeletConfiguration. Most modern Linux distributions default to cgroup v2 as of their 2024+ releases; the nodes most likely to be affected are long-running bare-metal or on-premises hosts that have not been reprovisioned recently.

Breaking change 3: static Pods can no longer reference Secrets or ConfigMaps

Static Pods — manifests placed directly on a node’s filesystem and managed by kubelet rather than the API server — can no longer use configMapRef or secretRef in env or envFrom fields to pull in Secret and ConfigMap values. The feature gate PreventStaticPodAPIReferences that previously controlled this behavior has been removed, making the restriction permanent and unconditional.

The rationale is consistency and security: static Pods run before the API server is necessarily reachable (they are often used to bootstrap control plane components), so allowing them to reference API objects creates a timing dependency that the kubelet cannot reliably resolve. The restriction was enforced as an alpha gate in v1.34, graduated through beta, and is now locked.

This is the most operationally surprising of the three changes because static Pod manifests are often maintained outside the main Helm chart or GitOps repository and are easy to overlook in a pre-upgrade audit. Run grep -r "configMapRef\|secretRef" /etc/kubernetes/manifests/ on each node to identify affected manifests. Secrets should be mounted as volumes or passed through the node’s environment instead.

What graduated to stable

Beyond the breaking changes, v1.37 delivers meaningful improvements for AI/ML and general-purpose workloads:

• DRA device taints and tolerations (GA): Dynamic Resource Allocation can now mark a device as “tainted” (degraded GPU, failing NIC) and Pods can express tolerations for those taints, mirroring the familiar node taint/toleration model. This closes a significant gap for GPU-heavy clusters where hardware health is uneven.
• Pod-level resource requests and limits (stable): Setting CPU and memory at the Pod level rather than the container level is now a stable API, simplifying resource accounting for multi-container workloads.
• Metrics API (GA): The metrics.k8s.io API, which backs kubectl top and the HPA, moves to stable with improved server error responses.
• GPU partitioning (KEP-4815, alpha → beta track): The ability to split a single physical GPU into multiple allocatable logical slices via DRA continues to mature. It is still not GA in v1.37, but beta landing is expected in v1.38.

What it means for US & EU software teams

For teams running workloads on self-managed Kubernetes, the operational calculus in v1.37 is similar to v1.35 and v1.36: the core platform has become more opinionated about acceptable configurations, and the cost of ignoring deprecation warnings is now one release cycle shorter than it was before. Three observations:

The cgroup v2 migration is no longer optional in planning. Kubernetes is closing the door on cgroup v1 progressively and deliberately. If your infrastructure roadmap still treats cgroup v2 as a “future consideration,” v1.37 should move that conversation to the next sprint. Managed cloud distributions have largely handled this for their customers; self-managed and on-premises clusters carry the burden themselves.

Static Pod hygiene matters more now. The static Pod restriction is the most likely source of silent failures on upgrade day because static Pod manifests often live outside the GitOps workflow that governs everything else. A pre-upgrade manifest audit is not optional — it takes ten minutes and prevents a kubelet that fails to start on a control plane node.

The DRA graduation path signals where Kubernetes GPU scheduling is headed. The taint/toleration model for accelerators graduating to GA in v1.37, combined with GPU partitioning tracking toward beta, means that Kubernetes is becoming the scheduler of record for heterogeneous compute — not just for general-purpose workloads. For teams building AI/ML pipelines on Kubernetes, it is worth tracking the DRA roadmap directly rather than relying on managed distribution defaults.

Pre-upgrade checklist for v1.37

Run these checks before promoting any node to v1.37:

1. Check proxy mode. kubectl get cm -n kube-system kube-proxy -o yaml | grep mode. If mode: ipvs, plan migration to iptables or nftables; IPVS removal is three releases away (v1.43).
2. Verify cgroup version on every node. stat -fc %T /sys/fs/cgroup. Output tmpfs = cgroup v1 = kubelet will not start without failCgroupV1: false override in KubeletConfiguration.
3. Remove legacy kubelet flags from node startup. Search systemd units and cloud-init scripts for --cgroup-driver or --cgroup-root. These flags are removed in v1.37 and will cause kubelet to fail to parse.
4. Audit static Pod manifests. grep -r "configMapRef\|secretRef" /etc/kubernetes/manifests/ on each node. Move Secret references to volume mounts or node-level environment variables.
5. Confirm containerd version. containerd --version. Must be 2.0.0 or higher (1.x is unsupported since v1.36).
6. Review DRA ResourceClaim usage. If you use DRA alpha features from v1.36, check the CHANGELOG for alpha API changes that may require manifest updates.
7. Test in a non-production cluster first. Run the checklist, upgrade the cluster, verify that kubectl top nodes and kubectl top pods return correct values (Metrics API GA behavior may differ from prior beta behavior in edge cases).

Frequently asked questions

Sources

Kubernetes.io — Kubernetes v1.37 Sneak Peek (official blog, July 31, 2026)
GitHub — kubernetes/sig-release release-1.37 schedule (August 26, 2026 confirmed GA date)
GitHub — Kubernetes CHANGELOG-1.37.md (official changelog)