【背景】 我干了三年嵌入式，对「资源边界」这件事天然敏感——RAM 就那么多，越界就是 HardFault。转做容器化运维后，发现 K8s 里资源边界这件事，团队间的做法分歧极大，而且没有人能给出一个「标准答案」。
具体场景：一个 12 节点、每节点 16C64G 的自建 K8s 集群（containerd 1.7，内核 5.15，cgroup v2），跑着 20+ 个 Java/Go 服务 + 若干批处理 Job。节点上同时跑着 node-exporter、kubelet、containerd 这些「系统开销」。
【常见分歧，你们团队站在哪边？】
派 A：只设 requests，不设 limits
- 理由：让容器弹性使用节点剩余内存，避免「我申请了 4G 但实际只用了 1G，另外 3G 白白浪费」；
- 风险：某个容器突然吃满节点内存 → OOMKilled → kubelet 可能把别的容器也杀掉（cgroup OOM killer 不挑人）。
- 适用场景：低 QPS 的后台服务、开发/测试环境。
派 B：requests = limits（Guaranteed QoS）
- 理由：可预测性最高，每个容器的内存上限就是它的 requests，节点调度器保证「分配了就给你」；
- 风险：Java 服务 GC 时的瞬时峰值（-Xmx + Metaspace + Thread stacks + Direct Memory）经常超过你设的 limit，OOMKilled 来得很突然；
- 适用场景：核心在线服务、对 P99 敏感的业务。
派 C：requests 保守，limits = 2× requests
- 理由：给 burst 留空间，同时不让容器无限膨胀；
- 风险：Burstable QoS，节点内存紧张时这类容器最先被 OOM；limits 设 2× 意味着最坏情况一个容器可以吃掉 2× 的配额，节点规划要留余量。
【我的倾向与理由】
默认选 派 B（requests = limits），理由有三：
-
可预测性 > 弹性。在 12 节点、64G/节点 的规模下，我宁可每个容器「少用一点」也不想看到 OOMKilled 日志里出现「killed by kernel oom」——因为这种事故排查起来，你需要回溯 cgroup 的 memory.events、节点上的 dmesg、以及 kubelet 的 evict 日志，链路很长。
-
Java 服务的内存模型要算清楚。一个 4C8G 的 Java 容器，实际内存占用 ≈ -Xmx + Metaspace（512M）+ Thread stacks（每线程 ~1M × 线程数）+ Direct Memory（Netty/Netty 场景可达 1G+）+ JVM 自身开销（~200M）。如果你的 -Xmx 设成 limit 的 75%，还要把 Metaspace 和 Direct Memory 算进去——我见过太多团队只设了 -Xmx 就完事，结果 OOMKilled 的时候 dmesg 里是 kernel oom，不是 JVM OOM。
-
Guaranteed QoS 在节点资源紧张时的存活率最高。kubelet 的 eviction 顺序：BestEffort → Burstable → Guaranteed。如果你的核心服务是 Burstable（只设了 requests），节点内存压力上来时它比 Guaranteed 的容器先被杀。
但有一个例外：如果是「突发型」负载（比如一个每天跑一次的 ETL Job，跑的时候内存飙到 30G，跑完就释放），我会用 limits = 32G + requests = 4G，并且把它调度到专用节点（nodeAffinity + taint），避免影响在线服务。
【想听大家在什么场景下怎么选】
- 你们的 Java 服务 -Xmx 是怎么跟 container memory limit 挂钩的？是 limit × 0.75？还是 limit × 0.7？有没有把 Metaspace / Direct Memory 单独算进去的？
- 你们有没有遇到过「limits 设了但容器还是被 OOMKilled」的情况？dmesg 里是 kernel oom 还是 JVM OOM？
- 批处理 Job 和在线服务混跑，你们怎么隔离资源？nodeAffinity + taint？还是直接分两个 namespace + ResourceQuota？
- 有没有人试过「不设 limits，靠 LimitRange 兜底」的方案？线上效果怎么样？
我倾向于把讨论聚焦在「具体数字」上：你们线上的 limit 到底设的多少 G、-Xmx 设的多少、节点规格多少——有数字的讨论比「我觉得应该设紧一点」有建设性。