华为云 CCE Pod 反复 CrashLoopBackOff：从事件到资源配置的逐项排查

Keywords: 华为云 CCE、Kubernetes、CrashLoopBackOff、容器排障、kubectl

凌晨两点，监控群里弹出一条告警：订单服务的 Pod 重启次数在十分钟内从 0 涨到了 17，状态在 Running 与 CrashLoopBackOff 之间反复横跳。应用没有发布新版本，节点也没有明显异常，问题出在哪里？在华为云 CCE 集群上运维业务的过程中，这类“容器反复重启”几乎是最常见的线上故障之一。本文记录一套可直接照做的排查流程：先用三条命令定性，再按根因清单逐项核对，最后给出修复验证与预防办法，帮你把平均定位时间控制在半小时以内。

一、先看现场：三条命令定性

遇到 Pod 反复重启，不要先猜原因，而是先把现场状态固定下来。以下三条命令能在两分钟内告诉你三件事：重启了多少次、最近一次为什么死、上一次的日志留下了什么。

# 1. 看重启次数与当前状态，重点关注 RESTARTS 列是否持续增长
kubectl get pods -n order-prod -w

# 2. 看 Pod 的事件和最近一次终止原因（Exit Code、OOMKilled、探针）
kubectl describe pod order-api-7d9f6b4c8d-x2k5p -n order-prod

# 3. 看上一次容器的日志：崩溃前的最后一行往往就是根因
kubectl logs order-api-7d9f6b4c8d-x2k5p -n order-prod --previous

如果 RESTARTS 列每隔几十秒就加 1，说明容器在反复启动后迅速退出，是典型的 CrashLoopBackOff；如果 RESTARTS 偶尔才涨一次，则更可能是节点驱逐、超售抢占或者应用自身偶发异常，排查方向完全不同。

经验：describe 输出中的 Last State 和 Events 是第一证据源。Last State 会直接告诉你上一次退出的原因和退出码；Events 会记录调度、拉取镜像、探针失败的时间线。先看这两段，再决定下一步。

二、根因速查表：先对号入座

对号入座之后，再按下面各节的方法逐项验证，不要一次改多个地方，否则无法确定到底是哪一处修好的。

三、启动日志：区分启动期崩溃与运行期崩溃

同样是退出码 1，崩溃发生的时机不同，原因完全不同。先用以下方法判断崩溃发生在启动期还是运行期：

# 对比当前容器日志与上一次容器日志
kubectl logs order-api-7d9f6b4c8d-x2k5p -n order-prod --previous --tail=50
kubectl logs order-api-7d9f6b4c8d-x2k5p -n order-prod --tail=50

如果上一次日志里出现“配置文件未找到”“连接数据库超时”“端口已被占用”等启动期错误，说明问题在环境或配置；如果日志显示应用已经正常启动、处理了几十秒请求后才退出，则要怀疑内存泄漏、连接池耗尽或者被探针误杀。实战中我们遇到过一个案例：应用日志没有任何异常，但容器每 90 秒重启一次，最后发现是存活探针的超时时间只有 1 秒，而应用在大促期间响应变慢，探针超时后 kubelet 判定容器不健康并将其杀死重启。

四、资源配置核查：内存与 CPU 是重灾区

OOMKilled 是 CrashLoopBackOff 最常见的直接原因。核查顺序是：先看 Pod 的资源配置，再看实际用量，最后看节点余量。

# 查看 Pod 的 requests / limits 配置
kubectl get pod order-api-7d9f6b4c8d-x2k5p -n order-prod -o yaml | grep -A 8 resources

# 查看容器实际用量（需要集群开启 metrics-server）
kubectl top pod -n order-prod
kubectl top node

需要注意三点。第一，Java 应用的堆内存（-Xmx）要小于容器的 limits.memory，留出约 20% 的余量给堆外内存、元空间和系统开销；我们曾经把 2Gi 容器的堆设到 2Gi，结果应用在流量高峰时反复被 OOMKilled，改成 -Xmx1536m 后恢复稳定。第二，CPU 的 requests 过低会导致 Pod 被调度到已经很忙的节点上，启动耗时被拉长，进而触发探针失败；第三，集群层面可以用 LimitRange 统一设定默认值，避免个别服务因为漏配 limits 而拿到不合理的配额。

resources:
  requests:
    cpu: "500m"
    memory: "1Gi"
  limits:
    cpu: "2"
    memory: "2Gi"

五、探针配置核查：让探针跟上应用的启动节奏

探针是 Kubernetes 判断容器健康状态的依据，但配得不合理时，探针本身会成为故障制造者。原则是：readiness 探针决定流量是否进入，liveness 探针决定容器是否重启；两个探针的职责不同，不能混用同一套参数。

livenessProbe:
  httpGet:
    path: /healthz
    port: 8080
  initialDelaySeconds: 30
  periodSeconds: 10
  timeoutSeconds: 5
  failureThreshold: 3
readinessProbe:
  httpGet:
    path: /ready
    port: 8080
  initialDelaySeconds: 15
  periodSeconds: 5
  failureThreshold: 3

initialDelaySeconds 的取值要覆盖应用从启动到能响应探针的全过程。以 Java 应用为例，冷启动可能需要 30 秒以上，如果 initialDelaySeconds 只给 10 秒，探针会在应用尚未就绪时就连续失败，failureThreshold 达到 3 次后 kubelet 就会重启容器，形成“启动—探针失败—被杀—再启动”的死循环。我们的做法是：在灰度环境里实测应用从进程启动到探针首次成功的时间，再留出 20% 余量作为 initialDelaySeconds；同时把启动探针（startupProbe）用在冷启动较长的服务上，让它先负责启动期的探测，等启动完成再交给 liveness 探针。

六、镜像与启动命令：别让低级错误消耗排查时间

镜像与启动命令的问题往往一眼就能看出来，但前提是先去看事件，而不是凭经验猜。核查清单如下：

1. 镜像地址是否正确，镜像仓库是否需要 imagePullSecrets；容器镜像服务 SWR 的凭证过期会导致拉取失败，表现为 ErrImagePull
2. 镜像拉取策略是否为 Always 配合了经常变动的 latest 标签，导致每次启动都重新拉取
3. command 与 args 是否与镜像的 Entrypoint 冲突，工作目录是否被错误覆盖
4. 启动命令依赖的文件或脚本是否在镜像内确实存在，且具有可执行权限

我们曾遇到过一个案例：Dockerfile 中把启动脚本放在了 /app/start.sh，但 Workload 中配置的 command 指向了 /start.sh，容器启动即报 127 退出。把 command 改为 /app/start.sh 后，重启次数立刻归零。

七、配置与密钥挂载：先确认它确实挂进来了

配置类问题在日志里往往只表现为一句含糊的“file not found”或“env not set”，排查时最省事的方法是进容器看一眼：

# 容器存活的短暂窗口期内执行一次检查（也可用临时调试容器）
kubectl exec -it order-api-7d9f6b4c8d-x2k5p -n order-prod -- ls -l /app/config
kubectl exec -it order-api-7d9f6b4c8d-x2k5p -n order-prod -- env | grep -i db_

如果 Pod 启动太快来不及 exec，可以临时把 command 改为 sleep 3600，让容器停下来再检查；确认后再把原配置改回来。这个方法在排查挂载问题时特别有效：我们曾据此发现某个命名空间下 ConfigMap 被误删重建后，键名发生了变化，导致应用读不到配置。

八、修复与验证：一次只改一处，观察重启次数归零

锁定根因后，按以下步骤修复并验证：

# 滚动更新，让新配置逐步替换旧 Pod
kubectl rollout restart deployment/order-api -n order-prod

# 持续观察：RESTARTS 不再增长，READY 保持 1/1
kubectl get pods -n order-prod -w

# 确认新 Pod 的事件里不再有失败探针或崩溃记录
kubectl get events -n order-prod --sort-by=.lastTimestamp | tail -20

验证的标准是：连续十五分钟内 RESTARTS 不再增长，且业务的成功率、延迟指标回到基线。如果重启次数停了但业务指标没恢复，说明问题还没有完全解决，要回头继续看日志和事件，而不是宣布修复完成。

九、预防清单：把排查经验沉淀成默认配置

• 为所有 Workload 设置合理的 requests 与 limits，Java 服务堆内存小于 limits.memory 的 80%
• 存活探针与就绪探针分开配置，initialDelaySeconds 按实测启动耗时加 20% 余量
• 镜像使用不可变版本号，避免 latest 标签在不同节点拉取到不同镜像
• 关键配置通过 ConfigMap 挂载，并给配置变更加上灰度验证流程
• 给 Pod 的重启次数配置告警：五分钟内重启超过 3 次即通知值班人员

十、总结

CCE Pod 反复 CrashLoopBackOff 的排查并不依赖高深的工具，关键是有一套固定的动作：先用三条命令看现场，再按速查表对号入座，然后一次只改一处、观察验证。把这套流程写成你团队的排障手册，再配合合理的资源与探针配置，大多数重启问题都能在半小时内定位。愿你的集群里，再也没有凌晨两点的重启告警。