As we get closer to the release date for Kubernetes v1.37, the project develops and matures, features may be deprecated, removed, or replaced with better ones for the project's overall health. This blog outlines some of the planned changes for the Kubernetes v1.37 release that the release team feels you should be aware of for the continued maintenance of your Kubernetes environment and keeping up to date with the latest changes. The information below reflects the current status of the v1.37 release and may change before the actual release date.
Deprecations and removals for Kubernetes v1.37
Kubectl: kubectl run --filename/-f
to be deprecated
The --filename
(or -f
) flag for kubectl run
is being deprecated as the generated pod is always built purely from CLI arguments like NAME
and --image
.
See kubernetes/kubernetes#138671 for the original issue and discussion.
Kubelet: Static Pods can no longer reference Secrets or ConfigMaps
Static Pods were never meant to read API resources directly, since they aren't created through the API server — but a bug let them reference Secrets or ConfigMaps via fields like configMapRef
or secretRef
. That bug is now fixed: as of v1.37 these references are strictly prohibited, and the PreventStaticPodAPIReferences
feature gate that previously let you opt out of the restriction has been removed.
See kubernetes/kubernetes#140226 for the original issue and discussion.
Deprecating kube-proxy's support for ipvs
mode
kube-proxy
support for ipvs
mode was introduced in v1.8 to resolve iptables
performance bottlenecks. However, since the kernel ipvs
API alone cannot fully implement Kubernetes Services, ipvs
mode continues to use iptables
underneath (KEP-3866, "The ipvs mode of kube-proxy will not save us").
Clusters running kube-proxy
in ipvs mode (or mode: ipvs in KubeProxyConfiguration) would now be logging a deprecation warning on startup. The deprecation timeline looks like this:
- By v1.40,
ipvs
mode forkube-proxy
is expected to be disabled by default (still selectable via the feature gate) - By v1.43, support for
ipvs
mode would be removed entirely KEP-5495, Graduation Criteria. To confirm which mode you’re currently running, use:
kubectl -n kube-system get configmap kube-proxy -o jsonpath='{.data.config\.conf}' | grep 'mode:'
To understand the rationale behind this deprecation, see KEP-5495: Deprecate ipvs mode in kube-proxy.
Ongoing major changes
Future removal of cgroup v1 support
As modern Linux distributions and container runtimes use cgroup v2 as the default, support for the legacy cgroup v1 is officially being phased out. Since the v1.35 release, the failCgroupV1
setting has defaulted to true. Consequently, the kubelet
will fail to initialize on any nodes that still rely on cgroup v1 unless an explicit configuration override is applied.
apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration
failCgroupV1: false # temporary override
Using this override should be considered a short-term fix. Advanced resource management capabilities, such as In-Place Pod Resizing and Tiered Memory Protection, depend entirely on cgroup v2. While the override remains available in Kubernetes v1.37, users are encouraged to migrate to cgroup v2, as support for cgroup v1 is planned to be removed in a future release.
To learn more about this deprecation, refer to KEP-5573: Remove cgroup v1 support.
Breaking changes in Kubernetes v1.37
SELinux volume relabeling ("SELinuxMount") graduates to GA
SELinuxMount is expected to reach GA and be enabled by default in v1.37. Volumes would then be
mounted with -o context=
(the mount option default) instead of being recursively
relabeled, but only when the volume's CSI driver opts in via a CSIDriver that sets .spec seLinuxMount: true
.
Because a single mount can only hold one SELinux context, pods with different SELinux labels sharing a volume on the same node (which previously coexisted under recursive relabeling) may now fail to start. To retain the previous recursive behavior for a specific workload, set seLinuxChangePolicy: Recursive
in the Pod spec.
Clusters without SELinux enabled see no effect at all. To learn more, check SELinux Volume Label Changes goes GA (and likely implications in v1.37)
Featured enhancements of Kubernetes v1.37
Metrics API goes GA
The metrics.k8s.io
API is expected to graduate to Stable (GA) in Kubernetes v1.37 after spending nearly nine years in Beta. The API provides a standard way to retrieve CPU and memory usage for pods and nodes, powering widely used Kubernetes features such as the Horizontal Pod Autoscaler (HPA) and commands like kubectl top
.
This graduation recognizes the API's stability and widespread adoption, with no functional changes expected. Both v1
and v1beta1
will remain usable during the transition, enabling developers to adopt the stable API at their own pace without breaking existing workflows.
To learn more about this enhancement, refer to KEP-5207: metrics.k8s.io API definition.
Kubelet in UserNS a.k.a. Rootless Mode
Traditionally, Kubernetes node components such as the kubelet
run with root privileges on the host. While necessary for many deployments, this also means that a vulnerability in one of these components could potentially have a greater impact on the underlying system.
With Kubernetes v1.37, kubelet in User Namespace (Rootless Mode) is expected to graduate to Beta. This enhancement allows Kubernetes node components to run inside a Linux user namespace as an unprivileged user on the host while still behaving as root within the namespace. By reducing the need for host-level root privileges, it adds an extra layer of isolation and helps limit the impact of potential vulnerabilities affecting node components.
To learn more about this enhancement, refer to KEP-2033: Kubelet in UserNS(aka Rootless Mode).
Volume health monitor
Historically, Kubernetes has lacked an API for CSI drivers to report storage failures, which become evident only through failed mounts or hung I/O. Since remediation controllers had nothing machine-readable to act upon, the only way to figure out the root cause behind this failure was to cross-reference Kubernetes objects alongside external vendor dashboards.
In Kubernetes v1.37, this KEP resets graduation to Alpha after an initial implementation in v1.21 and introduces four new CSI
RPCs. The controller plugin reports the health of storage volumes using ControllerListVolumeHealth
(lists unhealthy volumes) and ControllerGetVolumeHealth
(checks a specific volume). A controller-side health monitor polls these CSI controllers and stores the results in
PersistentVolumeClaim.status.healthStatus
.
On the node side, the kubelet calls NodeGetVolumeHealth
to obtain the health of individual volumes on that node and records
it in Pod.status.volumeHealth
, while NodeGetStorageHealth
reports the health of the drivers registered to a node in
CSINode.status.storageHealth
.
The error vocabulary is kept simple, extensible, and machine-parsable (Inaccessible
, Degraded
, etc.), with further driver-specific elaboration available via reason
and message
. Finally, the controller-side and node-side reports are kept independent and are hence displayed separately, providing a more holistic view of storage health to consumers.
To learn more about this enhancement, refer to KEP-1432: Volume Health Monitor.
Want to know more?
New features and deprecations are also announced in the Kubernetes release notes. We will formally announce what's new in Kubernetes v1.37 as part of the CHANGELOG for that release.
Kubernetes v1.37 release is planned for Wednesday, August 26th, 2026. Stay tuned for updates!
You can see the announcements of changes in the release notes for:
Get involved
The simplest way to get involved with Kubernetes is by joining one of the many Special Interest Groups (SIGs) that align with your interests.
If you don't know where to start, join our monthly New Contributor Orientations where we teach the community how the project is structured, and we'll guide you on how to make your first contribution to the project.
- Read more on how to become a Kubernetes Contributor
- Read more about what’s happening with Kubernetes on our blog
- Join us on Slack
- Follow us on X
- Follow us on LinkedIn
- Follow us on Bluesky for the latest updates
- Join the community discussion on Discuss
- Post questions (or answer questions) on Stack Overflow
- Share your Kubernetes End User Story
- Learn more about the Kubernetes Release Team
Facts Only
* `kubectl run --filename/-f` is being deprecated.
* Static Pods can no longer reference Secrets or ConfigMaps via fields like `configMapRef` or `secretRef`.
* kube-proxy support for ipvs mode will be disabled by default by v1.40 and removed entirely by v1.43.
* Support for legacy cgroup v1 is being phased out; the kubelet will fail initialization on nodes relying on cgroup v1 unless an override is applied.
* SELinux volume relabeling ("SELinuxMount") graduates to GA in v1.37, defaulting to mount options rather than recursive relabeling for volumes.
* The Metrics API is expected to graduate to Stable (GA) in v1.37.
* Kubelet in UserNS (Rootless Mode) is expected to graduate to Beta in v1.37.
* A Volume health monitor introduces CSI RPCs for reporting storage failures via `ControllerListVolumeHealth` and `ControllerGetVolumeHealth`.
Executive Summary
The Kubernetes v1.37 release introduces several deprecations, ongoing major changes, and breaking changes for system maintenance. Deprecations include the `--filename` flag for `kubectl run`, which is being phased out as pod generation relies solely on CLI arguments. The Kubelet can no longer reference Secrets or ConfigMaps directly in Static Pods due to a bug fix enforced by the `PreventStaticPodAPIReferences` feature gate removal. Furthermore, kube-proxy's support for ipvs mode will be deprecated over time, scheduled for removal in v1.43, following a deprecation timeline involving v1.40 and v1.43.
Major ongoing changes involve the phasing out of cgroup v1 support, as default settings are shifting to rely on cgroup v2, which is required for advanced resource management features. Breaking changes include the graduation of SELinux volume relabeling ("SELinuxMount") to GA, which now defaults to using mount options instead of recursive relabeling, potentially causing startup failures for pods with disparate SELinux labels unless specific configurations are applied. Enhancements focus on making the Metrics API stable (GA) and advancing kubelet Rootless Mode to Beta, alongside the introduction of a Volume Health Monitor that provides machine-readable reporting for storage health across CSI drivers.
Full Take
The evolution outlined suggests a clear trajectory toward enforcing modern, isolated, and observable infrastructure primitives within Kubernetes. The deprecations targeting direct API access (Static Pods) and legacy kernel interactions (ipvs mode, cgroup v1) reflect a necessary refinement toward security, operational integrity, and standardization—moving away from implicit assumptions to explicit configuration. The shift regarding SELinux volume relabeling highlights a tension between historical behavior and modern container security models, where fine-grained context management is prioritized, demanding users explicitly opt into recursive behavior for specific workloads.
The introduction of the Volume Health Monitor signals a maturation of storage observability, moving failure reporting from external correlation to internal, machine-readable status flags within the control plane. Simultaneously, isolating node components via Rootless Mode addresses systemic risk by enforcing reduced privilege at the host level, which is a fundamental architectural shift toward minimizing blast radius. The central pattern here is the methodical decomposition of legacy, implicit behaviors into explicit, opt-in mechanisms. This process forces system operators to acknowledge dependencies and explicitly manage the trade-offs between backward compatibility and long-term stability, challenging the default assumption that older mechanisms are sufficient for security or functionality.
What assumptions underpin the requirement for these specific deprecations? Are there alternative, less disruptive migration strategies that might address potential concerns about user friction introduced by mandatory feature gate changes? How does the pace of this transition align with the operational reality of large-scale, complex environments where maintaining operational stability often necessitates a degree of inertia against rapid change?
Sentinel — Human
The text reads like a carefully curated summary of official, complex technical roadmaps, exhibiting the precision of a knowledgeable human writer synthesizing upstream documentation.