Kubernetes Pod 排障实战：CrashLoopBackOff、OOMKilled 与高频异常的定位路径

Kubernetes Pod 排障是每个容器工程师绕不开的日常。很多初学者看到 Pod 状态异常就重启大法伺候，结果问题反复出现。本文结合生产环境真实案例，梳理 CrashLoopBackOff、OOMKilled、Pending、ImagePullBackOff 四类高频异常的定位路径与排查命令，帮助你在集群里快速止血。

一、CrashLoopBackOff：容器反复崩溃

CrashLoopBackOff 表示容器启动后反复退出，kubelet 按指数退避策略（10 秒、20 秒、40 秒……最长 5 分钟）不断重启。第一步永远是看退出码：kubectl describe pod 查看 Last State 中的 Exit Code。

Exit Code 1：应用主动退出，多半是启动时抛异常，用 kubectl logs --previous 看崩溃前的日志；Exit Code 137：容器被 SIGKILL，可能是 OOMKilled 或 livenessProbe 失败被杀，需结合事件区分；Exit Code 139：段错误，通常是二进制与基础镜像 CPU 架构不匹配，例如 x86 镜像被调度到了 ARM 节点。

生产案例：某服务每次发布后必然 CrashLoopBackOff，日志显示读不到配置文件。根因是 ConfigMap 名称拼写错误，Volume 挂载失败后目录为空，应用启动即退出。describe 事件里的 MountVolume.SetUp failed 是关键线索——这类资源引用错误靠重启永远解决不了。

二、OOMKilled：内存超限

容器内存超过 limits 后被内核 cgroup OOM 杀掉，退出码 137 且 Reason 为 OOMKilled。排查三板斧：kubectl top pod 看实际用量，describe 看 limits 配置，再看应用是否存在内存泄漏。

两个容易踩的坑：一是 JVM 应用在容器里如果不配 -XX:MaxRAMPercentage 或 UseContainerSupport，会按宿主机内存估算堆大小，一启动就 OOM；二是计算型任务的内存峰值是瞬时的，压测时用的是均值流量，上线后高峰期超限。内存 limits 的设定原则是"压测峰值的 1.3 到 1.5 倍"，而不是拍脑袋给个整数。

三、Pending：调度失败

Pod 长期 Pending 说明调度器找不到可用节点。kubectl describe pod 的事件段会给出明确原因：Insufficient cpu / memory 是资源不足；node(s) had untolerated taint 是节点污点没容忍；node(s) didn't match Pod's node affinity 是亲和性规则把所有节点排除了。

一个隐蔽案例：某业务设置 nodeSelector 指向一个已下线的节点组标签，扩容后新节点没有该标签，所有 Pod 全部 Pending。调度问题的排查本质是"把调度器拒绝你的理由读出来"，事件信息里写得清清楚楚，不要凭感觉改 YAML。

四、ImagePullBackOff：镜像拉取失败

常见原因按概率排序：镜像 tag 不存在或拼写错误；私有仓库未配 imagePullSecrets；仓库限流（Docker Hub 匿名拉取 6 小时只有 100 次）；集群节点无法访问外网仓库。可以用 crictl pull 在节点上直接验证，绕开 apiserver 层面的干扰。

生产建议：核心业务镜像一律内网自建 Harbor，配镜像预拉取 DaemonSet 或快照预热；CI 流水线里加 tag 存在性校验，避免"拼错一个字符，回滚半小时"。

五、通用排查框架

遇到任何 Pod 异常，按这个顺序走：kubectl get pod 确认状态 → describe 看事件与退出码 → logs（含 --previous）看应用日志 → exec 进容器验证运行时环境 → kubectl get events --sort-by=.lastTimestamp 看全局事件流。90% 的问题在前三步就能定位。

容器排障的核心心法：Kubernetes 的所有异常都会在 Events 里留下线索，"重启"只是清除表象。把每一次 CrashLoopBackOff 当作一次根因分析练习，而不是一次故障重启，你的集群稳定率会实打实地提升。