评估集群整体资源利用率，关键要看节点层面的真实消耗和可用容量之间的比例。具体来说，CPU 和内存使用率都应按这一公式计算：把所有节点的实际使用量相加，再除以可用总量，最后乘以 100%。数据来源也不能搞错，应该取自 Metrics Server、cAdvisor 或云厂商监控这类节点级监测数据，而不是简单把 docker stats 的结果直接累加。
容器集群整体资源利用率不是单个容器 stats 的简单加总，而是从集群维度统计节点层的真实消耗与可用容量之比。核心看 CPU 和内存两项，计算逻辑明确，但数据来源和口径容易混淆。
CPU 和内存使用率的准确计算方式
集群整体资源利用率由底层节点的实际负载决定，公式如下：
- CPU 使用率 = （所有节点 CPU 实际使用量之和 ÷ 所有节点可用 CPU 总量） × 100%
- 内存使用率 = （所有节点内存实际使用量之和 ÷ 所有节点可用内存总量） × 100%
注意，这里说的“实际使用量”，指的是基于节点操作系统层面的统计结果，比如 /proc/stat、cgroup v2 的汇总数据；它不是容器 request/limit 这类配置值，也不是 docker stats 这类从容器内部视角看到的数据。
为什么不能用 docker stats 加总？
docker stats 统计的是单个容器的 cgroup 资源视图，存在三类偏差：
- 只覆盖运行中容器，忽略系统进程、kubelet、容器运行时等宿主机开销
- 多容器共享内核调度和内存页，存在重复计算或未覆盖区域
- 无法反映节点级内存回收、swap 使用、page cache 等真实压力信号
所以即使把所有容器的 CPU% 和 MEM% 加起来，结果既无物理意义，也不等于集群仪表盘上显示的数值。
生产环境推荐的数据来源
真正可信的集群整体利用率，应通过以下任一方式获取：
- Kubernetes Metrics Server + kubectl top node：提供实时节点 CPU/内存使用率，数据来自 kubelet 汇总，延迟约 15–60 秒
- cAdvisor（通常内嵌在 kubelet 中）：暴露 /metrics/cadvisor 接口，含节点维度的 container_root 指标，是 Prometheus 常用采集源
- 云厂商控制台（如 TKE、ACK、EKS）：后台已聚合节点监控数据，直接展示“集群 CPU 使用率”“集群内存使用率”，并标注水平线（例如 CPU ≤ 30% 为健康）
配套看的两个关键指标：申请率
除了实际使用率，还需同步关注：
- CPU 申请率 = （所有 Pod 的 spec.containers[].resources.requests.cpu 之和 ÷ 集群可分配 CPU 总量） × 100%
- 内存申请率 = （所有 Pod 的 spec.containers[].resources.requests.memory 之和 ÷ 集群可分配内存总量） × 100%
申请率反映资源预留上限，若接近 100%，说明集群已无法调度新 Pod；若申请率高而使用率低，说明 request 设置过宽，存在优化空间。
