The first time a kubelet refused to start on one of our nodes because cgroup v2 was not there, I was two coffees in and the on-call phone was still in the drawer. It was fine. It was also exactly the kind of surprise I do not want on a Friday. The Kubernetes release team published the v1.37 sneak peek on July 31, and the whole point of that post is to save you from a version of my morning. It lists what is being deprecated, what is being removed, and what is being cleaned up before the release lands, so the platform team gets to plan the migration instead of chasing it.
What the sneak peek actually lists
The post is a preview, and the release team is explicit that the details may still change before the actual v1.37 date. What it does commit to is a short list of clean-up work. kubectl run is losing its --filename (or -f) flag, because the generated pod is meant to come from CLI arguments like NAME and --image, not from a manifest file. Static Pods can no longer reference Secrets or ConfigMaps through configMapRef or secretRef, and the PreventStaticPodAPIReferences feature gate that used to guard that behaviour has been removed. And kube-proxy support for ipvs mode is on a three-release deprecation clock.
The kube-proxy ipvs timeline you can actually diary
If any of your clusters run mode: ipvs, this is the beat to circle. In v1.37, kube-proxy will log a deprecation warning at startup when it sees that configuration. In v1.40, ipvs mode is expected to be disabled by default and only selectable through a feature gate. In v1.43, support is expected to be removed. The plan is tracked in KEP-5495. The release team even hands you the diagnostic:
kubectl -n kube-system get configmap kube-proxy -o jsonpath='{.data.config\.conf}' | grep 'mode:'
If that prints mode: ipvs, you have a project to schedule, not a fire to fight. The friendlier fact about a deprecation clock this long is that you almost never have to do the migration under time pressure. The harder fact is that "we'll do it later" tends to survive right up until the release that removes it.
Static Pods and the API resources rule
This one is quieter but worth flagging for anyone who runs custom static-pod manifests. Static Pods were never supposed to reach into the API server for Secrets or ConfigMaps, because they are not created through the API server in the first place. In v1.37 the release cleans that up: configMapRef and secretRef fields stop resolving in a Static Pod, and the feature gate that used to enforce the restriction is gone. If you have manifests in /etc/kubernetes/manifests that reach for a Secret name, now is the time to inline the value or move the workload off the static-pod pattern.
The cgroup v1 tripwire is already live
Not new in v1.37, but the sneak peek reminds you it is still humming. Since v1.35, failCgroupV1 defaults to true, which means kubelet will refuse to start on a cgroup v1 node unless you override it. The escape hatch looks like this:
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
failCgroupV1: false # temporary override
The release team calls this a short-term fix, and I would take them at their word. Advanced features such as In-Place Pod Resizing and Tiered Memory Protection depend on cgroup v2, so an ageing node on v1 is not only a warning line in the kubelet log, it is a feature ceiling you will run into the next time somebody asks for either.
The DX bit I am watching
The kubectl run --filename change is small. It is also the shape of thing that catches you only in a script you wrote three years ago and never touched. If your onboarding docs or a bootstrap script pipe a file into kubectl run -f, that is a five-minute rewrite today and a puzzling failure on the day the cluster upgrades.
What I am doing before v1.37 lands
Three things, none of them heroic. Grep the fleet for mode: ipvs in the kube-proxy configmap and open a ticket per cluster. Audit static-pod manifests under /etc/kubernetes/manifests for any configMapRef or secretRef. And take one more pass through the nodes to make sure nothing is still limping on cgroup v1 with the failCgroupV1 override taped over it. The whole reason the release team publishes a sneak peek is so this list becomes routine instead of a series of small surprises, and the honest gain is that a v1.37 upgrade day gets to feel boring. That is my favourite kind of release day.
Top comments (0)