K8s 里 CPU limit 到底该不该设：CFS throttling 让 P99 抖，不设 limit 又会被 noisy neighbor 吃掉——你们生产上到底怎么选？

【背景】 做容器化运维 5 年，最近一年在 3 个团队都撞上同一个争论：K8s 里 CPU limit 到底该不该设？

我自己的场景：K8s 1.28，混部 + 单租户并存。单租户核心业务 Pod，一开始按 request=limit=2C 设，上线后 P99 明显抖动——kubectl top pod 显示 CPU 峰值才 1.8C，但 Prometheus 里 container_cpu_cfs_throttled_seconds_total 一路在涨。去掉 limit 只留 request=2C 后，P99 立刻平了。但混部节点上，某个 batch job 不设 limit 直接吃满 16C，把同节点另一个在线服务的 P99 拖到 3 倍。两个方向，各踩一次坑。

【常见分歧 / 几种做法】

1. 激进派：一律 request=limit（Guaranteed），理由是可预测、容量好算。代价：CFS throttling，P99 抖动是常态。
2. 保守派：只设 request 不设 limit（Burstable），理由是 throttling 是 K8s 反模式。代价：noisy neighbor，混部节点上必炸。
3. 分级派：在线服务 limit 给到 request 的 2–4 倍，批处理严格 limit；按 SLO 分档。
4. 平台派：不鼓励业务自己写 limit，用 VPA / KEDA / 平台默认值兜底，业务只写 request。

四种做法我在不同公司都见过，没有一种是"标准答案"，但每一家踩过的坑都不一样。

【我的倾向与理由】 CPU limit 不是"要不要设"的问题，是"给谁设、设多少、throttling 怎么补偿"的问题。我现在的默认策略：

• 在线服务：request 按 P95 用量 × 1.2，limit = request × 2（给突发留 1 倍 headroom），同时把 container_cpu_cfs_throttled_periods_total / container_cpu_cfs_periods_total 这个比例纳入告警，>5% 就 warn、>15% 就 page。这个比例比 CPU 使用率更有预警价值——使用率看的是"忙不忙"，throttle 比例看的是"被卡了几次"，后者才是 P99 抖动的先行指标。
• 批处理：limit 必须设，且 ≤ (节点可分配 CPU - 在线预留) / batch 副本数，用 K8s limit + cgroup v2 cpu.max 双重兜底，防止业务自己写错 YAML。
• 关键判断：业务是 CPU-bound 且 P99 敏感时，limit 就是"性能税"，能免则免；业务是 IO-bound 或突发型时，limit 反而是保护，不设才是事故。

我反对"一刀切"，也反对"让业务自己拍脑袋"。平台侧应该给一个默认策略 + 例外审批通道，而不是让每个团队自己发明一套。

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

1. 你们生产上 CPU limit 的默认策略是什么？平台级规范还是业务自定？VPA 用得多吗？
2. container_cpu_cfs_throttled_seconds_total 这个指标你们用吗？阈值怎么定、谁负责告警？
3. 混部节点上，你们怎么给 batch job 限流？只靠 K8s limit 还是叠加 cgroup v2 的 cpu.max / cpu.weight？
4. 有没有人试过比 K8s limit 更细粒度的 CPU 隔离方案（比如 QoS 分级、cgroup 嵌套、甚至 Wasm sidecar），落地成本和收益怎么权衡？
5. 你们踩过"去掉 limit 后 P99 平了，但节点整体被吃满"这种坑吗？后来怎么解？

我倾向"在线宽松 + 批处理严格 + throttle 比例做先行指标"，但我知道不同规模、不同混部程度下最优解会差很远。想听听一线的真实数据，尤其是 throttle 比例的阈值——这个数字我目前拍的是 5% / 15%，但没有跨团队对齐过。