资源监控与优化

集群跑起来后，常见问题是 节点利用率低却报 Pending，或 limits 虚高导致浪费、limits 过低导致 throttle/OOM。本课对应路线图 monitoring-optimizing-resource-usage——用指标驱动 rightsizing、HPA 调参、节点池伸缩，与 k8a-resources 的配额形成闭环。

学习目标

• 用 Prometheus 查询对比 Pod requests vs 实际 CPU/内存使用
• 识别 over-provision 与 under-provision 的信号
• 列出 CodeRoadMap backend 资源优化检查清单

看哪些数

指标 / 视图	回答什么
container_cpu_usage_seconds_total vs request	CPU 是否长期远低于 request
内存 working set vs limit	是否频繁 OOM 或 limit 过大
kube_pod_status_phase{phase="Pending"}	调度失败是否因 Insufficient 资源
节点 allocatable - 已分配 requests	是否「看起来有空但 schedule 不上」
HPA 当前副本 vs max	是否触顶或从未扩容

数据源来自 k8a-obs 的 kube-state-metrics 与 cAdvisor；Grafana 面板可参考 prom-grafana 与 obs-dashboards。

Over-provision 信号

Pod CPU request: 1000m
P95 实际使用:     80m  持续 7 天
→ 浪费调度槽位，节点看似满实则空

Rightsizing 流程：

1. 取 7–14 天 P95/P99 使用量（排除压测窗口）
2. request 设为 P95 + 小缓冲；limit 略高于峰值
3. staging 验证后再改 prod values（helm-release）
4. 滚动重启观察 OOM/throttle 告警

Java/Spring 服务注意 JVM 堆 + metaspace + direct buffer 一并算进 memory limit。

Under-provision 信号

现象	可能原因
CPU throttle 高	limit 过低
OOMKilled	memory limit < 实际峰值
Latency 升、CPU 顶满	request 过低导致节点过载
HPA 频繁抖动