集群整体资源利用率需按节点层实际消耗与可用容量之比计算，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 设置过宽，存在优化空间。
