Metrics API reaches stable v1 in Kubernetes 1.37: implications for automation and scaling

The Kubernetes Metrics API has been promoted to a stable v1 version in the v1.37 release. The change is limited to the API version string; the resource types (NodeMetrics and PodMetrics) and their fields remain identical to the previous v1beta1 version. For engineers who rely on kubectl top, Horizontal Pod Autoscaling, or any custom tooling that consumes node‑ and pod‑level CPU/memory data, the promotion means the API now carries the stability guarantees of a core Kubernetes API.

What changed in v1.37?

The only functional difference is the API group version: metrics.k8s.io/v1 replaces metrics.k8s.io/v1beta1. No fields were renamed, no new fields were added, and the semantics of the returned metrics are unchanged. Clients can query the stable endpoint with commands such as:

kubectl get --raw /apis/metrics.k8s.io/v1/nodes

and

kubectl get --raw /apis/metrics.k8s.io/v1/namespaces/default/pods

kubectl top automatically prefers the v1 endpoint when it exists, falling back to v1beta1 on older clusters. The Horizontal Pod Autoscaler (HPA) still targets v1beta1 only; a discovery‑based switch to v1 is planned but not available in this release.

Why does this matter to AI, Cloud, DevOps, and Security engineers?

Stable APIs are a contract: they are less likely to change in incompatible ways and are covered by Kubernetes’ versioning policy. Automation pipelines, CI/CD jobs, and monitoring agents that embed the API version can now lock to v1 with confidence that future releases will preserve the contract. For AI workloads that dynamically scale based on resource consumption, the guarantee reduces the risk of unexpected metric‑related failures. Cloud platform teams can treat the metrics endpoint as a first‑class component of the control plane, and security engineers can rely on the stable API surface when defining audit or compliance checks.

Operational and architectural considerations

• Implementation requirement: The metrics service (e.g., metrics-server) must expose the v1.metrics.k8s.io API and register an APIService object. Without this registration, the stable endpoint will not be discoverable.
• Dual‑version support: During the transition period, implementations should continue to serve both v1 and v1beta1. Keeping the older version available protects existing clients that have not yet migrated.
• Verification steps: Operators can list the served versions with kubectl get --raw /apis/metrics.k8s.io/ | jq . and confirm the APIService status via kubectl get apiservice v1.metrics.k8s.io. These checks become part of routine health‑checking scripts.
• Impact on autoscaling: Since HPA still consumes v1beta1, clusters that only expose v1 will need to retain the beta endpoint until the HPA controller is updated. Planning for the upcoming discovery‑based switch can avoid a temporary loss of autoscaling capability.
• Security posture: The promotion does not introduce new authentication or authorization mechanisms. Existing RBAC rules that grant access to metrics.k8s.io continue to apply. However, the stable API may be referenced in security policies, so ensuring the correct APIService is registered helps avoid accidental exposure.

Related CloudNinjas coverage: Kubernetes.

What This Means For Practitioners

Adopt the v1 endpoint in any new tooling or automation and verify that your metrics implementation registers the corresponding APIService. Keep the v1beta1 version running until the HPA controller is updated, and incorporate the version‑check commands into your cluster validation suite. Monitoring the SIG Instrumentation channels will alert you when the HPA gains native v1 support, allowing you to retire the beta endpoint safely.