K8s Guaranteed QoS 买"稳"到底值多少钱：怎么按 SLI 给无状态服务分级定 requests/limit 的 gap

背景 我负责一个 12 节点（16C64G，Kubernetes 1.28.9，containerd 1.7.13，cgroup v2，内核 5.15）的生产集群，上面跑着 30+ 个 Java 17 / Spring Boot 3 与 Go 写的无状态服务。当前资源策略是"一刀切"：所有无状态 Pod 都设 requests = limits（Guaranteed QoS），目的是保命——过去一年节点内存吃紧时，确实有几个 requests 设得规整的 Guaranteed Pod 没排到驱逐队首而活了下来。

现象 / 卡点 但 FinOps 给的账不好看：节点 CPU 的 request 装箱率只有约 55%，也就是一半"配额"平时闲置；按成本折算，这套 Guaranteed 策略比"requests < limits 的 Burstable 策略"大约贵 30%。我的纠结是：为这份"稳"多花 30% 的钱，到底值不值？

已尝试的排查

1. 我试过把非核心服务的 limit 放宽到 1.5× request，想靠 Burstable 省成本，结果高峰期 CFS 节流把 P99 抬了 3 倍（现象与站内几篇 CPU limit 节流复盘一致），被迫回滚；
2. 我想按 SLI 给服务分级（核心 / 次核心 / 可丢弃），每档给不同的 requests/limit gap，但卡在我不知道用什么指标做分级判据，也不知道每档 gap 给多少才既省钱又不踩驱逐 / 节流红线。

期望得到的答案形态 希望给一个可落地、带数字的分级方案：(a) 三档（或两档）判据——用什么 SLI（P99 延迟、驱逐率、nr_throttled/throttled_time 比例）做红线，阈值大概多少；(b) 每档 requests/limit 的 gap 建议范围（如核心档 gap=0，次核心档 gap=20~40%，可丢弃档不设 limit）；(c) 走 Burstable 时如何配合节点级驱逐排序（memory/cpu 的 allocatable 预留、QoS 权重）兜底，避免"省成本省成驱逐"。最好给一个我能直接套到 30+ 服务上、算得出成本收益的公式或对照表。