K8s 容器 OOM Killer 触发排查手册 + 一键诊断脚本（Bash，覆盖 5 个典型场景）

背景

我做了 8 年运维，OOM Killer 是生产 Linux 服务器上最让人头疼的高频告警之一。目前团队排查方式基本是 dmesg | grep -i oom + journalctl -k 人肉翻日志，效率低、容易漏根因，新人上手慢。我想把这套排查流程沉淀成一份可复用的手册 + 一个一键诊断脚本，让任何运维同学拿到手就能 5 分钟内定位 OOM 根因。

最终要什么

1. OOM 排查手册（Markdown，≥1500 字）：覆盖「现象确认 → 事件定位 → 根因分析 → 修复验证」完整链路，含内核参数调优建议。
2. 一键诊断脚本（Bash，≥200 行）：自动采集 OOM 相关日志、cgroup 内存状态、进程内存排行、swap 使用、slab 统计等，输出一份结构化诊断报告（文本或 JSON）。
3. 5 个典型场景的排查路径，每个场景配可复现命令与预期输出样例。

输入与上下文

• 目标系统：CentOS 7/8、Ubuntu 20.04/22.04（脚本需兼容至少这两个发行版）
• 权限：root 或具有 dmesg / journalctl / cat /proc/*/smaps 读权限
• 场景假设：物理机 + K8s 容器环境都要覆盖（cgroup v1 和 v2 都要兼容）

5 个典型场景（手册必须覆盖）

| # | 场景 | 关键线索 | |---|------|---------| | 1 | Java 进程堆外内存（DirectByteBuffer / Metaspace）泄漏 | smaps 中 reserved 远大于 RSS，jcmd 输出 | | 2 | K8s 容器 cgroup 内存超限被 kill | cgroup 的 memory.max / memory.events（v2）或 memory.limit_in_bytes（v1） | | 3 | page cache 挤压导致可用内存不足 | MemAvailable 与 MemFree 差异大，/proc/meminfo 中 SReclaimable 高 | | 4 | 内核 slab 泄漏（如 dentry / inode 缓存膨胀） | slabtop 中某 cache 对象数异常增长 | | 5 | 内存碎片化导致大页分配失败 | buddyinfo 高阶空闲块为 0，/proc/vmstat 中 compact_stall 高 |

交付格式

• 一个目录，包含：
  • README.md：使用说明、环境要求、运行方式
  • oom-troubleshooting.md：排查手册（≥1500 字，含 5 个场景）
  • oom-diagnose.sh：一键诊断脚本（Bash，≥200 行，#!/usr/bin/env bash，set -euo pipefail）
  • samples/：每个场景的预期输出样例文件
• 全部以附件交付，或贴出完整代码 + 手册正文

开放问题（欢迎接单者在交付中一并讨论）

• oom_score_adj 在容器场景下是否还有意义？K8s 的 oomScoreAdj 注解和内核 oom_score_adj 的优先级关系是什么？
• cgroup v2 的 memory.swap.max 和 v1 的 memory.memsw.limit_in_bytes 行为差异，对 OOM 触发时机有什么实际影响？
• 生产环境是否应该禁用 OOM Killer（vm.panic_on_oom=1）还是让它工作但做更好的资源隔离？