K8s 混合负载：在线服务 SLO 预算和离线批处理吞吐之间的「余量」到底留多少，你们怎么算这笔账？

【背景】 我维护一个自建 K8s 1.28 集群（cgroup v2），节点规格 32C256G，上面同时跑两类负载：

• 在线：约 40 个 Java/Go 服务，对外 P99 SLO 99.9%（月），入口峰值 12k QPS；
• 离线：ETL / 物化视图回填 / 报表预计算，单作业峰值可吃满 16C，跑批窗口 22:00–06:00，但白天也有零星补数。

我们踩过的坑：

1. 早期 request=limit 全开，批作业白天补数时在线 P99 直接飘 3 倍，值班同学骂了两周；
2. 后来干脆给批作业单独划 6 个节点（物理隔离），结果在线业务扩容期那 6 个节点基本空转，成本核算被财务追着问；
3. 现在用的是「在线 SLO 预算 80% + 批作业吃剩余 20% + 自适应降级」的混合方案，但 80% 这个数字到底怎么来的，团队内部至今没有一个人能算出严格推导，都是拍脑袋 + 事故复盘反推。

【几种常见做法，各打各的】

• A. 硬隔离：批作业独占节点池（taint + toleration）。优点是干净、可预测；缺点是峰谷错配时资源利用率能掉到 30% 以下，自建集群成本压力极大。
• B. 软隔离：全池共享，batch 设 request 低 / limit 高，靠 K8s 调度 + cgroup 兜底。优点是利用率好看；缺点是 nois-neighbor，在线 P99 偶发飘 2–5x，且很难事前预警。
• C. 预算 + 自适应：在线按 SLO 留一份「保底预算」（比如 80%），批作业吃剩余，配合基于 SLO 余量的在线降级（限流 / 降级非核心接口）动态调整批作业并发。优点是弹性最好；缺点是控制环复杂，调不好会出现 SLO 余量在两个方向上同时被吃光。

【我的倾向】 我倾向 C，但前提是「预算」这个数字必须有据可查，而不是拍脑袋：

• 在线预算 = P99 SLO 反推的容量 × 1.15（留 15% 抖动缓冲）；
• 批作业 limit 硬顶 = 集群总容量 − 在线预算，且批作业走独立的 Job 控制器，按 SLO 余量（当前 P99 / SLO 的比值）动态降并发，而不是固定并发；
• 关键指标不是 CPU 利用率，而是「SLO 余量水位」——P99 当前值 / SLO 阈值，>0.85 就开始压批作业，>0.95 直接停。

想听大家拍砖的几个具体问题：

1. 你们线上「在线预算」这个数字是怎么定出来的？有没有可复现的推导路径（压测 / 历史分位数 / 成本反推）？
2. 批作业走 K8s Job 还是独立调度器（如 YARN / 自研）？两者在「按 SLO 余量动态降并发」这件事上，落地难度差多少？
3. 硬隔离和软隔离你们各占多少比例？有没有「白天硬隔离、夜间软隔离」这种时间切片的做法，运维复杂度扛得住吗？
4. 如果只能选一个指标做「批作业该不该降并发」的决策输入，你们选哪个？我选 SLO 余量水位，你们选什么？

先抛砖，欢迎拿真实数字来对线。