Key Changes in Kubernetes v1.37: Deprecations, Enhancements, and New Features

With the impending release of Kubernetes v1.37, significant updates are on the horizon, impacting how users maintain their Kubernetes environments. This version focuses on refining existing features and implementing new functionalities that promise to enhance user experience without compromising overall project health. Below, we outline pivotal changes including deprecated features, enhancements, and important new integrations.

Deprecations and Removals

Deprecation of kubectl run --filename/-f

The use of the --filename (or -f) flag during kubectl run commands is slated for deprecation. The rationale is straightforward: generated pods will always derive their configuration directly from CLI parameters like NAME and --image. Users are encouraged to migrate their workflows accordingly.

For more details on this change, refer to the discussion on GitHub.

Static Pods: Prohibition of Secrets and ConfigMaps

Kubernetes v1.37 enforces stricter regulations around Static Pods. Previously, a bug allowed these Pods to reference Secrets and ConfigMaps, but this has been corrected—now, such references are explicitly forbidden. This fix aligns with the original design intent, where Static Pods do not interact with the API server directly.

To review the details of this fix, consult the related GitHub issue.

Deprecation of kube-proxy IPVS Mode

Support for ipvs mode in kube-proxy will see a phased deprecation, with warnings issued to clusters using this mode starting from v1.37. Although initially introduced to improve performance over iptables, ipvs can't function independently of it, leading to this decision.

• v1.40: ipvs mode will be disabled by default but can still be utilized via a feature gate.
• v1.43: The ipvs mode will be completely removed from Kubernetes.

For further clarification of the reasons behind this deprecation, see the discussion in KEP-5495.

Ongoing Major Changes

Phasing Out of cgroup v1 Support

As platforms move towards cgroup v2 as the standard for resource management, Kubernetes is following suit by phasing out support for legacy cgroup v1. Starting from v1.35, the failCgroupV1 setting defaults to true, which means any dependencies on cgroup v1 will lead to kubelet initialization failures unless explicitly configured.

For a temporary bypass, users can set failCgroupV1: false, but this should be seen as a short-term solution. Long-term resource management features, like In-Place Pod Resizing, will rely on the full functionality of cgroup v2. Follow up on this with KEP-5573.

Breaking Changes in v1.37

SELinux Volume Relabeling Matures to GA

With the transition to General Availability (GA), the SELinuxMount feature will be enabled by default in v1.37. This change requires volumes to be mounted with -o context=<label>, moving away from previous recursive relabeling strategies. Pods with differing SELinux labels sharing the same volume could encounter startup issues under this new setup, so users should be cautious.

More about this can be found in the detailed blog post.

Key Enhancements in v1.37

Metrics API Reaches GA

After nearly a decade in beta status, the metrics.k8s.io API is set to graduate to Stable (GA) in this release. This API enables standardized access to resource usage metrics, essential for features like the Horizontal Pod Autoscaler (HPA). The switch will allow both v1 and v1beta1 to coexist, giving users the flexibility to transition at their convenience.

Learn more through KEP-5207.

Kubelet in User Namespace: Rootless Mode

The introduction of rootless mode for kubelet offers enhanced security by enabling node components to operate within Linux user namespaces, eliminating the need for host-level root privileges while maintaining necessary functionalities. This shift is particularly significant for better safeguarding against vulnerabilities.

Additional information is available in KEP-2033.

Introduction of Volume Health Monitoring

A new Volume Health Monitor allows CSI drivers to report storage problems via dedicated APIs, tackling a long-standing issue where storage failures were difficult to diagnose. With four new CSI RPCs introduced to gather and relay health status, Kubernetes now provides a more systematic approach to storage management.

To explore this further, see KEP-1432.

Engage with the Community

With these upgrades, staying involved in the Kubernetes ecosystem has never been easier. Developers can participate in Special Interest Groups (SIGs) that mirror their interests. Monthly orientations provide new contributors with guidance and insights into the project's structure.

For anyone interested in contributing, consider joining the discussions on Kubernetes Discuss or following along with updates through various community channels like Slack, X, and LinkedIn.

Stay tuned for more updates regarding the official release set for Wednesday, August 26th, 2026. For more detailed insights about previous releases and changes, visit the Kubernetes CHANGELOG.