3. 利用率现状诊断
在动手做任何优化之前，必须先回答一个看似简单却极易被跳过的问题：当前集群到底浪费在哪里、浪费了多少、先改哪一处收益最大？利用率现状诊断就是把这个模糊的“感觉资源紧张/资源闲置”转化为可量化、可排序的工程结论。它的产出不是一张漂亮的监控大屏，而是一份优化基线 + 优先级清单：基线用于后续对比“优化是否真的生效”，优先级用于决定先动谁、后动谁。
一、诊断的四个核心视角
资源浪费、超卖、碎片化、热点，是四类性质完全不同的问题，必须用不同的指标去识别，不能混为一谈。
- 资源浪费：申请量（Request）远大于实际使用量（Usage）。典型表现是 CPU Request 使用率长期低于 20%，内存 Request 使用率低于 40%。浪费的本质是“占着不用”，它直接推高成本，但不一定造成故障。
- 超卖：节点上所有 Pod 的 Request 之和超过节点可分配资源，或 Limit 之和远超物理容量。超卖本身是提高利用率的合法手段，风险在于突发流量下发生 CPU 节流（throttling）或内存 OOM。
- 碎片化：节点剩余资源总量足够，但被切成小块，无法容纳一个较大的 Pod。表现为大量节点 CPU 可分配余量在 1～2 核之间，而待调度 Pod 需要 4 核。
- 热点：少数节点或 Pod 承担了绝大部分负载，CPU/内存/网络/磁盘 IO 显著高于同类对象，是稳定性风险与性能瓶颈的来源。
二、从监控数据到诊断结论
诊断依赖三类数据源：指标数据（Prometheus 采集的 container_cpu_usage_seconds_total、container_memory_working_set_bytes、kube_pod_container_resource_requests 等）、调度与容量数据（节点 Allocatable、已分配 Request、Pod 分布）、业务侧数据（QPS、P99 延迟、错误率）。只有把资源指标和业务指标对齐，才能判断“低利用率”是健康的还是危险的。
下面这张图展示了从原始指标到优先级清单的完整诊断链路，以及四类问题各自的判据与输出：
三、关键指标的计算与判读
诊断不能只看“CPU 使用率 30%”这种单点数字，必须用比值型指标。最核心的两个是：
# 容器级 Request 使用率（近 7 天 P95，避免被瞬时峰值误导）
cpu_req_util = rate(container_cpu_usage_seconds_total[5m])
/ kube_pod_container_resource_requests{resource="cpu"}
# 节点级分配率（衡量超卖程度）
node_alloc_ratio = sum(kube_pod_container_resource_requests{resource="cpu"})
/ kube_node_status_allocatable{resource="cpu"}
# 节点级实际使用率（衡量真实负载）
node_usage_ratio = sum(rate(container_cpu_usage_seconds_total[5m]))
/ kube_node_status_allocatable{resource="cpu"}判读时要注意三点。第一，用 P95 而非平均值：平均值会把夜间低谷和白天高峰抹平，掩盖真实峰值需求。第二，区分“低使用率”与“低使用率但高波动”：一个 P95 使用率 15%、但峰值冲到 90% 的服务，不能简单降 Request，否则高峰期会被节流。第三，内存不能只看使用率：内存是“用多少占多少”，Working Set 长期稳定在 Request 的 30% 才是安全的降配信号；若 Working Set 波动大，降配会触发 OOM。
四、建立优化基线
基线是“优化前的快照”，没有它就无法证明优化有效。一份可用的基线至少包含以下字段，建议按命名空间或业务线聚合：
| 字段 | 含义 | 示例值 |
|---|---|---|
| namespace | 业务命名空间 | order-service |
| cpu_req_util_p95 | CPU Request 使用率 P95 | 18% |
| mem_req_util_p95 | 内存 Request 使用率 P95 | 42% |
| node_alloc_ratio | 节点 CPU 分配率 | 1.35 |
| throttle_rate | CPU 节流比例 | 3.2% |
| oom_count_7d | 7 天 OOM 次数 | 0 |
| pending_pods | Pending Pod 数 | 6 |
| cost_month | 月度资源成本估算 | ¥ 12,400 |
基线数据建议用脚本定期导出为 CSV 或写入时序库，每次优化后重新采集一次，形成“基线—优化—复测”的闭环。示例中 order-service 的 CPU Request 使用率仅 18%，说明存在明显浪费；而 node_alloc_ratio 达到 1.35，说明集群整体已在超卖，两者叠加意味着“申请量虚高但节点已排满”，此时降 Request 既能释放调度空间，又能降低成本，属于典型的高收益动作。
五、优先级排序的实操方法
把四类问题映射到优先级，可以用一个简单的打分模型：收益分（预计节省的核数或成本）、风险分（是否影响稳定性）、成本分（改造工作量）。三者归一化后加权，得到排序。实践中通常遵循以下顺序：
- 先处理“低风险高收益”的浪费：如长期低使用率的无状态服务降 Request，改动小、可灰度、收益直接。
- 再处理热点：热点是稳定性隐患，即使收益不直接体现为成本，也应优先于纯成本优化。
- 然后处理碎片化：通常需要调整调度策略或 Pod 规格，涉及面较广，放在中期。
- 最后处理超卖：超卖调整直接影响容量安全边界，必须配合压测和灰度，放在后期。
诊断的终点不是“发现问题”，而是“形成一份可执行、可验证、可回滚的优化清单”。当基线、判据、优先级三者齐备，后续的每一项优化动作才有据可依，也才能在优化后回答那个最关键的问题：我们到底省了多少，代价是什么。