K8s 混部节点上 batch job 被 CFS throttle 拖慢 + 同节点在线 P99 抖：cpu.max.burst 给 batch 用安全吗？"自身被限流"和"邻居被挤占"到底怎么拆开量化？

【背景】 我维护一个 14 节点自建集群（K8s 1.28.9，containerd 1.7.13，内核 5.15.0-91，cgroup v2 单层级，节点 32C128G，NVMe SSD）。节点上混跑两类负载：

• 在线：6 个 Java 17 / Spring Boot 3 无状态微服务，Pod 规格统一 request=2C / limit=4C / 8Gi；
• 批处理：每周二的对账 batch job（Go，16 核并行 worker，跑 20 分钟，CPU 长期 90%+），目前没设 cpu.limit（安全团队催着要加，还没加）。

【现象】 上周二 batch 跑的时候，同节点在线服务 P99 从稳态 45ms 抖到 310ms（持续约 15 分钟，batch 结束后 30s 内恢复）。事后看：

1. node_cpu_seconds_total 该节点 util 峰值 88%，没打满；
2. 在线 Pod 自身 container_cpu_cfs_throttled_periods_total 在 batch 期间增量很小（说明「自己」没怎么被 throttle）；
3. batch 容器自身 cpu.stat 的 nr_throttled 因为没设 limit 一直是 0——我没法直接证明是 batch「挤占」了在线，还是在线被自己的 limit 卡住了，只能靠排除法。

【已尝试】

• 给 batch 加 cpu.limit=12（留 20% 余量）压了一次：batch 跑完 19 分钟（+5%），在线 P99 抖到 280ms，比不限好但没根治；
• 看了社区里几篇 CFS throttling 复盘（id=1481、id=1496），方向一致：quota 是带宽上限不是算力保障；cpu.max.burst 是给「突发型」在线服务准备的透支卡；
• 但没人讨论过：把 cpu.max.burst 反向用在 batch job 上（limit=12 + burst=30s）能不能把 batch 自己那 +5% 的 slowdown 补回来，同时不放大对在线的挤占——burst 窗口内 batch 可以临时跑满 16 核，那 30s 内在线不是更惨吗？

【期望得到的答案形态】

1. 内核 5.15 上 cpu.max.burst 的实际生效边界（内核 changelog 或你们验证过的版本下限），以及 burst 窗口内对同节点其他 cgroup 的可见影响（是否有实测数据：burst 期间邻居 P99 / 邻居 throttle 率）；
2. 一套「在混部节点上把 batch 自身被 throttle 和 邻居被挤占」拆开量化的指标组合：具体到 PromQL 或 cpu.stat 字段，以及你们线上用的告警阈值（不是拍脑袋的 80%）；
3. batch + online 混跑时，CPU / IO 两侧的可复现配置组合：cpu.max / cpu.weight / io.max / io.weight 各自的取值逻辑，以及你们验证过的「batch 吞吐下降 ≤ X% 且 online P99 抖动 ≤ Y%」的实际数据点；
4. 如果你们的做法是「batch 不设 limit、只靠 io.max + 低优先级 + 时间窗口错开」，请给出你们验证过的窗口错开策略（cron 偏移多少分钟、节点亲和性怎么配），以及为什么不用 cpu.max.burst 给 batch。

希望答案里有真实数字，不接受「我们线上都设了 limit 没问题」这种一句话结论。