Kubernetes v1.37: Metrics API graduates to stable

The Kubernetes project just moved the Metrics API to stable status in version 1.37, marking a significant milestone for observability and resource management in Kubernetes clusters. The metrics.k8s.io API has been a critical component of Kubernetes operations for years, but living under beta status meant it could change without warning. Now that it’s reached v1 stability, cluster operators and platform teams can rely on it as a permanent fixture of the Kubernetes API landscape. This graduation removes uncertainty from production deployments and gives organizations confidence that their monitoring and autoscaling workflows won’t break with future Kubernetes upgrades.

So what exactly does the Metrics API do, and why should you care? At its core, the Metrics API collects CPU and memory usage data from your nodes and pods, then exposes this information through standard Kubernetes API endpoints. When you run kubectl top nodes or kubectl top pods to see resource consumption in your cluster, you’re querying this API. Behind the scenes, the Metrics Server component (a separate deployment) pulls raw metrics from Kubelet on each node, aggregates them, and stores them in memory for quick retrieval. This is deliberately lightweight by design—it’s meant for recent metrics (typically the last 15 minutes), not long-term historical storage. Think of it as your cluster’s real-time vital signs display, complementing your longer-term monitoring solutions like Prometheus or CloudWatch.

The practical impact becomes clear when you consider how autoscaling works in Kubernetes. Horizontal Pod Autoscaler (HPA) and Vertical Pod Autoscaler (VPA) both depend on the Metrics API to make scaling decisions. When HPA decides whether to spin up more replicas based on CPU threshold, it’s reading directly from this API. For example, if you’ve configured HPA to scale your web service when average CPU exceeds 70%, the controller checks the Metrics API every 30 seconds to make that decision. With the API now stable, you can confidently build automation that relies on these metrics without worrying about breaking changes in future Kubernetes releases. This is especially valuable for teams running multi-cluster setups or those planning long-term infrastructure investment.

For teams adopting Kubernetes at scale, this graduation simplifies your architecture decisions. You no longer need to treat the Metrics API as a moving target in your documentation and operational runbooks. Whether you’re building cost optimization tools that analyze pod resource requests versus actual usage, creating dashboards that developers can self-serve, or implementing cluster autoscaling policies, you can now build on a stable foundation. The stability guarantee means Kubernetes commits to maintaining backward compatibility—any future enhancements will only add new capabilities, not remove existing ones. If you’ve been hesitant about integrating the Metrics API into custom tools or GitOps workflows, now is the time to do so with confidence.