我们在一家跨境电商公司维护一批部署于香港的边缘服务器，这些服务器主要用于提供海外用户访问的低延迟服务。为提升资源利用率和服务灵活性，运维团队采用了 Kubernetes + Docker 的容器化部署方式。
近期，在对外高并发服务的几台香港节点上，频繁出现业务 Pod 被系统 OOM Killer 杀死的情况，严重影响了服务可用性与稳定性。本文将详细记录这次故障的排查过程、发现的问题、以及最终的优化方案，旨在为读者提供具有实操性的容器内存调度优化参考。
在数台部署于香港的数据中心的物理服务器中，我们观察到以下异常：
- 多个业务容器（如 nginx、node、redis）突然退出；
- kubectl describe pod 显示容器被 OOM（Out of Memory）终止；
- 系统日志（dmesg）频繁记录 OOM Killer 杀死进程的信息；
- 业务请求响应时间间歇性升高，出现服务不可用告警。
典型日志如下：
[ 25699.474839] Out of memory: Killed process 13452 (node) total-vm:512000kB, anon-rss:451000kB, file-rss:1048kB, shmem-rss:0kB
[ 25699.475102] oom_reaper: reaped process 13452 (node), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB
初步排查：确认资源配置
首先检查 Pod 的资源请求与限制：
resources:
requests:
memory: "256Mi"
cpu: "250m"
limits:
memory: "512Mi"
cpu: "500m"
发现：
- 容器请求的内存偏低（仅 256Mi），上限也仅为 512Mi；
- 业务模块（node 应用）在高并发情况下内存增长迅速；
- 物理机内核版本为 5.4，使用的是 cgroup v1 管理资源。
执行 top 和 free -m 检查宿主机内存状况时，发现：
- 总内存使用率高达 95%；
- 即便 swap 开启，系统仍频繁触发 OOM Killer。
进一步分析 vm.overcommit_memory 参数，发现设置为默认的 0（即 Heuristic 模式），系统可能在分配内存时被过度乐观。
深入分析：调度机制与容器管理失衡
在K8s中，cgroup 限制的是容器的物理内存使用上限。然而，当多个容器运行在资源受限的物理机上时，容易出现“局部水位低、全局水位高”的不平衡现象。
通过 cat /sys/fs/cgroup/memory/memory.stat 查看各容器内存占用情况，发现某些业务容器常驻 RSS 超过 500Mi，逼近其限制。而 Node.js 应用存在 V8 垃圾回收滞后问题，导致其在短时间内内存突增，被系统 OOM Kill。
同时检查 kubelet 配置，发现未开启 –eviction-hard 和 –system-reserved 参数，导致 kubelet 没有预留足够的系统资源，OOM 风险被系统层级接管，而不是 Kubernetes 管理。
优化方案设计
1. 调整容器资源请求与限制
根据实际运行内存数据，结合业务峰值表现，将容器资源策略调整为：
resources:
requests:
memory: "512Mi"
cpu: "500m"
limits:
memory: "1024Mi"
cpu: "1000m"
同时通过 Prometheus + Grafana 监控容器内存使用率曲线，动态调整资源配置。
2. 启用内存驱逐机制
修改 kubelet 启动参数：
--eviction-hard=memory.available<500Mi
--system-reserved=memory=512Mi
目的：
- 提前触发 Pod 驱逐，避免系统级 OOM；
- 预留系统内核、守护进程必要内存空间。
3. 启用 cgroup v2 统一资源管理
升级内核至 5.10，并配置系统使用 cgroup v2，提升内存调度精度与稳定性：
GRUB_CMDLINE_LINUX="systemd.unified_cgroup_hierarchy=1"
统一 cgroup 有更好的资源隔离能力，且支持 memory.min 等软限制配置，防止系统不公平地回收内存。
4. 优化 Node.js 应用内存回收
通过启动参数限制 Node.js 最大可用内存：
node --max-old-space-size=768 app.js
并引入 heapdump 工具，观察 GC 前后堆内存情况，进一步精细化分析内存泄露风险。
5. 物理机内存与 swap 策略优化
关闭 swap，防止内核交换频繁影响性能：
swapoff -a
设置合理的内存过载控制：
sysctl -w vm.overcommit_memory=2
sysctl -w vm.overcommit_ratio=80
这个设置要求内存分配必须预留 backing store，系统更保守，OOM 几率降低。
提升效果验证
优化完成后，重新部署 Pod，并持续监控一周：
- OOM Kill 事件数量从每日 10+ 次降为 0；
- 宿主机内存使用率维持在 75% 以下；
- GC 执行更加平稳，业务延迟降低 20%；
- Prometheus 报警频率显著下降，系统运行稳定。
在容器化部署环境中，资源限制和调度机制设计直接影响系统的稳定性。OOM Killer 是 Linux 内核的最后防线，但应尽量由 Kubernetes 主动管控资源回收。
本次故障排查中，我们总结出以下建议：
- 根据实际业务负载设定合理的 requests 和 limits；
- 启用 kubelet 内存驱逐机制，防止宿主机资源透支；
- 使用 cgroup v2 提升资源管理精度；
- 优化应用层内存使用模式，防止短时间爆发；
- 加强监控体系，提前识别内存异常行为。
通过这些手段，可以显著降低容器内存管理风险，提升整体系统稳定性与可观测性。希望本文的实录过程对正在容器化环境中遇到内存调度问题的工程师提供有益参考。
