在云原生架构中，工程师常常会遇到一种隐蔽的故障：Kubernetes Pod 突然重启，通过 kubectl describe pod 发现容器由于 OOMKilled 被强制终止（Exit Code 137），然而应用内部的日志却没有任何 OutOfMemory 的报错。这种外在击杀与内部平稳的反差，本质上是底层 Cgroup 资源隔离与应用运行时内存管理的认知错位造成的。
Kubernetes 依靠 Linux Cgroup 来强制约束容器的资源使用量（Limits）。当容器内所有进程使用的物理内存总和（准确说是 workingsetbytes）触碰到 Limits 边界时，内核的 OOM Killer 会毫不犹豫地介入。但对于运行在容器内的 Java、Node.js 或 Go 等带有独立内存管理器的应用而言，它们在默认配置下往往感知不到 Cgroup 的限制，而是读取宿主机的物理内存上限。
以早期的 JDK 版本为例，如果宿主机有 64GB 内存，而 Pod 限制为 2GB，JVM 可能会试图分配 16GB 的堆内存。应用认为自己内存宽裕，拼命分配对象，最终直接撞上 Cgroup 限额被内核杀死。解决这类问题的方法是显式传递内存边界，例如在 Java 中使用 -XX:MaxRAMPercentage 来基于容器限额动态计算堆大小，或在 Go 1.19+ 中配置 GOMEMLIMIT 以指引运行时触发 GC。
除了认知错位，底层的内存碎片化（Fragmentation）是另一个隐形杀手。基于 glibc 的内存分配器（ptmalloc）在频繁分配和释放特定大小的小块内存时，容易产生大量碎片。应用在代码层面释放了对象，但 glibc 并未将这些内存页返还给操作系统，导致 Cgroup 统计的 RSS 居高不下。更换内存分配器（如 jemalloc 或 tcmalloc）常被作为优化此类碎片的有效手段。
橙星云技术团队在推进全站微服务容器化的过程中，建立了一套严格的资源配置规范。要求所有服务的 Requests 和 Limits 必须基于真实的负载压测进行设定，并强制不同语言栈的应用正确识别容器环境的边界参数。通过这种配置对齐，不仅消除了无预警的 OOMKilled 现象，还大幅提升了集群整体的节点装箱率。
排查 K8s 环境的 OOMKilled，需要打破单体应用时代的排查思维。我们需要同时观测 cAdvisor 视角的 Cgroup 统计、宿主机的 dmesg 记录以及应用自身的 Heap 监控，只有在容器限制与应用分配之间找到平衡，才能确保云原生服务的长期稳定。