Kubernetes 资源治理：requests 和 limits 设错，比不设更危险

一个团队给所有 Pod 设了相同的 requests 和 limits，CPU 500m、内存 1Gi。上线后频繁 OOMKilled，CPU 被限流，但节点整体利用率很低。问为什么这么设，回答是“复制粘贴的，看起来安全”。

requests 和 limits 的语义不同。
requests 影响调度，决定 Pod 被放到哪个节点，也影响 CPU 权重。limits 影响运行时上限，CPU 超限被 throttle，内存超限被 OOMKill。把两者设成一样，等于既没有弹性又容易被杀。

CPU 和内存要分开对待。
CPU 是可压缩资源，超限被限流，不会杀死 Pod，所以 CPU 的 limits 可以适当放宽甚至不设，让突发流量用满节点空闲。内存是不可压缩资源，超限直接 OOMKill，所以内存 limits 要按实际峰值加缓冲设置，requests 可以略低于 limits，允许一定超卖。

一个可操作的流程：
先不设 limits，只设保守的 requests，观察一周的实际用量分布；按 P95 设 requests，按 P99 加 20%—30% 设内存 limits；CPU limits 可以设为 requests 的 2—3 倍或不设；用 VPA 的 recommend 模式辅助，但不要自动应用；对关键服务设 PodDisruptionBudget 和优先级。

常见误区：
第一，所有服务用同一套资源配置。第二，只看平均值不看峰值。第三，忽略 JVM、Node.js 等运行时自己的内存上限，容器 limits 和堆上限不匹配。第四，没有监控 throttle 和 OOM 指标，出了问题才发现。