Kubernetes 1.37: Metrics API Goes GA and kube-proxy IPVS Set for Removal
Kubernetes 1.37 is shaping up to be one of the most operationally significant releases in a long time. It is not full of shiny new objects. Instead it lands a long awaited API graduation, moves the rootless kubelet closer to production, and formally starts the sunset of a proxy mode that many clusters still run on. Here is what actually matters to teams operating clusters right now.
Metrics API finally graduates to GA
The metrics.k8s.io API has spent roughly nine years in beta. In 1.37 it is expected to graduate to stable. This API is the standard way to get CPU and memory usage for pods and nodes, and it powers the Horizontal Pod Autoscaler plus kubectl top. The graduation brings no functional changes. Both v1 and v1beta1 stay usable during the transition, so you can move your tools over at your own pace without breaking existing workloads. For platform teams this removes one of the last long running betas in the control plane.
kube-proxy IPVS mode is being deprecated
This is the headline change for anyone running on the older networking defaults. kube-proxy support for IPVS mode was introduced back in 1.8 to fix iptables performance bottlenecks. The reality is that the kernel IPVS API alone cannot fully implement Kubernetes Services, so IPVS mode still leans on iptables underneath. The extra complexity is no longer worth keeping. Under the plan, IPVS mode is disabled by default by 1.40, still selectable via a feature gate, and removed entirely by 1.43.
The first step is to know which mode you run today:
[code]
kubectl -n kube-system get configmap kube-proxy -o jsonpath='{.data.config\.conf}' | grep 'mode:'
[/code]
If you see IPVS, start planning the move to iptables or to an eBPF data path. If you are already on a CNI that replaces kube-proxy entirely, this deprecation is largely a non-event for you.
Static pods can no longer read Secrets or ConfigMaps
There has long been a bug that let static pods reference Secrets and ConfigMaps through fields like secretRef and configMapRef, even though static pods are not created through the API server and were never meant to read API resources. As of 1.37 these references are strictly prohibited. The PreventStaticPodAPIReferences feature gate that previously let you opt out of the restriction has been removed. If you have static pods pulling config from the API, you need a different pattern now, such as mounting files directly or using an init container that reads external configuration.
cgroup v1 is on its way out
Support for the legacy cgroup v1 is being phased out. Since 1.35 the failCgroupV1 setting has defaulted to true, so the kubelet fails to initialize on nodes still running cgroup v1 unless you override it. The override remains in 1.37 but should be treated as a short term fix only. Advanced features like in-place Pod Resizing and tiered memory protection depend entirely on cgroup v2. Anyone still running older nodes should migrate to cgroup v2 before support is removed for good.
Rootless kubelet moves to beta
Traditionally the kubelet runs as root on the host, which means a vulnerability in a node component can have a wide blast radius. In 1.37 the kubelet in a user namespace, commonly called rootless mode, is expected to graduate to beta. Running node components as an unprivileged user inside a Linux user namespace adds a real layer of isolation, since the process behaves as root only inside the namespace. This is a meaningful step for anyone hardening node OS security.
SELinuxMount graduates to GA
The SELinuxMount feature is expected to reach GA and be enabled by default. Volumes get mounted with a context label instead of being recursively relabeled, but only when the CSI driver opts in through a CSIDriver spec. Because one mount can hold only one SELinux context, pods with different labels sharing a volume on the same node may now fail to start. To keep the old behavior for a specific workload, set seLinuxChangePolicy to Recursive in the pod spec. Clusters without SELinux are unaffected.
What I would schedule for a 1.37 upgrade
- Audit your proxy mode now, not during the upgrade
- Check for static pods that reference Secrets or ConfigMaps
- Confirm every node is on cgroup v2
- Move any tooling off metrics.k8s.io beta if it pins to v1beta1
- Test SELinux workloads if you run SELinux enabled nodes
Deprecations in 1.37 are courteous. They send a warning now so you have a full cadence to migrate before the removal actually lands.
Kubernetes 1.37 does not look flashy on paper. It looks boring in the best way. The project is paying down years of networking and resource management debt while hardening the node security story at the same time. For most teams the upgrade is low drama, but the cleanup you do now determines how painful 1.40 and 1.43 will be.