Kubernetes V1.37 Sneak Peek: Three Deprecations and a Pre-Upgrade Checklist

  • 2026/8/2
  • 5-minute read
Table of Contents

The official blog just published a Kubernetes v1.37 Sneak Peek. GA is planned for Wednesday, 26 August 2026

Treat it less like a glossary dump and more like a pre-upgrade checklist: which commands die, which policy suddenly gets strict, which capabilities finally stabilize. Below: landmines first, then the good stuff. Details still follow the real CHANGELOG

What’s being deprecated?

What bites on upgrade is often not new features — it’s flags and modes going away. Three items in the v1.37 preview to check first

1. kubectl run -f is deprecated

Pods from kubectl run only honor CLI args (name, image, …). Adding -f makes people think it can consume a full manifest like apply. Upstream plans to deprecate that flag

If scripts still have kubectl run -f ..., switch to kubectl apply -f, or use a proper Deployment / Job manifest

2. Static Pods can no longer reference Secret / ConfigMap

Static Pod: started by kubelet from a local manifest, not created via the API Server scheduler. Common for control-plane components (e.g. apiserver/etcd under /etc/kubernetes/manifests). What you see in the API is often a mirror Pod; lifecycle still belongs to the local kubelet

Static Pods aren’t created through the API Server, so they shouldn’t read API objects directly. An old loophole is closing: from v1.37, referencing Secret/ConfigMap via fields like secretRef / configMapRef is strictly forbidden; the feature gate that allowed it goes away too

Concrete action: audit /etc/kubernetes/manifests (and any custom static-pod dirs). Still mounting Secret/ConfigMap? Move to a normal Pod/DaemonSet via the API, or accept static boundaries and put config on local files / host paths

3. kube-proxy IPVS mode starts emitting deprecation warnings

IPVS landed to ease iptables scale pain. The kernel IPVS API alone can’t carry full Service semantics, and IPVS mode still leans on iptables underneath — the community has written this up before

Rough timeline in the peek: warn on start now → around v1.40 default off (maybe still toggleable via feature gate) → around v1.43 remove. Confirm whether you’re still on IPVS:

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

If it’s mode: ipvs, plan a move back to iptables, or evaluate nftables / the current main path — don’t wait to get cut hard

Broader trend: cgroup v1 keeps exiting

Since v1.35, kubelet defaults to failCgroupV1: true. Nodes still on cgroup v1 may fail to start kubelet unless you temporarily override:

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
failCgroupV1: false  # short-term bridge only

v1.37 still allows the switch, but the message is clear: short-term patch — move to cgroup v2. In-place resource resize, memory QoS, and friends are tied to v2; riding false only gets harder

Breaking change: SELinuxMount likely GA

If the cluster runs SELinux, walk this path carefully

SELinuxMount is expected to GA and default on in v1.37. For volumes with CSIDriver.spec.seLinuxMount: true, labeling uses mount options -o context=... instead of recursive relabel of the whole volume. One mount point, one SELinux context — Pods with different labels that used to “share” a volume via recursive labeling may fail to start

Workloads that need the old behavior can set seLinuxChangePolicy: Recursive on the Pod. Clusters without SELinux mostly won’t notice; SELinux clusters with multi-label shared volumes should validate in a test environment before upgrade

Three signals worth watching

After the landmines, three direction signals — observability, node security boundary, orchestratable storage faults

1. metrics.k8s.io finally GA

After nearly nine years in Beta, metrics.k8s.io is expected to go Stable in v1.37. It’s the base for HPA and kubectl top. Functionally no big rewrite expected; both v1 and v1beta1 should work during transition so you can cut over on your schedule

2. Rootless kubelet (UserNS) to Beta

Node components (including kubelet) often run as host root — large blast radius. v1.37 is expected to push Kubelet in User Namespace (Rootless Mode) to Beta: node components are root inside a Linux user namespace, while the host side can be an unprivileged user — another isolation layer, smaller impact from component CVEs

Good for environments that care about node security boundaries and can track Beta; production should weigh distro and runtime maturity, not flip everything at once

3. Volume Health Monitor back to Alpha

When storage fails, you used to reverse-engineer from mount failures / stuck IO and vendor consoles. This round resets the volume health KEP to Alpha (there was an earlier implementation): a set of CSI RPCs, results written back to the API — PVC status.healthStatus, Pod status.volumeHealth, CSINode status.storageHealth

Error vocabulary skews machine-readable (e.g. Inaccessible, Degraded), details in reason/message; controller-side vs node-side reports stay separate. Direction: make storage faults orchestratable — still Alpha; follow driver progress, don’t make it your only production alert source yet

Five minutes before you upgrade

  1. Any kubectl run -f left in scripts?
  2. Do Static Pods still mount Secret / ConfigMap?
  3. Is kube-proxy still on ipvs?
  4. Are nodes still held up by failCgroupV1: false on cgroup v1?
  5. SELinux on: any multi-label sharing of the same volume?

The sneak peek’s value isn’t memorizing names — it’s putting the landmines on the calendar before the upgrade window. What actually hurts is usually Static Pods, IPVS, and SELinux mounts — new features can wait; check those three soon

Final capabilities and dates still follow the 26 August CHANGELOG.

Source: Kubernetes v1.37 Sneak Peek

Related Posts

Tech KubernetesCloud NativeOpsUpgrade

comments