首页 > 科技周边 > 业界新闻

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

来源：17golang原创

时间：2026-08-28 09:33:48 225浏览收藏

升级 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 的 Stable 指的是 metrics.k8s.io API 的成熟度，不是 Metrics Server 的自动部署。
HPA 读取资源指标时，关键链路是 HPA → metrics.k8s.io → Metrics Server → kubelet。
kubectl get apiservice v1beta1.metrics.k8s.io 与 kubectl top pods 应该成对检查。
指标能查到但 HPA 不扩容时，还要检查目标资源、阈值和 currentMetrics。

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 就可能停留在旧值。

Kubernetes v1.37 中 HPA 通过 metrics.k8s.io、Metrics Server 和 kubelet 获取 Pod 资源指标的调用链

这也是为什么我更建议先查 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。

核对 Kubernetes metrics.k8s.io 后，kubectl top 与 HPA currentMetrics 从不可用恢复为可读的前后对照

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

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

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

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

现象	优先检查	能得出的结论
APIService 为 False	Metrics Server Service、端点、TLS	聚合 API 入口未就绪
`kubectl top` 无数据	Metrics Server 日志与 kubelet 连通性	资源指标读路径中断
currentMetrics 更新但副本不变	HPA target、资源请求、缩放策略	指标链路已通，问题在扩缩容决策

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

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

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

把这次升级写进验收清单

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