Kubernetes v1.37 Is Coming: What You Need to Know Before You Upgrade

Kubernetes v1.37 is scheduled to land on Wednesday, August 26, 2026. As with every release, this one trims away legacy behavior, tightens security defaults, and promotes several long-running features to maturity. Here’s a concise but detailed walkthrough of the changes that matter most for keeping your clusters healthy.

Deprecations and Removals

kubectl run --filename/-f is being deprecated. Since the pod generated by kubectl run is always built purely from CLI arguments like NAME and --image, the --filename flag never actually did anything meaningful. If your scripts pass -f to kubectl run, drop it now to avoid warnings later.

Static Pods can no longer reference Secrets or ConfigMaps. Static Pods are managed directly by the kubelet and were never intended to read API resources, since they don’t go through the API server. A long-standing bug nonetheless let them pull in Secrets and ConfigMaps via fields like configMapRef and secretRef. In v1.37 that loophole is closed: such references are strictly prohibited, and the PreventStaticPodAPIReferences feature gate that used to let you opt out has been removed. Audit your static manifests in /etc/kubernetes/manifests before upgrading.

kube-proxy’s ipvs mode enters its deprecation runway. Introduced back in v1.8 to relieve iptables performance bottlenecks, ipvs mode never fully delivered — the kernel IPVS API can’t implement Services on its own, so it still falls back to iptables under the hood. The timeline:

  • v1.37 — clusters running ipvs mode log a deprecation warning at startup.
  • v1.40ipvs mode expected to be disabled by default (still selectable via feature gate).
  • v1.43 — support removed entirely.

Check which mode you’re on:

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

The recommended migration target is nftables mode.

An Ongoing Major Change: cgroup v1 on Its Way Out

Modern Linux distros and container runtimes default to cgroup v2, so cgroup v1 is being phased out. Since v1.35, the failCgroupV1 setting has defaulted to true, meaning the kubelet refuses to start on nodes still running cgroup v1. You can apply a temporary override:

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
failCgroupV1: false # temporary escape hatch only

Treat this strictly as a short-term fix. Advanced capabilities like In-Place Pod Resizing and Tiered Memory Protection depend entirely on cgroup v2, and full removal of v1 is planned for a future release.

Breaking Change: SELinuxMount Graduates to GA

SELinux volume relabeling (“SELinuxMount”) reaches GA and is enabled by default in v1.37. Instead of recursively relabeling every file, volumes are now mounted with -o context=<label> — but only when the CSI driver opts in by setting .spec.seLinuxMount: true in its CSIDriver object.

The catch: a single mount can hold only one SELinux context. Pods with different SELinux labels that share a volume on the same node — something recursive relabeling used to tolerate — may now fail to start. To preserve the old behavior for a specific workload, set seLinuxChangePolicy: Recursive in the Pod spec. Clusters that don’t use SELinux see no change at all.

See also: Mastering the Linux Command Line — Your Complete Free Training Guide

Featured Enhancements

Metrics API goes GA. After nearly nine years in Beta, metrics.k8s.io graduates to Stable. It’s the standard source of CPU and memory usage for pods and nodes, powering the Horizontal Pod Autoscaler and kubectl top. No functional changes are expected, and both v1 and v1beta1 remain usable during the transition — so you can adopt the stable API at your own pace.

Rootless kubelet (UserNS mode) reaches Beta. Traditionally node components like the kubelet run as root on the host, meaning a single vulnerability can have outsized impact. In v1.37, running the kubelet inside a Linux user namespace graduates to Beta: components behave as root within the namespace while remaining unprivileged on the host, adding a meaningful layer of isolation.

Volume Health Monitor resets to Alpha. Historically, CSI drivers had no machine-readable way to report storage failures — you’d discover problems only through failed mounts or hung I/O, then cross-reference vendor dashboards. This KEP introduces four new CSI RPCs. On the controller side, ControllerListVolumeHealth and ControllerGetVolumeHealth feed PersistentVolumeClaim.status.healthStatus. On the node side, NodeGetVolumeHealth populates Pod.status.volumeHealth and NodeGetStorageHealth fills CSINode.status.storageHealth. The error vocabulary stays simple and parsable (Inaccessible, Degraded, etc.), with reason/message fields for driver-specific detail.

Bottom Line

For most operators, three items deserve immediate attention: migrate nodes off cgroup v1, plan your exit from kube-proxy ipvs mode, and test SELinux-labeled shared-volume workloads before rolling out v1.37. Everything else is either a quiet cleanup or a welcome graduation.

The official announcement will arrive with the v1.37 CHANGELOG on release day. Note that these details reflect the current state of the release and may shift before August 26.

Avatar photo
David Cao

David is a Cloud & DevOps Enthusiast. He has years of experience as a Linux engineer. He had working experience in AMD, EMC. He likes Linux, Python, bash, and more. He is a technical blogger and a Software Engineer. He enjoys sharing his learning and contributing to open-source.

Articles: 694

Leave a Reply

Your email address will not be published. Required fields are marked *