K8s 资源配额：requests=limits 一刀切 vs 留 burst 空间——40+ 服务你凭什么只有一套标准？

背景

我维护一个 12 节点（16C64G，K8s 1.28，containerd 1.7）的自建集群，上面跑着 40+ 服务：API 网关、订单服务、日志采集（fluent-bit）、batch ETL、监控 agent（node-exporter / cAdvisor）、CI 构建 worker……

去年团队做了一次"资源治理"，核心动作就一条：所有 Pod 统一 requests=limits，QoS 全部拉成 Guaranteed。理由是驱逐优先级最高、排障时不会被 cgroup 的 OOMKill 和节点驱逐搅在一起、容量规划简单。

当时确实爽了半年。但今年节点从 8 扩到 12 后，问题开始暴露：

• 一台 16C 节点上，fluent-bit 的 limit 设了 1C（实际稳态 80m），node-exporter 设了 0.5C（实际稳态 30m）——这些"守护型"组件白白锁掉了 1.5C 的调度空间；
• batch ETL 任务跑的时候 CPU 会飙到 8C，但稳态只要 2C，limits 设 8C 等于按 peak 付了 12 小时的账单；
• 反过来，API 服务的 limits 设太紧（=requests=4C），一次突发流量直接 OOMKill，比"被驱逐"还惨——至少驱逐还能 drain 30s。

三种常见做法（也是团队内部分歧）

| 派系 | 策略 | 典型理由 | |------|------|----------| | A：全 Guaranteed | requests=limits，所有服务 | 驱逐优先级最高；排障路径短；容量=limits，账单可算 | | B：分层 Guaranteed | API 服务 requests=limits；batch / agent 只设 requests 不设 limits（Burstable） | 关键路径保 SLO；非关键路径省成本 | | C：全 Burstable | 只设 requests，不设 limits（或 limits=requests×3） | 给 burst 留空间；避免 OOMKill；cgroup 兜底 |

我的倾向（欢迎打脸）

我目前倾向 派系 B + 一条硬规则：

1. 按"故障爆炸半径"分层：直接面向用户、P0/P1 的服务 → Guaranteed（requests=limits）；内部 batch、日志、监控 → Burstable（只设 requests）；
2. limits 的上限不是"能跑多少"，而是"节点超卖比允许多少"：我们把节点超卖比控制在 1.3× 以内（即 Σrequests ≤ 物理资源 × 1.3），limits 可以更高但节点上 Σlimits ≤ 物理资源 × 1.8。超了就不允许再调度；
3. 一个反直觉的点：对 Java 服务，limits 设成"能触发 OOMKill 但不触发 Full GC 风暴"的值，比"永远不 OOMKill"更合理——因为 Full GC 风暴时整个 Pod 的所有请求都卡住，不如 OOMKill 一个 Pod 让 K8s 拉起新实例（前提是 PDB 和 readiness 配好）。

想听大家聊的

1. 你们集群里 batch job / 日志采集 / 监控 agent 的 resource 策略分别怎么定？是全 Guaranteed 还是故意留 Burstable？
2. 有没有踩过 limits 设太高 → 节点超卖 → 驱逐风暴 → 雪崩 的坑？具体什么配置组合触发的？
3. 对 Java 服务，你们 limits 是设成"永不 OOMKill"还是"允许 OOMKill 但要 PDB 兜底"？JVM 的 -XX:MaxRAMPercentage 跟 K8s limits 怎么联动？
4. 你们有没有用 VPA（Vertical Pod Autoscaler）做推荐，还是纯手工 + Prometheus 历史 P95？

不追求"标准答案"，就想看看大家在不同规模（10 节点 vs 500 节点）、不同业务形态（纯 API vs 有 batch）下，怎么在"成本"和"不被 OOMKill"之间画那条线。