技术 · 实用指南
容器以 137 退出或显示“OOMKilled”？先证明 SIGKILL 边界，再增加内存
137 说明进程收到了 SIGKILL，却没有说明是谁发出的。先在同一事故时间窗中关联运行时、cgroup、节点与编排器证据，再调整限制。
容器退出码是线索，不是根因。137 通常对应 SIGKILL，但进程无法报告发送者；只有与同一次容器尝试和时间窗绑定的 OOMKilled 才是较强证据。
调整内存前建立带时间戳的证据账本，比较运行时终止记录、cgroup 计数器、节点内核证据和编排器事件。各层一致或矛盾被明确保留时才接受诊断。
1. 固定一次事故时间窗
记录准确的容器尝试、节点、开始与退出时间、退出码、信号、运行时原因及最后动作；重启会覆盖状态。
统一时区并保留原始输出，不要把当前计数器与旧内核消息或另一副本混用。
2. 把 137 当作 SIGKILL 证据
列出可能发送者：内核 OOM、操作员或自动化、运行时超时、编排器宽限期升级或其他特权进程。
若显示 OOMKilled，确认属于同一次尝试；若为 false 或缺失，只把 OOM 保留为假设。
3. 定位内存边界
识别实际 cgroup 和限制，记录 memory.max、用量与 memory.events，并比较叶级及相关祖先的计数增量。
叶级 oom_kill 增加支持该边界内终止；节点 OOM 支持更广边界；没有匹配增量就继续检验。
4. 关联节点与编排器证据
读取相同秒级时间窗的节点日志和事件，检查内存压力、驱逐、删除、探针失败、发布、排空或宽限期到期。
缺失证据要明确记为缺失；受限日志和轮换事件降低置信度，不能把假设变成事实。
5. 修复已证明的边界
容器 OOM 要先测工作集、分配尖峰和并发；节点压力、停止升级或外部终止则分别修复容量、关机处理或发送者。
受控复现后，以四层账本无匹配 oom_kill、无节点 OOM、无未知升级且运行时记录符合预期为验收条件。
