INFRA Signal 152
Cluster operators can now use stable metrics.k8s.io/v1 API for autoscaling
↗
Illustration only Photo by Venti Views on Unsplash
Kubernetes v1.37 graduates the metrics.k8s.io API to stable v1, giving CPU and memory metrics a guaranteed interface for tools like kubectl top and autoscaling.
The graduation provides stability guarantees, so clients relying on the API will not face breaking changes in future Kubernetes releases. Existing tools such as kubectl top and the HorizontalPodAutoscaler can continue to work unchanged, while new implementations can target the v1 endpoint. Cluster operators must ensure their metrics server serves v1 and registers the corresponding APIService to reap the benefits.
Written by elseif from the cluster below · every claim links back to a sourceThe three things worth knowing
The v1 API surface is identical to v1beta1, with NodeMetrics and PodMetrics resource types unchanged.
kubectl top prefers the stable v1 endpoint but automatically falls back to v1beta1 when v1 is not served.
The HorizontalPodAutoscaler currently only consumes v1beta1, with v1 support planned for a later release.
THE READ
What the cluster adds up to.
Kubernetes v1.37 promotes the metrics.k8s.io API from beta to stable, releasing it as version v1. The API continues to expose the NodeMetrics and PodMetrics resource types with the same fields as in v1beta1. No changes were made to the CPU and memory values returned by the API.
Adopting the stable API requires a metrics server implementation that serves the v1 endpoint and registers an APIService for v1.metrics.k8s.io. Operators can continue to run existing v1beta1 servers alongside the new v1 service to maintain compatibility with older clients. No feature gate needs to be enabled; the API is served through the standard aggregation layer. During the transition, implementations should provide both v1 and v1beta1 versions.
The stable API does not yet affect all consumers; the HorizontalPodAutoscaler controller still consumes only v1beta1 in this release. Consequently, autoscaling based on HPA will not automatically use the v1 endpoint until support is added in a future version. The API remains intentionally small and is not intended to replace a full monitoring pipeline or the custom metrics API.
For operators, the graduation offers long-term stability guarantees, reducing the risk of breaking changes in future Kubernetes releases. Tools such as kubectl top already prefer v1 when available and will fall back to v1beta1 if needed, providing a smooth transition. Monitoring the APIService status with kubectl get apiservice v1.metrics.k8s.io confirms that the stable endpoint is being served.
Written by elseif from the cluster below · checked for specifics the sources never containedTHE CLUSTER