requests 设低了省成本，但 HPA 和驱逐都会失真：你的集群到底把「利用率」当目标还是把「余量」当目标？

【背景】 做了 5 年云原生，最近一年带团队做集群降本项目，把核心原则从「按峰值留余量」切换到「按 P95 利用率提密度」。节点数从 41 砍到 26，账单确实降了 30%+。但随之而来的三类问题，让我开始怀疑我们其实是在用「稳定性」换「账单」，而不是真的省：

1. HPA 失真。HPA 默认看 CPU Utilization = usage / request，request 设得越激进，分子分母同时被压缩，一个 8C 的 Java 服务 request 给 2C，平时利用率 40% 看起来挺健康，但一次流量尖峰直接打到 90%+，HPA 触发扩缩容的窗口期里 P99 已经先抖了。
2. 驱逐风险被掩盖。request 设得低意味着 Guaranteed/Burstable 边界很窄，一旦邻居 Pod 突发，内核的 OOM 排序和 Kubelet 的驱逐压力计算都会把我们这种「看起来占用不高」的服务优先干掉——因为它的 request 本来就低，相对占用反而高。
3. 团队协作成本。每个服务的 request 到底填多少，从「运维给个默认值」变成了「每个 SRE 都要看 6 个月监控曲线」，新人上手周期从 2 周拉到 6 周。

【常见分歧 / 几种做法】

• 派 A：requests = P95 用量，limits = 2×P95，追求密度，接受 HPA 反应慢。
• 派 B：requests = 日常均值，limits 不设（或给个 4× 的硬顶），让内核 CFS 自然调度，靠节点级 headroom 兜底。
• 派 C：只对核心链路 Guaranteed，其余全部 Burstable 不设 limit，用 VPA 定期调 request。
• 派 D：干脆不追求密度，按业务 SLO 反推容量，requests 直接给到能扛 P99 的量，账单贵但睡得着。

【我的倾向与理由】 我倾向「派 B + 派 D 的混合」：核心链路（支付、订单、消息）按 P99 反推 requests，宁可贵 20%；非核心（后台任务、报表、爬虫）requests 给 P75，limits 一律不设，让 CFS 自己调度。理由很简单——limits 在生产环境是个伪需求，它唯一的作用是「防止某个 Pod 吃光 CPU」，但代价是 CFS 节流带来的 P99 抖动，后者对用户的伤害远大于前者。而 requests 才是真正的「容量契约」，必须按 SLO 反推，不能按账单反推。

成本优化不该以「SLO 不变」为底线吗？如果优化后 P99 从 120ms 涨到 180ms，省下的钱和客诉成本哪个高？

【想听大家在什么场景下怎么选】

• 你的集群 requests/limits 是怎么定的？有没有一个「按 SLO 反推」的公式或工具链？
• limits 你设不设？设的话是几倍？不设的话怎么防「CPU 吃光」？
• HPA 是看 CPU Utilization 还是自定义 metric（QPS、队列深度）？为什么？
• 如果让你把账单砍 30%，你愿意为此接受 P99 涨 50% 吗？在什么业务下你会说不？

期待大家贴真实的数字（节点数 / Pod 数 / 平均 request / P99 变化），别只谈原则，我想看数据。