防止核心管理agent被oom killer终止的关键是设置合理的oom_score_adj值并绑定内存限制：为containerd设-999，为agent容器设-800，配硬性内存限制及earlyoom主动缓冲。
核心管理 Agent（如 node-exporter、otel-collector、log-forwarder 或自研运维代理）一旦被 OOM Killer 终止，会导致监控失联、日志断流、自动扩缩容失效等连锁故障。防止其被误杀的关键不是“关掉 OOM”，而是让内核明确知道：它比大多数业务容器更不可替代。
给 Containerd 守护进程本身设高保护等级
Containerd 是所有容器的运行时基座，若它被杀，整个节点容器将无法调度、启停或健康检查。必须优先保障其存活：
- 编辑 /etc/containerd/config.toml，在顶层添加 oom_score = -999
- 该值与 systemd、sshd 同级，确保内核在全局 OOM 中将其完全跳过
- 修改后执行 sudo systemctl restart containerd 生效
为管理 Agent 容器设置专属 OOMScoreAdjust
不能依赖默认值。需在启动时显式声明其生存优先级：
- 使用 ctr（Containerd 原生命令行）启动时，通过 --runtime-config '{"oom_score_adj": -800}' 指定
- 若用 Kubernetes 部署，需在 PodSpec.securityContext.oomScoreAdj 中设为 -800（注意：需 kubelet v1.22+ 且启用 SupportPodPidsLimit 特性门）
- 避免设为 -1000：虽可豁免，但会剥夺内核最后兜底能力；-800 已足够高，同时保留极端情况下的系统可控性
绑定内存限制，让 oom_score_adj 发挥作用
OOM 评分只在 cgroup 内存超限时触发。不设限，再低的分数也无效：
- 为每个管理 Agent 容器配置硬性 --memory=128m（如 node-exporter）或 --memory=512m（如 otel-collector）
- 搭配 --memory-reservation=64m，避免因瞬时抖动被误判
- 禁止使用 --oom-kill-disable：它绕过整个机制，反而让失控进程拖垮宿主机
配合 earlyoom 实现主动缓冲
原生 OOM Killer 是“临界点爆发”，earlyoom 可提前干预：
- 安装 earlyoom，并配置 -m 10（当可用内存 ≤10% 时触发）
- 在 earlyoom 的 --avoid 参数中加入管理 Agent 的进程名（如 node_exporter,otelcol）
- 这样它会在真正 OOM 前先清理低优先级批处理任务，为 Agent 争取数秒至数十秒缓冲时间
