【背景】
最近帮两个团队做 K8s 集群（1.28，cgroup v2）的 P99 治理，都撞上了同一道选择题：CPU limit 到底设不设、怎么设。
团队 A：40 个微服务，大部分 Java（JDK 17，G1GC），requests=limits 统一 2C，集群 12 节点 32C。上周一次 P99 抖动，定位到是 CFS throttling——container_cpu_cfs_throttled_periods_total / container_cpu_cfs_periods_total 在峰值时段飙到 8%，throttle 时间占比 3%。把 limit 从 2C 放到 4C 后抖动消失，但代价是集群可调度余量直接少了 80C，下次扩容周期得推后一个 sprint。
团队 B：15 个 Go 服务 + 3 个 Python 任务，不设 limit（只设 requests），集群 8 节点 16C。上个月一个 Python batch job 吃满 16 核跑了 20 分钟，同节点上一个 Go 服务的 P99 从 8ms 飙到 45ms，持续 8 分钟。事后看 node_load1 飙到 30+，cgroup v2 的 cpu.stat 里该 Go 服务的 nr_throttled 是 0（没 limit 自然不会被 throttle），但 user_usec 被挤占了。
两个团队、两种痛：一个是 limit 卡住了 P99，一个是没 limit 被邻居炸了 P99。
【常见分歧——三种流派】
我调研了一圈，大致三种做法：
流派一：requests=limits（Guaranteed QoS），limit 设宽松。 理由：可预测、QoS 高、驱逐顺序明确。适合对延迟敏感的服务。 代价：limit 必须 ≥ 真实峰值，否则 CFS throttling；集群整体超卖率被压死，容量利用率上不去。
流派二：只设 requests 不设 limit（Burstable QoS）。 理由：弹性好，峰值时能借用节点空闲 CPU。 代价：无 limit 的 Pod 在节点过载时是"无牌玩家"——内核调度器不保证它拿到 CPU；而且 Burstable 的驱逐优先级低于 Guaranteed，OOM / CPU 压力驱逐时它先走。
流派三：limit 设大（4C~8C）+ 配合 HPA 扩副本。 理由：单副本 limit 够宽就不会 throttle，靠副本数摊平。 代价：副本数多了资源碎片化；HPA 扩缩容的滞后窗口（60s~120s）内仍然会 throttle，而且 HPA 是按 CPU 利用率触发——如果已经被 throttle 了，看到的利用率反而是"假的低"，HPA 反应更慢。
【我的倾向与理由】
我的默认策略是「按负载类型分三档」，不追求全局统一：
-
延迟敏感型（在线 API、支付链路、搜索）：requests=limits，limit 按 P99 CPU 用量的 2 倍设（注意是 P99 不是 P95，因为 P99 就是你要保的那个尾）。cgroup v2 下
cpu.weight保持默认 100，如果节点上还有别的 Guaranteed Pod 争抢，至少 shares 不会让它在 idle 时饿死。container_cpu_cfs_throttled_periods_total占比 > 1% 就告警，不要等 P99 抖了再查。 -
吞吐型（批处理、ETL、消息消费、数据同步）：只设 requests，不设 limit。这类服务对单请求延迟不敏感，总吞吐量才是目标。配合 KEDA 按队列深度扩缩，把"一个 Pod 吃满"变成"多个 Pod 各吃一部分"。
-
混合型（同一服务既有在线 API 又有后台任务）：拆服务。我知道这听起来像废话，但 80% 的混合负载 P99 问题都是"在线请求和后台任务抢同一组 CPU"导致的，拆开后各自按上面两档配就行。拆不了的至少把后台任务丢到独立的 sidecar 容器里，用
cpu.max单独限。
核心原则：limit 不是"资源上限"，是"你对这个 Pod 的 CPU 需求做出的优先级声明"。设了 limit，你就是 Guaranteed，内核调度器会优先保你；不设 limit，你就是 Burstable，节点过载时你的优先级在 Guaranteed 之下。这不是"公平"问题，是"谁先被饿"的问题。
【想听大家在什么场景下怎么选】
想收集几个具体场景下的选择，特别是踩过坑的：
-
你的集群里 Guaranteed / Burstable / BestEffort 的 Pod 比例大概多少？我猜大多数团队 80% 以上 Guaranteed，但实际跑批服务应该 Burstable 更合理——你们真这么分了吗？
-
Java 服务你们 limit 一般设多少？是 P99 × 2 还是有经验值（比如"JDK17 + G1 至少给 4C 才不抖"）？JVM 的 GC 线程是额外占 CPU 的，limit 算不算 GC？
-
cgroup v1 还是 v2？v1 下 CFS bandwidth controller 是 per-thread 的，v2 下
cpu.max是 per-cgroup 的——同一个 Java 服务在两种 cgroup 下 throttling 行为不一样，你们踩过 v1→v2 迁移后 limit 要重调的坑吗？ -
有没有团队在用
cpu.priority（如果内核支持的话）或 eBPF 做更细粒度的 CPU 调度？纯靠 K8s 的 QoS 三级在混合负载下够用吗？