一行超长日志引发的 “血案” - Containerd 频繁 OOM 背后的真相

案发现场：混沌初现

2024年6月10日，本应是平静的一天。但从上午 9 点开始，Sealos 公有云的运维监控告警就开始不停地响。北京可用区服务器节点突然出现大量 “not ready” 告警，紧接着，系统自动触发 004 节点重启，让服务暂时恢复了正常。

就在我以为这只是个小插曲的时候，7分钟后，广州可用区服务器也沦陷了！001 节点不得不重启以求自保。事情似乎并没有那么简单。

“发生什么事了?!” 运维同学们迅速登录服务器排查。原本稳定运行在 30%左右的内存使用率，在几分钟内飙升到 100%。“看起来像是有新应用大量占用内存？”

问题排查：真相难明

“难道是底层机器的内存不足以支撑业务的增长？” 抱着姑且一试的态度，我们紧急升级了北京可用区服务器的配置，将内存容量直接翻倍。观察一段时间后，服务基本恢复稳定。“看来还是资源预留不足，3 倍底线仍然扛不住啊。” 大家暂时松了口气。

广州可用区的扩容也在40分钟后完成。

正当大家松了一口气，准备撤离 “战场” 时，北京可用区又开始卷土重来：16:22，接连不断的 not ready 告警又回来了！003 和 004 节点在资源耗尽的边缘反复横跳。人工重启维持一会儿还好，可 10 几分钟后，崩溃又卷土重来，内存曲线坚定地向右上方奔去...

更让人无语的是，计划赶不上变化，17:46，广州可用区也开始出问题，两个集群再次陷入节点轮番崩溃的怪圈。

揭示真相：内存炸弹，原来是你！

局势愈发紧张，我们只能通过不断重启节点，维持业务的运转。但内存增长的势头依然强劲，系统每隔 15-30分钟就会崩溃。

内存泄露？

面对诡异的内存曲线，有人提出会不会是内存泄露？大家决定从系统内核和容器两个方向深挖。

首先怀疑是不是有容器在疯狂打印日志。统计对比发现整体集群的 Pod 数量上升并不异常，排除了 Pod 数量暴增导致的资源问题。但在统计各节点内存使用时，发现所有 Pod 的实际内存使用总和，远小于宿主机的内存占用。

进一步确认是 Containerd 进程的内存占用在飙升，最高达到了恐怖的 1G/s 速率！而与此同时，Pod 本身的资源使用一直很平稳。

定位罪魁祸首

进一步怀疑可能是 Containerd 的 Bug 导致内存泄露。我们决定先将整个集群的 Containerd 升级到最新的 1.7.18 版本再继续观察。升级命令如下：

#!/usr/bin/env bashset -euxo pipefail
wget https://github.com/containerd/containerd/releases/download/v1.7.18/containerd-1.7.18-linux-amd64.tar.gz
tar xfz containerd-1.7.18-linux-amd64.tar.gz -C /usr
systemctl restart containerd && sleep 3
systemctl is-active