Kubernetes v1.37 让 metrics.k8s.io API 进入 Stable：升级后如何核对 HPA 依赖

升级 Kubernetes 集群后，HPA 还在按 CPU 或内存扩缩容，但排查时经常先看到的不是 Deployment，而是 metrics.k8s.io。Kubernetes v1.37 的一个关键变化，是这个资源指标 API 从长期的 Beta 状态进入 Stable；这不会自动替你安装或修复 Metrics Server，却让依赖它的指标链路有了更明确的兼容基线。

升级后先核对 APIService 是否可用，再用 kubectl top 验证数据是否能到达，最后看 HPA 的 current 与 desired 是否都在更新；只看 API 版本变成 Stable，不能证明自动扩缩容已经正常。

Kubernetes v1.37 到底稳定了什么

官方 v1.37 发布说明把 metrics.k8s.io API 列为进入 Stable 的能力。这里的对象是 Kubernetes 聚合 API 提供的资源指标接口，常见资源包括 Pod 和 Node 的 CPU、内存使用量。它解决的是 API 成熟度和兼容预期，不等于控制面会凭空产生监控数据。

实际集群通常仍由 Metrics Server 提供这个 API。它从 kubelet 收集资源指标，再通过 APIService 暴露给 Kubernetes API 聚合层；HPA 控制器则从这条链路读取当前值。升级公告值得关注，但排障要回到这条调用链。

先把 HPA 的指标调用链画清楚

一个基于 CPU 利用率的 HPA，大致经过四个边界：HPA 控制器发起资源指标查询，API 聚合层路由到 metrics.k8s.io，Metrics Server 查询 kubelet，最后把 Pod 指标返回给 HPA。任何一段断开，HPA 的 currentMetrics 就可能停留在旧值。

这也是为什么我更建议先查 APIService，而不是直接修改 HPA 的目标利用率。目标值写得再合理，指标接口不可用时也没有新的 current 值可以比较。

升级后用两条命令核对指标入口

先确认聚合 API 的注册状态：

kubectl get apiservice v1beta1.metrics.k8s.io
kubectl describe apiservice v1beta1.metrics.k8s.io

重点看 AVAILABLE 是否为 True，以及描述信息里有没有 TLS、Service 不存在或端点不可达的报错。API 版本的稳定级别变化不会替代这一步。

然后直接读取资源指标：

kubectl top pods -A
kubectl top nodes

如果两条命令都能返回近期数值，说明从 API 聚合入口到 Metrics Server 的基本读路径已经打通；如果只看到 “Metrics API not available”，先回到 Metrics Server 日志和 APIService 条件，不要急着调 HPA。

HPA 仍不扩容时，检查 currentMetrics 和目标资源

指标 API 正常，只能说明 HPA 有机会拿到数据。继续查看 HPA：

kubectl describe hpa  -n 
kubectl get hpa  -n  -o yaml

在输出中对照 currentMetrics、desiredReplicas、事件和目标 Deployment。若 current 值已经更新而副本数不变，常见原因转移到了目标资源选择器、请求资源值、缩放窗口或阈值，而不是 metrics.k8s.io 的 API 稳定级别。

这次变化对升级和回滚意味着什么

对使用者来说，最直接的收益是 API 稳定性信号更清晰：可以把 metrics.k8s.io 纳入升级验收清单，并把 APIService、kubectl top、HPA 状态作为一组回归检查。它并不意味着所有旧版 Metrics Server、kubelet 配置或网络策略都自动兼容。

回滚时也不要只比较控制面版本。先保存升级前后的 APIService 条件、Metrics Server 日志摘要和一组 kubectl top 输出，再判断 HPA 是否真的受到影响。这样即便最终回退，也能分清是 API 发现问题、采集问题，还是扩缩容参数问题。

相关问题

metrics.k8s.io 进入 Stable 后还需要安装 Metrics Server 吗？

需要。Stable 描述 API 的成熟度，不负责替集群提供资源指标实现；仍要确认集群中有可工作的 Metrics Server 或兼容实现。

APIService 是 True，为什么 kubectl top 仍然失败？

继续看 Metrics Server 端点、证书、到 kubelet 的网络访问和日志。APIService 可用代表聚合入口可达，不代表每次采集都成功。

HPA 不扩容是不是一定是 metrics.k8s.io 的问题？

不是。先看 currentMetrics 是否更新；如果更新了，应转查 HPA 目标、资源请求、策略和冷却窗口。

把这次升级写进验收清单

Kubernetes v1.37 的这项变化适合落成三步验收：确认 v1beta1.metrics.k8s.io 的 APIService 为可用，确认 kubectl top 能读到近期指标，再确认一个测试 HPA 的 currentMetrics 和 desiredReplicas 会随负载变化。三步都通过，才算指标链路和自动扩缩容一起完成了升级验证。