【背景】 做了 10 年嵌入式，后 5 年主力在容器化与 K8s 运维。资源调度这块我见过三个阵营，每次新人入职都要重新吵一遍，但每次吵完没有定论——因为答案取决于负载类型，而"取决于负载类型"这句话本身不够用。
我维护的集群：K8s 1.28.9，containerd 1.7.13，内核 5.15.0-91，cgroup v2，节点 16C64G（7200RPM SATA），在线服务 + 离线 batch 混跑。
【三种常见做法】
- 阵营 A（全设）：requests + limits 都设。理由："K8s 就是要把资源锁死，不然 noisy neighbor 会把在线服务拖死。"
- 阵营 B（只设 requests，不设 limits）：理由："CPU 设 limits 就是自找 CFS throttle，P99 抖了你都不知道为什么。memory 倒是可以设，OOMKill 总比 throttle 强。"
- 阵营 C（不对称）：requests 全设，limits 只设 memory，CPU 不设 limits。
【我的倾向：阵营 C，但有边界条件】 先说结论：在线服务 CPU 不设 limits，memory 设 limits；离线 batch 服务两个都设。
具体理由和踩过的坑：
1）CPU limits 的坑是 CFS throttling 是"静默"的。 cgroup v2 下 cpu.max 是硬限（"quota period"），一旦触发 throttle 不会发任何事件，不会打日志，不会触发 OOMKill。你只能事后看 container_cpu_cfs_periods_throttled_total / container_cpu_cfs_periods_total 的比值，或者看 node_exporter 的 container_cpu_cfs_throttled_seconds_total。 我见过一个 Go 服务（CPU limit 200m，稳态 180m），GC 一次 burst 到 250m，被 throttle 了 200ms，P99 从 3ms 涨到 12ms。事后复盘看了 2 小时才定位到是 CFS throttle，因为监控里 CPU 使用率曲线完全正常（throttle 期间 CPU 使用率反而下降，因为进程被暂停了）。
2）Memory limits 的坑是 OOMKill 是"致命"的。 throttle 是慢，OOMKill 是死。而且 OOMKill 之后 pod 重启，有启动时间，这段时间服务不可用。所以 memory limits 必须设，但要留 headroom：limits = 稳态 RSS × 1.5（Go 服务 GC 后 RSS 会回落，但 burst 时会涨；JVM 服务看 -Xmx + Metaspace + Direct Buffer）。
3）离线 batch 服务例外：CPU + memory 都设 limits。 batch 任务允许慢，不允许把在线服务的 CPU 或 memory 抢走。这里 limits 不是"限制性能"，而是"保护在线服务"。
4）K8s 1.28+ 的 PriorityClass + preemption 能不能替代 limits？ 理论上可以：在线服务 PriorityClass=1000，batch 服务 PriorityClass=100，节点资源紧张时调度器会驱逐 batch pod。但实际中 preemption 是"驱逐"不是"限流"，驱逐后 batch 任务要重新排队，对 SLA 的影响比 throttle 更大。所以我的判断是：PriorityClass 解决"谁先跑"，limits 解决"跑多快"，两者不互斥。
【想听大家在什么场景下怎么选】
- 你的集群里在线服务 CPU limits 设不设？设的话，limits 怎么算（requests × N？固定值？压测得出？）？
- 有没有踩过"设了 CPU limits 然后 P99 抖了，查了半天才发现是 CFS throttle"的坑？你们怎么把 throttle 指标纳入告警的？
- 离线 batch 和在线服务混跑，你们的隔离策略是什么？cgroup v2 io.max？ionice？还是纯靠 PriorityClass + node affinity？
- K8s 1.28+ 有没有新机制（比如 cgroup v2 的 cpu.idle、memory.high 软限）改变了你对 limits 的判断？
- 有没有人试过"不设任何 limits，纯靠 requests + 调度器"的方案？跑了多久，踩过什么坑？