metrics.k8s.io is no longer "that optional metrics API" — it's now GA in 1.37, and that matters more than you'd think. When the cluster API you rely on for CPU/memory/topology signals becomes a stable contract, it forces everyone off ad‑hoc shims and onto a single observability surface. Expect upgrades to expose gaps: legacy metrics-server builds, custom scrapers that bypass metrics.k8s.io, and CI templates that parse unstable JSON will all surface failures during upgrades.
This release includes enhancements across alpha, beta, and stable stages. The operational winners are obvious: metrics.k8s.io v1 (GA), SELinuxMount stable and on by default, kyaml output stabilized in kubectl, pod-level resources going GA, and taints/tolerations for device resources reaching stability. Together these are not cosmetic — they change what teams must test in staging before pushing control-plane or node upgrades.
Start with observability: metrics.k8s.io GA
With metrics.k8s.io promoted to v1, the API path for pod and node metrics is a supported contract. That should simplify autoscaler integrations and give SREs a single source for pod/node metrics. But there's a catch — many managed distributions and older clusters still rely on non‑standard exporters or older metrics-server builds. If your HPA, custom autoscaler, or cost engine queries kubelet /metrics directly or parses kubectl top output, it’s time to stop relying on fragile plumbing.
Security and mount behavior: SELinuxMount on by default
SELinuxMount is now stable and enabled by default. This is overdue and correct: defaulting to safer semantics reduces a class of silent privilege escalations from bind‑mounts and hostPath abuses. It will, however, break workloads that rely on permissive mount semantics or that assume host SELinux contexts. Teams with daemonsets that perform low‑level mounts — logging agents, CSI helpers, or custom init containers — need to audit for SELinux denials and test upgrades. Treat this like a kubelet flag change in disguise; it affects runtime behavior, not just a pod annotation.
Pod-level resources and device taints: better accounting for hardware
Pod-level resources graduating to GA and taints/tolerations for device resources stabilizing means hardware‑aware scheduling is maturing. If you still shoehorn accelerators into device plugins that cheat the scheduler or expose devices as node‑level allocatable, you’ll see lower‑fidelity scheduling and accounting. Pod‑level resources give you per‑pod visibility (and chargeback hooks) for GPUs, NPUs, and custom accelerators — use them or keep paying the technical debt tax.
Beta features that change how you think about node security and autoscaling
KubeletInUserNamespace (rootless kubelet) and HPA scale‑to‑zero are beta in 1.37. Rootless kubelet is a meaningful security bet: it reduces the attack surface of node agents but also changes assumptions about privileged mounts, tooling that expects host namespaces, and how you distribute node‑level certs. HPA scale‑to‑zero formalizes a common serverless pattern; if your autoscaling tests only cover 1→n behavior, add zero→one cold‑start cases now.
Ecosystem choreography: Helm 3 EOL and containerd 2.x momentum
Outside core, the ecosystem is shifting: Helm 3 is now in long‑term maintenance for older minors and chart authors are focusing on compatibility, while container runtime upgrades (including containerd 2.x adoption) are progressing. If your pipelines bake Helm charts or pin container runtimes, schedule those upgrades ahead of time and consult vendor support timelines rather than doing them during a Friday‑afternoon emergency.
My take: this release is less about flashy alpha features and more about raising the baseline. Stabilizing metrics.k8s.io, pod-level resources, SELinuxMount, and kyaml output forces operators to deal with correctness and security trade-offs rather than papering over them with ad‑hoc tooling. That’s the right call — it will be inconvenient in the short term, but it reduces silent drift and hidden failure modes.
If you're responsible for cluster upgrades, do three things this quarter: (1) run a metrics compatibility sweep (clients, HPA, autoscalers), (2) test node‑level SELinux behaviors in a staging fleet, and (3) validate device plugins against pod‑level resources and device taints/tolerations. Ignore any one of these and you'll learn the difference between "it worked in dev" and "it broke in production" the hard way.
Kubernetes 1.37 isn't flashy, but it's the kind of release that reshapes operational foundations. Expect upgrade‑induced noise — and a cleaner, more auditable cluster baseline afterward.