实时资源用量视角
kubectl top 显示 Pod 与节点的实时 CPU、内存用量，数据来自集群内安装的 metrics-server，它读取 kubelet 暴露的容器指标并通过 Metrics API 提供给 kubectl 与 HPA 使用。它的定位是容量排查的第一步：先找出谁在吃资源，再结合 requests/limits 与监控历史判断是否要调整。它只提供瞬时采样，不具备时间序列能力。
基本信息
| 语法 | kubectl top pods -n dev；kubectl top nodes |
|---|---|
| 容器级 | --containers 显示 Pod 内每个容器的用量，便于识别 sidecar 占用 |
| 排序 | --sort-by=cpu 与 --sort-by=memory，快速定位消耗大户 |
| 前置条件 | 集群需安装并运行 metrics-server，Metrics API 处于可用状态 |
| 数据口径 | CPU 为核或毫核，内存为字节；均为瞬时采样值 |
| 权限 | 需要能读取 Metrics API 的账号，只读即可 |
典型使用场景
- 节点水位巡检：判断是否需要扩容或迁移负载
- 找出内存与 CPU 消耗最高的 Pod，确定优化与限流目标
- 排查 OOMKilled 前先看当前用量与 limit 之间的余量
- 横向对比同一 Deployment 各副本的用量，发现负载不均或个别实例异常
- HPA 不扩缩时先确认指标本身是否在变化，区分是指标缺失还是策略问题
常用命令
常用命令
kubectl top nodes # 节点级 CPU 与内存
kubectl top pods -n dev --sort-by=memory | head # 内存消耗排行
kubectl top pod web-1 --containers # Pod 内各容器用量
kubectl top pods -A --sort-by=cpu | head -20 # 全集群 CPU 排行
kubectl get pod web-1 -o jsonpath='{.spec.containers[*].resources}' # 对比 requests/limits
kubectl get apiservice v1beta1.metrics.k8s.io # 确认 Metrics API 已注册输出逐列读法
| 列 | 含义 | 异常表现 |
|---|---|---|
| NAME | 节点名或 Pod 名，加 --containers 时首列为容器名 | 名字对不上通常是查错了命名空间 |
| CPU(cores) | 瞬时 CPU 用量，以核或毫核表示 | 持续贴近 limit 或节点可分配上限即为瓶颈 |
| CPU(%) | 占节点可分配 CPU 的百分比 | 高占用伴随高负载均值说明已过载 |
| MEMORY(bytes) | 瞬时内存用量 | 持续贴近 limit 时随时可能 OOMKilled |
| MEMORY(%) | 占节点可分配内存的比例 | 与 requests 对比可判断调度是否已超标 |
top 显示的是瞬时采样：排查 OOM 必须结合容器 limit 与监控里的历史峰值，只看一眼可能正好落在低谷，从而误判为「内存很宽裕」。
数据缺失时按层排查：先确认 metrics-server 的 Pod 是否就绪，再看 apiservice 是否 Available，最后查节点网络与证书配置。国内环境常见原因是镜像拉取失败导致 metrics-server 一直没能起来。