问题定位
kubectl top 的数据不来自 kubelet 直连，而来自聚合层暴露的 Metrics API：请求先进 kube-apiserver，再转发给 kube-system 里的 metrics-server，metrics-server 定期从每个节点 kubelet 的 10250 端口抓取指标。报 Metrics API not available、只显示部分节点或干脆没有数据，都出在这条链路上。适用平台是 Kubernetes，HPA 也依赖同一套指标，因此这条链路修不好，弹性伸缩同样失效。
基本信息
| 依赖组件 | metrics-server（或同类指标适配器）加 API 聚合层 |
|---|---|
| 数据来源 | 节点 kubelet 的 10250 端口指标接口 |
| 采集周期 | metrics-server 默认约 15 秒抓一次，指标有窗口延迟 |
| 影响面 | kubectl top 与 HPA 共用这条链路，坏了会同时受影响 |
典型使用场景
- 巡检确认指标链路可用：日常核对 kubectl top nodes 能出数，避免 HPA 失效无人察觉
- 扩容决策前看真实用量：节点 requests 已满但实际利用率低时，用 top 判断是否需要调 requests
- 排查 HPA 不扩缩：先确认指标链路是否正常，再去看 HPA 的事件与阈值配置
- 验证新装集群：kubeadm 装完后确认 metrics-server 是否正常工作，属于集群验收项
- 对比 requests 与实测：定位长期超配或欠配的工作负载
三步检查
三步检查
kubectl get apiservice v1beta1.metrics.k8s.io -o wide # 聚合层是否注册且可用
kubectl -n kube-system get pod -l k8s-app=metrics-server # 组件是否在跑
kubectl -n kube-system logs deploy/metrics-server --tail=80 # 看抓取报错
kubectl get --raw /apis/metrics.k8s.io/v1beta1/nodes | head -c 300 # 直接查 API
kubectl top nodes; kubectl top pods -A # 最终验证现象与原因对照
| 现象 | 常见原因 | 处理方向 |
|---|---|---|
| Metrics API not available | APIService 未注册或后端不可用 | 查 apiservice 的 AVAILABLE 列与 metrics-server 日志 |
| 只有部分节点有数据 | 这些节点 kubelet 的 10250 不通或证书不被信任 | 节点侧查防火墙与 kubelet 证书 |
| 刚装完就没数据 | 采集周期未到 | 等一到两分钟再看 |
| 日志报 x509 错误 | metrics-server 与 kubelet 证书校验不通过 | 修 CA 配置，测试环境才考虑 insecure 选项 |
日志里出现 x509 证书报错或 10250 端口连不上，说明 metrics-server 到 kubelet 的链路有问题；自签环境下常用 --kubelet-insecure-tls 绕过校验，但仅限测试用途，生产应正确配置 CA。
kubectl top pod 显示的是近窗口的平均用量，用于实时判断会有滞后；做容量规划仍应结合监控系统里的长周期数据。