K8s 节点超卖率（overcommit）到底敢压到多少：requests 按实际用量装箱，怎么量化"超卖→节点热点→驱逐"的风险，有没有可复现的压测/指标方法？

背景

8 年嵌入式出身，习惯了"资源就是钱"——MCU 上 512KB RAM 每一字节都要算清楚，超了直接 hard fault，没有"再给点"的余地。转 K8s 运维后最不适应的一点：调度器按 requests 装箱，但 requests 和"真实峰值用量"之间可以差好几倍——这个倍数（超卖率 / overcommit ratio）到底敢压到多少，我至今没有答案。

具体场景：K8s 1.28.9 + cgroup v2，约 40 节点混合集群，同节点混部在线 API（Java/Go 无状态）+ 少量批处理。现在全量 Pod 的 cpu.requests 加起来约为节点可分配 CPU 的 70%~85%（即超卖率约 1.2~1.4×），内存 requests 合计约节点的 80%。这个数当初是"抄"来的，从没被认真论证过。

现象

• CPU：监控里节点整体利用率长期只有 45%~55%，看似很空，但个别节点在早高峰会出现 cpu.pressure（PSI）spike、部分 Pod 被 CFS throttling（cpu.stat 的 nr_throttled 涨），P99 抖动可复现。
• 内存：requests 合计 80% 时，节点 page cache + working set 偶发顶到 memory.events 的 high/oom_kill 边缘，驱逐（eviction）和 node-pressure 触发时没有提前量，事后才看到。
• 核心矛盾：超卖率太低（requests 设高）= 钱白花，利用率难看；太高 = 热点节点、throttling、驱逐，稳定性买单。这两头我都见过翻车现场，但"中间那个安全点在哪"没人给过依据。

已尝试的排查与结果

1. 拉了 container_cpu_cfs_throttled_seconds_total / container_cpu_cfs_periods_total 做 throttling 率告警，能抓到热点 Pod，但只能事后看到"谁被卡了"，不能事前回答"超卖率该设多少"。
2. 用 Prometheus 的 PSI（cpu.pressure.avg10）做压力预警，比 OOM 早一些，但阈值全是拍的，不同负载（在线 vs 批处理）没法共用一个数。
3. 参考了几篇站内讨论：CPU limit 触发 CFS throttling 把 P99 长尾翻 5 倍的复盘（id=140）、limits 默认值之争（id=1568）、CPU limits 三种流派各有翻车现场（id=729）——但它们都聚焦在"limits 设不设 / 设多少"，没有正面回答"requests 该压到实际用量的百分之几才安全"这个装箱/超卖侧的问题。

期望得到的答案形态（越具体越好）

1. 你们团队节点超卖率（requests 合计 / 节点可分配）的具体数字和依据？在线集群和混批集群会不会用不同超卖率？
2. 有没有可复现的量化方法：比如用一周线上 p99 用量 + 压测峰值倒推 requests 上限，再留多少余量才不把超卖率顶穿？
3. 事前预警：除了 PSI，还有哪些指标能在 throttling/驱逐发生前给出"这节点超卖过头了"的信号？阈值怎么定才有提前量（而不是事后复盘）？
4. 成本 vs 稳定性：你们怎么给"超卖率再压 10%"这类决策做可量化的 ROI——省多少台节点的钱，换多少 P99 / 驱逐风险？想听具体数字，不只是结论。