Kubernetes 1.37: What Actually Needs Your Attention

Published August 10, 2026, ahead of the August 26 GA date. This post is based on the pre-GA sneak peek. A few KEPs typically drop out of the milestone between now and release, so we'll revisit this post after GA and correct anything that changed.

Picture this: a distributed training job on 64 GPUs, three days in, checkpoints landing on a shared NFS-backed volume every 20 minutes. On day three, the loss curve goes strange. Hours of debugging later, the cause turns up: one worker held on to a stale NFS file handle after a brief network blip and kept writing through it, silently truncating the checkpoint on the next write. Kubernetes never knew anything was wrong. There's no mechanism for a CSI driver to report a storage-level fault back to the API server.

Worth being upfront: no single company signed off on that story. It's a composite, drawn from the kind of failure GPU-cluster operators keep describing in storage and MLOps circles. The failure class behind it, though, silent storage corruption that Kubernetes never sees, is real and well documented. It's exactly what one of the KEPs in this release is trying to fix.

That KEP is Volume Health Monitor. It was first attempted back in 2021, didn't stick, and got shelved. Now it's coming back, and its return is a small piece of a larger pattern: Kubernetes is slowly catching up to the fact that clusters run GPU training jobs and AI agents now, not just stateless web services. You'll see that pattern again in the Rootless Mode section below. That's the thesis of this post. Most of what follows isn't urgent. One item is.

A note up front: the official sneak peek was published on July 31, and GA is expected on August 26. As with every release, some of what's described here may change before then. A few KEPs (manifest-based RBAC authorization, the DRA ClusterResourceClaimTemplate) have already dropped out of the 1.37 milestone as of this writing, and that number could grow. Base your upgrade plan on the official release notes after GA, not on this post.

The one-line summary: find your cgroup v1 nodes. Everything else on this page can wait.

What deserves the most attention: cgroup v1

This is the only item on this page that genuinely demands action. Since v1.35, failCgroupV1 has defaulted to true, meaning the kubelet no longer starts on nodes still running cgroup v1, unless you set an explicit override:

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
failCgroupV1: false # temporary, not a permanent fix

On a single node, checking which side you're on takes five seconds:

stat -fc %T /sys/fs/cgroup/

cgroup2fs means you're fine. tmpfs means you're still on v1.

That one-liner doesn't scale to a 200-node fleet, though. For a cluster-wide check, run it as a DaemonSet and collect the output, or loop it through every node with kubectl debug:

for node in $(kubectl get nodes -o jsonpath='{.items[*].metadata.name}'); do
echo -n "$node: "
kubectl debug node/$node -it --image=busybox --quiet -- \
chroot /host stat -fc %T /sys/fs/cgroup/ 2>/dev/null
done

If you're on a managed provider, the answer is usually determined by your node image, not by anything you configured directly:

GKE is worth flagging specifically: 1.26+ only changes the default for new nodes. Existing node pools stay on cgroup v1 until you migrate them explicitly, and GKE plans to auto-migrate remaining cgroup v1 clusters starting at 1.33.

Why this matters: advanced resource management features like In-Place Pod Resizing and Tiered Memory Protection now depend entirely on v2, and so does Memory QoS (KEP-2570), which reaches Beta in 1.37 with default settings enabled. Staying on cgroup v1 means missing all of it, and maintaining two separate code paths isn't sustainable for Kubernetes either. This isn't a "maybe someday" change. It's a door that's closing for good in an upcoming release.

kube-proxy's ipvs mode is being deprecated

If you run Cilium or another CNI in kube-proxy-replacement mode, this section doesn't apply to you. Skip ahead to the next one.

For everyone else: the story behind ipvs mode is worth knowing. It was added in v1.8 (2017) to solve iptables performance bottlenecks, but the kernel's ipvs API alone can't fully implement Service semantics, so ipvs mode still leans on iptables rules underneath. The KEP's own line sums it up: "the ipvs mode of kube-proxy will not save us." nftables now genuinely handles this cleanly, which is why kube-proxy's ipvs deprecation makes sense.

The timeline: in 1.37, only a warning gets logged. By 1.40, it's off by default. By 1.43, it's removed entirely. There's no need to rush today, but you should know which mode you're running:

kubectl -n kube-system get configmap kube-proxy -o jsonpath='{.data.config\.conf}' | grep 'mode:'

An empty result here isn't an error. It means the mode field is unset, which defaults to iptables. Only mode: ipvs puts you on the deprecation clock.

Worth knowing: this isn't really "something dying," it's "something moving." The same 1.37 cycle lays alpha-stage groundwork (KEP-5343) for nftables to eventually become kube-proxy's default backend outright, not just the recommended replacement for ipvs. That's still early and not something to act on yet, but it's the direction the whole subsystem is heading.

If you're on ipvs, put testing a migration to nftables on a test cluster on your calendar now. No need to rush, but don't forget either.

A small but important bug fix for static pods

Here's a detail worth knowing: static pods, by definition, never go through the API server at all. The kubelet reads them directly from a manifest file. So in theory, they should never have been able to reference a Secret or ConfigMap. But a bug quietly allowed exactly that for years. 1.37 closes that door: references like configMapRef/secretRef are now strictly rejected, and the PreventStaticPodAPIReferences feature gate that previously let you opt out of the restriction has been removed.

# This worked before 1.37 (thanks to the bug) but will no longer work:
apiVersion: v1
kind: Pod
metadata:
name: static-pod-example
spec:
containers:
- name: app
image: my-app:latest
envFrom:
- configMapRef:
name: some-configmap

If your control plane nodes (under /etc/kubernetes/manifests/) have anything like this, clean it up before upgrading. You probably don't, but it's a cheap check. You can follow the original discussion in kubernetes/kubernetes#140226.

Related cleanup in the same cycle: kubectl run --filename/-f is also being deprecated. kubectl run already builds a pod purely from CLI arguments, so the -f flag never quite fit that flow. If any of your scripts use it (unlikely), finding and replacing it takes about as long as reading this paragraph.

SELinuxMount is graduating to GA, but it only concerns some of you

If you don't use SELinux, skip this section entirely. You're genuinely unaffected.

For those who do: the old method (recursive relabeling) tagged every single inode on a volume one by one, which could take minutes on large disks when a container started. The new method sets a single context label at the mount level, bringing that down to milliseconds. It's expected to reach GA and ship enabled by default, but it only activates if your CSI driver has opted in via CSIDriver.spec.seLinuxMount: true. Kubernetes' own writeup on the SELinux volume-labeling changes covers the mechanics in more depth.

Check which of your drivers have opted in:

kubectl get csidriver -o custom-columns=NAME:.metadata.name,SELINUX:.spec.seLinuxMount

Here's the hidden risk: on an opted-in driver, pods with different SELinux labels sharing the same volume on the same node, which used to work fine under recursive relabeling, may now fail to start. If you have a multi-tenant shared-PVC scenario, test this. Setting seLinuxChangePolicy: Recursive restores the old behavior, but then you're also giving up the performance gain.

Kubelet Rootless Mode is graduating to Beta

On its own, this Rootless Mode KEP might seem unremarkable: node components can now run as an unprivileged user inside a user namespace on the host, instead of running as root, while still behaving as root within the namespace. Classic defense-in-depth.

The timing is worth noting, though. Clusters no longer only run stateless "take a request, return a response" services. There are AI agents that can execute code, make requests to external APIs, and carry credentials across multiple domains. A point often raised in the security community: when a workload like that is compromised, what the attacker gains isn't just a network socket, it's the agent's delegated authority. Rootless Mode doesn't solve that on its own, but it hardens one more layer of defense against it.

There's nothing concrete to do about this today. Beta doesn't mean production-ready. Add it to the watch list if you run multi-tenant clusters or workloads with a low trust boundary.

Volume Health Monitor: the gap from the start of this post

Back to the checkpoint scenario from the opening: Volume Health Monitor is trying to close exactly that gap. There was never a machine-readable API for CSI drivers to say "this volume is corrupted." Problems only surfaced once a mount failed or I/O hung.

First attempted in v1.21, it's resetting to Alpha again in 1.37 with four new CSI RPCs: ControllerListVolumeHealth, ControllerGetVolumeHealth, NodeGetVolumeHealth, NodeGetStorageHealth. Results get written to PVC.status.healthStatus, Pod.status.volumeHealth, and CSINode.status.storageHealth. Error codes are deliberately kept simple (Inaccessible, Degraded), with driver-specific detail available in the reason/message fields. Controller-side and node-side reports are intentionally kept independent and shown separately.

Since it's still Alpha, it won't solve a checkpoint problem in your production cluster today, and your CSI driver would also need to implement these RPCs. Still, the CNCF's Kubernetes AI Conformance Program, an opt-in certification track, now requires workload-aware scheduling for any platform seeking certification under it. For the platforms in that program, this kind of storage visibility work is clearly becoming a real requirement, not just a nice-to-have. If storage consistency is a real production problem for you, piloting this once it reaches Beta could be worthwhile.

Also stable in 1.37: KYAML, Pod Certificates, and Cluster Trust Bundles

A few graduations that don't need their own section but deserve more than a footnote.

Of the three, KYAML (KEP-5295) is probably the one you'll actually touch. It's a stricter YAML dialect for kubectl output: curly braces for maps, square brackets for lists, double-quoted strings, no more silent type coercion (the "Norway problem," where an unquoted NO gets parsed as boolean false). Every KYAML file is valid YAML, so nothing breaks if you keep using regular YAML everywhere else. Worth trying once, just run kubectl get -o kyaml.

Less flashy, but worth knowing about: Pod Certificates (KEP-4317) and Cluster Trust Bundles (KEP-3257) reach GA together. The pair gives pods a native way to request short-lived X.509 certificates for mTLS, without reaching for cert-manager or SPIFFE/SPIRE. The kubelet requests a certificate on the pod's behalf via a PodCertificateRequest, and the credential bundle lands straight in the pod's filesystem. It pairs naturally with the delegated-authority point from the Rootless Mode section above - native, short-lived workload identity is one more way to shrink what an attacker walks away with.

And then there's Metrics API (metrics.k8s.io), finally Stable after nearly nine years in Beta. HPA and kubectl top already depended on it, nothing in its behavior changes, v1beta1 keeps working alongside it. Nothing to do here, genuinely.

Wrapping up

The one thing you genuinely need to do today is find your cgroup v1 nodes. Most of the rest falls into the "know it, keep it on the calendar" category, per the summary table near the top of this post.

Taken individually, 1.37's headlines aren't exciting: a deprecation, a bug fix, a nine-year-old Beta API finally reaching GA. But Volume Health Monitor's return and Rootless Mode's graduation to Beta fit the thesis from the opening. Kubernetes is slowly catching up to the reality that clusters now run GPU training jobs and AI agents, not just web services.

GA is set for August 26. This post will be revisited after that date to correct anything that changed. Until then, you can follow the authoritative list on kubernetes.io/blog.