Kubernetes v1.37 Sneak Peek: Metrics API Goes GA and ipvs Deprecation

Kubernetes v1.37 Sneak Peek: Metrics API Goes GA and ipvs Deprecation

On July 31, 2026, the Kubernetes blog published the v1.37 Sneak Peek, previewing the enhancements, deprecations, and breaking changes worth watching in this release. v1.37 is planned for August 26, 2026, and teams maintaining clusters should digest this list in advance.

Kubernetes ships three minor releases a year, and each release is only maintained for about a year — so upgrading isn't a question of "if" but "when". The sneak peek matters because it carries both graduating features and several deprecations that become hard requirements within the next two or three releases. Plan now, or the cost of moving later — once a feature is disabled by default or removed entirely — will be far higher.

Featured enhancements

• Metrics API goes GA: after nearly nine years in Beta, the metrics.k8s.io API graduates to Stable. It provides a standard way to retrieve CPU and memory usage for pods and nodes, powering core features such as the Horizontal Pod Autoscaler (HPA) and kubectl top. The graduation brings no functional changes, and both v1 and v1beta1 remain usable during the transition for a smooth upgrade.
• Kubelet in User Namespace (Rootless Mode) reaches Beta: Kubernetes node components can now run inside a Linux user namespace as an unprivileged host user while behaving as root within the namespace. This adds an isolation layer that limits the blast radius of a vulnerability in node components.
• Volume health monitor: a new CSI storage-health reporting mechanism means storage failures no longer have to be diagnosed after a failed mount — controller-side and node-side reports are independent, giving a more holistic, machine-parsable view of storage health.

The Metrics API graduation is the most tangible for day-to-day ops. Where kubectl top node previously leaned on a temporary metrics-server implementation, a stable v1 interface is now something monitoring and cost-analysis tooling can safely depend on:

# Node resource usage
kubectl top nodes
# Per-pod usage inside a namespace
kubectl top pods -n production

Worth noting: since it first appeared alongside HPA in 2017, metrics.k8s.io has lived as a "side interface" that many monitoring stacks treated as a throwaway data source. GA formalizes the API contract — fields stop changing under you, tooling can depend on it long-term — and it also paves the way for future features like resource-usage billing and cost allocation.

Deprecations and removals to plan for

• kube-proxy ipvs mode starts deprecation: ipvs mode was introduced in v1.8 to solve iptables performance bottlenecks, but it still relies on iptables underneath. The plan is to disable it by default in v1.40 and remove it entirely in v1.43. Check your current mode with:

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

For clusters still on ipvs, the migration path is usually back to the default iptables mode, or to a more modern eBPF data plane (such as Cilium). The migration itself isn't hard: set mode to empty or iptables, roll kube-proxy out, and verify with curl localhost:10249/proxyMode. The time sink isn't the operation — it's auditing any custom rules that depend on ipvs-specific behavior.

• kubectl run --filename/-f is deprecated: because the generated pod is always built from CLI arguments, the -f flag will be removed.
• Static Pods can no longer reference Secrets or ConfigMaps: this fixes a bug — Static Pods previously could reference API resources via fields; starting in v1.37 these references are strictly prohibited.
• cgroup v1 moves toward removal: since v1.35, failCgroupV1 defaults to true. Nodes still relying on cgroup v1 need a temporary failCgroupV1: false override, but the project explicitly calls this a short-term fix and encourages migrating to cgroup v2.

Check whether a node is already on cgroup v2:

stat -fc %T /sys/fs/cgroup
# Output cgroup2fs means v2 is in use

Version window and migration rhythm

Against this table, put "check ipvs mode, confirm cgroup v2, clean up Static Pod references to Secrets" on the pre-upgrade checklist for v1.37. Every item maps to a concrete action within the next two releases — do it early and rest easy; leave it late and you'll be juggling several changes at once, where it's far harder to tell which one broke what.

Breaking change: SELinuxMount goes GA

SELinux volume relabeling (SELinuxMount) reaches GA and is enabled by default in v1.37. 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 old recursive behavior, set seLinuxChangePolicy: Recursive in the Pod spec. If your cluster runs with SELinux enabled on bare metal or self-hosted nodes, run a regression test on a representative volume before upgrading to v1.37 to make sure no pods fail to start because of the changed relabeling behavior.

16IDC Take

v1.37's "goodbye list" deserves more attention than its "welcome list": paying down technical debt is the theme of this generation of container orchestration. For SMBs, don't be distracted by the new features — put the ipvs migration, cgroup v2, and Static Pod compliance on your roadmap first. Concretely: fold the v1.37 upgrade test, ipvs mode check, and cgroup v2 health check into the next iteration's ops plan — each item is easy, but each needs a release of lead time. Beginners can start with the Kubernetes deployment guide for beginners, then build on the Docker deployment guide to understand container fundamentals. For more environment and deployment content, see the Environment Deployment category.

Reference: Kubernetes v1.37 release notes https://kubernetes.io/blog/2026/07/31/kubernetes-v1-37-sneak-peek/