📚 课程目录第4章调度亲和性基础

4. kubectl top node 与 kubectl top pod：实时查看节点与 Pod 资源使用情况

在诊断节点资源竞争与调度亲和性校准的过程中，实时资源监控是第一步。kubectl top 命令直接读取集群中 Metrics Server 聚合的指标数据，提供节点和 Pod 的 CPU、内存瞬时使用量，是判断节点是否过载、Pod 是否资源受限的核心工具。

4.1 命令基础与数据来源

kubectl top 依赖 Metrics Server 运行在集群中。如果集群未部署 Metrics Server，执行该命令会返回错误。Metrics Server 从 kubelet 的 cAdvisor 接口采集数据，默认每 15 秒刷新一次，因此 top 命令展示的是近实时快照，而非历史趋势。

命令	作用	输出维度
`kubectl top node`	查看所有节点的 CPU 和内存使用总量	节点级别
`kubectl top pod`	查看指定命名空间下 Pod 的资源使用量	Pod 级别（含容器级）
`kubectl top pod --containers`	展开显示 Pod 内每个容器的资源使用	容器级别

4.2 kubectl top node：节点资源饱和度诊断

执行 kubectl top node 可快速识别集群中资源使用率最高的节点，判断是否存在资源竞争风险。

# 查看所有节点资源使用情况
kubectl top node

# 输出示例：
NAME          CPU(cores)   CPU%   MEMORY(bytes)   MEMORY%
node-1        850m         42%    6144Mi          75%
node-2        1200m        60%    8192Mi          100%
node-3        400m         20%    3072Mi          37%

关键判断指标：当节点 CPU% 持续超过 80% 或 MEMORY% 超过 90% 时，该节点处于高负载状态，可能引发 Pod 驱逐、调度失败或应用性能下降。上例中 node-2 内存已达 100%，需要立即介入。

4.3 kubectl top pod：Pod 级资源消耗定位

定位到高负载节点后，使用 kubectl top pod -n <namespace> 查看具体哪些 Pod 消耗了最多资源。

# 查看 kube-system 命名空间下 Pod 资源使用
kubectl top pod -n kube-system

# 输出示例：
NAME                              CPU(cores)   MEMORY(bytes)
coredns-5d4dd4b4d9-abc12          3m           15Mi
etcd-node-1                       45m          450Mi
kube-apiserver-node-1             120m         890Mi
kube-scheduler-node-1             8m           35Mi

最佳实践：结合 -l 标签选择器过滤特定应用组，例如 kubectl top pod -n production -l app=nginx，快速定位业务 Pod 的资源消耗。

4.4 资源竞争诊断流程

以下流程展示了从节点到 Pod 再到容器的逐层下钻诊断路径：

全局扫描：kubectl top node 找出 CPU% 或 MEMORY% 超过 80% 的节点。
节点定位：使用 kubectl describe node <node-name> 查看节点上的 Pod 列表和资源分配。
Pod 筛选：kubectl top pod --all-namespaces --field-selector spec.nodeName=<node-name> 列出该节点所有 Pod 的资源使用。
容器级分析：对资源异常的 Pod 执行 kubectl top pod <pod-name> -n <ns> --containers，定位具体是哪个容器导致资源竞争。

  案例：某生产集群 node-5 内存使用率 95%，通过上述流程发现一个 Java 应用 Pod 的 init-container 未设置 resources.requests，导致与主容器共享内存时发生 OOM 竞争。修复后节点内存使用率降至 60%。

4.5 调度亲和性校准中的资源视角

在调整 Pod 亲和性（podAffinity）或节点亲和性（nodeAffinity）时，必须结合 top 数据验证调度效果：

反亲和性场景：将高资源消耗的 Pod 分散到不同节点，避免单节点过载。使用 kubectl top node 验证分散效果。
亲和性场景：将需要低延迟通信的 Pod 调度到同一节点，但需确保该节点有足够剩余资源。使用 kubectl top pod --field-selector spec.nodeName=<node> 检查节点上已有 Pod 的资源占用。
资源预留验证：调度器基于 Pod 的 requests 做决策，但实际使用量可能远超 requests。top 命令暴露实际使用量，帮助判断是否需要调整 requests 或增加节点。

4.6 常用参数与组合技巧

参数组合	用途	示例
`--all-namespaces`	查看所有命名空间的 Pod	`kubectl top pod --all-namespaces`
`--field-selector`	按节点或状态过滤 Pod	`kubectl top pod --field-selector spec.nodeName=node-1`
`-l`	按标签选择器过滤	`kubectl top pod -l app=nginx,tier=frontend`
`--sort-by`	按 CPU 或内存排序	`kubectl top pod --sort-by=memory`
`--containers`	展开容器级别指标	`kubectl top pod my-pod --containers`

效率技巧：将 kubectl top pod --all-namespaces --sort-by=memory 与 head -10 结合，快速获取集群中内存消耗最高的 10 个 Pod，是日常巡检的常用命令。

4.7 常见问题与避坑

Metrics Server 未部署：执行 top 命令报错 error: Metrics API not available。需先部署 Metrics Server，可通过 kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml 安装。
数据延迟：Metrics Server 默认 15 秒采集间隔，刚启动的 Pod 可能需要等待 1-2 个采集周期才能显示数据。
CPU 单位：输出中的 CPU(cores) 以毫核（m）为单位，1000m = 1 核。CPU% 是相对于节点总 CPU 的百分比。
内存单位：MEMORY(bytes) 以 MiB 为单位，MEMORY% 是相对于节点总内存的百分比。
非实时性：top 命令展示的是瞬时快照，对于突发性资源竞争，建议结合 kubectl describe node 查看历史驱逐事件，或使用 Prometheus 等监控系统查看趋势。