Kubernetes 1.37 Preview: What’s New for Cluster Operators

Rarely does a Kubernetes upgrade break because someone introduced a new shiny feature. More often than not, you run into trouble because something quietly changed.

The Kubernetes 1.37 release illustrates this point quite nicely. While the release includes several operator improvements, it also deprecates old functionality, hardens security-related behaviors, and moves clusters closer to newer Linux and Kubernetes infrastructure. For anyone running a cluster in production, knowing what’s going away can be just as important as knowing what’s being introduced.

Kubernetes 1.37, codenamed Garhwal, was released on August 26, with the next patch release, v1.37.1, scheduled for September 15.

Out with the old

Perhaps the most critical change is the ongoing push to retire older infrastructure. kubectl run will lose its –filename/-f option, and Static Pods will no longer be allowed to reference Secrets or ConfigMaps. The latter fixes a bug to return Static Pods to their intended behavior.

Additionally, Kubernetes 1.37 begins the deprecation of kube-proxy’s IPVS mode. According to the project, IPVS is unable to implement all Kubernetes Services and continues to rely on iptables underneath. IPVS will be disabled by default starting in v1.40, and will be removed entirely by v1.43.

If you operate a cluster, cgroup v1 needs to get your attention, as well. Kubernetes is moving away from cgroup v1 in favor of cgroup v2, and v1.37 continues that effort. Starting in v1.35, failCgroupV1 has been set to true by default, meaning the kubelet won’t boot up on cgroup-v1 nodes unless an override is configured. That configuration is meant to be a short-term fix, while newer resource management features are expected to require cgroup v2.

The quiet quality-of-life upgrades

While other changes may not be as dramatic, they definitely help make everyday cluster operations easier.

The metrics.k8s.io API has graduated to stable after nearly nine years in beta. It provides standard CPU and memory usage data for Pods and nodes, and powers many common features and tools like kubectl top and the Horizontal Pod Autoscaler.

kubelet in User Namespace, also called Rootless Mode, has also graduated to beta. This feature lets Kubernetes node components run as an unprivileged user on the host while acting as a root user within the user namespace. It reduces host-level privileges, which can help mitigate the impact of vulnerabilities targeting node components.

SELinuxMount is GA and will be enabled by default when supported by the CSI driver. Under specific circumstances, Pods with different SELinux labels that share a volume on the same node may be affected, but clusters that don’t use SELinux are not impacted.

Storage gets more visibility

Observability around storage is improving, too. Volume health monitoring returns to Alpha with four new CSI RPCs. Storage drivers can now expose information such as volumes being inaccessible or degraded through Kubernetes resources. Instead of looking for failures across a collection of dashboards, cluster operators will have machine-readable data to help troubleshoot storage issues.

For cluster operators, that may be the real story for Kubernetes 1.37. The release isn’t just adding features to a complex platform; it’s retiring old assumptions while making critical pieces of the cluster more observable and less reliant on privileged infrastructure.