Kubernetes 1.37 deprecates IPVS, flips SELinuxMount on by default, and drops static pod secrets

26 August 2026. Kubernetes 1.37 reaches general availability. Nine years. That is how long the metrics.k8s.io API spent in beta before graduating to stable in this release. Three. That is how many breaking changes a cluster operator must audit before upgrading, and none of them touch the application API: all of them live at the node level.

The cycle shipped roughly 86 tracked enhancements, with 16 graduating to stable and 22 landing as first-time alpha features, according to pre-release coverage from Cloudsmith and independent trackers. The point release looks boring on paper; it is not, because the CNCF now puts Kubernetes production adoption at 82% of organizations that use containers at all, up from 66% two years ago. When four out of five container shops run the software, a networking deprecation is not a footnote: it is a maintenance window for thousands of platform teams.

What graduates to stable

The most symbolic promotion is metrics.k8s.io, the core metrics API that kubectl top and the Horizontal Pod Autoscaler depend on. It leaves beta after almost a decade, a longevity record that says something about how conservative the project has become about locking in an API millions of clusters already rely on informally.

SELinuxMount also reaches GA, and critically, ships enabled by default. Instead of relabeling a volume file by file on every mount, the kubelet now mounts with a context=<label> option and applies the whole SELinux label in a single operation. That is a real win on large volumes, but it changes runtime behavior on any cluster with SELinux in enforcing mode. Several pre-release writeups flag it explicitly as a feature that can break existing workloads.

The remaining graduations are less flashy but consistent: KYAML output from kubectl becomes a stable format, pod-level resource requests graduate to stable, and device-level taints and tolerations for Dynamic Resource Allocation make GPU scheduling a first-class citizen rather than a bolt-on.

Three breaking changes to handle

First: kubectl run loses its --filename flag. The command is meant to generate a pod from CLI arguments, not from a manifest, and the project is finally enforcing that split. Any script that passed kubectl run -f must switch to kubectl apply or kubectl create.

Second: static pods can no longer reference secrets or config maps. The PreventStaticPodAPIReferences feature gate, which allowed the restriction to be toggled, has been removed outright: the behavior is now unconditional. Any static pod manifest that pulled its credentials from a secretRef or configMapRef will fail to start after the upgrade, full stop.

Third, and the longest tail: kube-proxy’s IPVS mode is formally deprecated under KEP-5495, and nftables becomes the default backend for new installs. IPVS has been a recommended mode since it arrived as an alternative to iptables in Kubernetes 1.11, thanks to its lower CPU overhead at scale. Removal is not scheduled until v1.43, several releases away, but the clock is running: a cluster standardized on IPVS needs a migration plan to nftables.

The quiet hardening of the node runtime

Under those three visible changes, two constraints harden nodes without fanfare. cgroup v2 becomes effectively mandatory: as of 1.37, the kubelet refuses to initialize on a cgroup v1 node by default unless an operator explicitly overrides it. And the end of containerd 1.x support means 1.37 requires containerd 2.0 or later, 1.35 having been the last release to tolerate the 1.x branch.

The rootless kubelet also advances to beta: the node agent runs without root privileges, narrowing the attack surface of a component that touches everything on the machine. Combined with the SELinuxMount default flip, a meaningful share of this release’s upgrade risk sits in node-level runtime behavior rather than the API surface teams are used to auditing.

The containerd 2.0 requirement is worth reading closely. 1.35 was the last release to support containerd 1.x, and the kubelet flag removal in 1.37 aligns with the end of containerd v1.7 support. Operators should run the kubelet_cri_losing_support metric checks on their current clusters to identify any node still on the old runtime before targeting 1.37.

Why this point release matters

The 1.37 timeline followed the three-times-a-year cadence the project adopted to make each cycle less rushed: first alpha on 10 June 2026, enhancements freeze on 17 June, code freeze on 22-23 July, docs freeze on 5-6 August, rc.0 on 6 August, rc.1 on 19 August. No slip: the project is working the way it was redesigned to work.

The timing alongside the AI infrastructure boom is not a coincidence. The CNCF annual survey published in January 2026 frames Kubernetes as the de facto operating system for AI workloads: two thirds of organizations running generative models report using it for inference. An inference pod often bundles a model server with sidecars for batching or telemetry; being able to set resource limits at the pod level, instead of summing per-container guesses, makes capacity planning on GPU nodes noticeably less error-prone. That is a very different workload profile from the stateless web services Kubernetes was originally built to orchestrate, and it explains why Dynamic Resource Allocation and device-level GPU scheduling keep graduating release after release.

The most instructive precedent is dockershim, the shim that let the kubelet talk to Docker Engine directly: removed in Kubernetes 1.24 in 2022 after more than a year of notice, it still caught teams off guard because so many CI pipelines assumed Docker was always present under the hood. PodSecurityPolicy followed the same slope, deprecated for several releases before removal in 1.25 in favor of Pod Security Admission. The IPVS deprecation follows that exact path: a formal notice, a multi-release runway to v1.43, and a documented migration to nftables. The more abrupt removals, static pod secrets and the SELinuxMount flip, are closer to the PodSecurityPolicy replacement: they force manifest fixes without delay.

The pre-upgrade checklist

# 1. Audit static pod manifests for secret/configMap references
grep -R "secretRef\|configMapRef" /etc/kubernetes/manifests/ 2>/dev/null

# 2. Confirm every node is on cgroup v2
stat -fc %T /sys/fs/cgroup/        # should print cgroup2fs

# 3. Identify the current kube-proxy mode before planning the IPVS -> nftables move
kubectl get configmap kube-proxy -n kube-system -o yaml | grep -i mode

# 4. If SELinux is enforcing, test SELinuxMount on a staging node first
getenforce                          # Enforcing or Permissive?

Those four commands cover the bulk of the risk. The classic trap of this release is not in the application manifests, it is in the node itself.

Verdict

If your cluster runs IPVS at scale for CPU cost reasons, you have time: removal is not scheduled before v1.43. But open the migration to nftables now and test it on a staging cluster, rather than waiting for a deprecation to become an emergency.

If your nodes run RHEL, Fedora CoreOS or any SELinux-enforcing distribution, the SELinuxMount default flip is the first risk to measure: test it on an isolated node before you feel it in production. And if you run static pods for the control plane, reread every manifest for secretRef or configMapRef: this release no longer tolerates the pattern, with no exception.

The simple rule stands: audit the node before you audit the API. All three breaking changes in Kubernetes 1.37 are fixable ahead of time, provided you look in the right place. Treat the upgrade as a node-runtime change first and an API change second, and the risk collapses to a morning of checks rather than a weekend of firefighting.

References

• Kubernetes Blog — v1.37 Sneak Peek, 31 July 2026
• Kubernetes Contributors — v1.37 Release Information
• shattered.io — Kubernetes 1.37 Release: 3 Breaking Changes to Fix, 25 August 2026
• CNCF Annual Cloud Native Survey, January 2026