为什么依赖 metrics-server
按 CPU/内存使用率扩缩的 HPA 并不自己采集数据：它通过聚合 API 路径 metrics.k8s.io 向 metrics-server 取数，metrics-server 再从各节点 kubelet 的 10250 端口汇总指标。所以指标管道任一段中断，HPA 的 TARGETS 列就会显示 unknown，同时 kubectl top 也会一起失效——这两个现象同时出现，几乎可以断定问题在指标管道而不是 HPA 本身。
基本信息
| 数据链路 | HPA -> metrics.k8s.io -> metrics-server -> kubelet:10250 |
|---|---|
| 聚合入口 | APIService v1beta1.metrics.k8s.io |
| 部署位置 | 通常位于 kube-system，以 Deployment 形式运行 |
| 连带影响 | kubectl top、HPA 资源指标同时失效 |
| 替代方案 | 自定义指标需 Prometheus Adapter 等额外组件 |
典型使用场景
- HPA 报 unknown：先确认指标管道，避免在策略配置上反复试错
- kubectl top 报错：值班告警里常与容量看板一起出现，需要同一套检查路径
- 集群升级后指标失效：kubelet 证书或聚合层参数变化导致采集握手失败
- 自签证书环境：kubelet 证书不被信任时 metrics-server 持续采不到数据
- 容量审计：核对指标数据是否真实，避免基于失真数据做扩缩决策
按链路顺序检查
按链路顺序检查
kubectl get apiservice v1beta1.metrics.k8s.io # 是否为 True，Available 列最直观
kubectl -n kube-system get deploy,pods | grep metrics-server # 组件是否就绪
kubectl -n kube-system logs deploy/metrics-server --tail=50 # 采集失败原因通常在这里
kubectl top node # 端到端验证，报错即管道不通
kubectl get --raw /apis/metrics.k8s.io/v1beta1/nodes | head -c 200 # 直接读聚合接口常见报错对照
| 现象 | 可能的层 | 下一步 |
|---|---|---|
| APIService 显示 False 或 MissingEndpoints | 聚合层未就绪 | 看 metrics-server 的 Pod 与 Endpoints 是否为空 |
| 日志出现 x509 或证书校验错误 | 与 kubelet 的 TLS 握手失败 | 按官方建议配置 kubelet 证书信任参数 |
| 日志出现 dial tcp ... connection refused | 到 kubelet 10250 网络不通 | 检查节点网络、防火墙与 kubelet 监听地址 |
| HPA 有值但 top 报错 | 权限或聚合层权限问题 | 检查组件 ServiceAccount 的 RBAC 绑定 |
HPA 计算使用率的分母是容器的 requests：容器没有写 CPU requests 时，资源型 HPA 无法计算百分比，TARGETS 同样显示 unknown，此时问题在清单而不在指标管道，先确认 Pod 的 requests 是否齐全。
metrics-server 提供的是短周期的资源使用快照，不保存历史数据。需要趋势分析、扩缩依据留痕或基于历史做容量规划时，应另建长期指标系统，把它当成实时查询入口而不是监控库。