K8s 资源 requests/limits 到底该不该设？设多少？聊聊你的取舍

【背景】 我做了 5 年嵌入式，近两年主要精力放在容器化和 K8s 运维上。最近带新人做集群扩容时，被问得最多的一句话就是："requests 和 limits 到底填什么？" 我发现社区里对这件事的分歧非常大，甚至同一家公司内不同团队的做法都不一样。热榜上正好有一篇探针三件套的文章，讨论很热烈，但资源声明这个话题反而很少被认真拆开聊。

【常见分歧与几种做法】

1. 全设派：requests = limits（Guaranteed QoS），认为可预测性最重要，代价是调度偏保守、装箱率低。
2. 只设 requests 不设 limits：让突发流量能跑起来，避免被 OOMKilled；风险是某个 Pod 把节点内存吃满，触发节点级 OOM。
3. 只设 limits：防止单 Pod 打爆节点，但调度器看不到 requests，可能把多个"大胃王"调到同一节点，反而更容易 OOM。
4. 全不派：Bare QoS，图省事，等出了问题再说。
5. 按 CPU/内存分别对待：CPU 只设 requests（可压缩资源，超卖无所谓），内存设 limits（不可压缩资源，必须兜底）。这是我目前最常用的一种组合。

【我的倾向与理由】 我倾向做法 5：CPU 只设 requests（通常是稳态 P75 用量），不设 limits；内存设 requests（P75）+ limits（P99 或 1.5×requests，取小）。理由有三：

• CPU 是可压缩资源，超卖在物理上无害，限了反而把突发流量变成 429；
• 内存是不可压缩资源，不设 limits 时节点 OOM 的受害者往往是无辜的相邻 Pod；
• 设 limits 的 CPU 会引入 CFS quota 带来的调度延迟抖动，对延迟敏感的服务尤其明显（我在一个时序采集服务上实测过，CPU limit 设为 2 核后 P99 从 8ms 抖到 25ms，放开后恢复）。 但这也意味着调度装箱率会偏高，节点数要多买 10%–20%，这笔账要算清楚。

【想听大家怎么选】 想请教各位在以下场景下的取舍：

• 延迟敏感的在线服务（P99 有 SLA）：CPU 到底设不设 limits？
• 批处理 / 离线任务：会不会直接放开，甚至给到整节点？
• 多租户共享集群：你们是靠 limits 兜底，还是靠 Namespace ResourceQuota？
• 有没有人用过 LimitRange 做团队级默认值 + 单服务覆盖的模式？效果如何？
• 嵌入式/边缘场景（资源极小，几百 MB 内存）：你们的 requests/limits 怎么定？

欢迎贴你的配置片段、监控截图或者踩坑记录，越具体越好。我会先把自己那套 CPU/内存分治的完整 YAML 和压测数据整理成文章发出来，供对照。