Kubernetes CrashLoopBackOff：用退出原因定位容器反复重启

适用范围与前提

适用于 Deployment 管理的 Kubernetes Pod；StatefulSet 与 Job 的恢复决策不同。

先确认 kubectl 上下文、命名空间、Pod 与容器。日志及事件需要读取权限，发布操作需要单独写入权限。

常见症状

• Pod 状态为 CrashLoopBackOff
• 部署后副本无法 Ready
• 日志只显示最后一次启动片段

1. 读取上一轮容器日志与退出原因

优先使用 --previous 获取崩溃实例日志，并查看 describe 中的 Last State、Exit Code、OOMKilled 与事件。不要只看当前还未启动成功的日志流。

kubectl logs POD_NAME -n NAMESPACE -c CONTAINER_NAME --previous --tail=200
kubectl describe pod POD_NAME -n NAMESPACE

2. 按退出类型处理

OOMKilled 指向内存限制、突发峰值或泄漏；exit 1 多为配置、启动命令或依赖连接失败；探针失败则要比较应用真实启动时间与 initialDelaySeconds。修改探针不能修复应用崩溃本身。

kubectl get pod POD_NAME -n NAMESPACE -o yaml
kubectl top pod POD_NAME -n NAMESPACE --containers

3. 验证变更与回滚窗口

对配置、Secret、镜像 tag、启动参数逐项与上一稳定 ReplicaSet 对比。若恢复时间优先，先回滚并保留失败版本的镜像、事件和日志以便复盘。

kubectl rollout history deployment/DEPLOYMENT_NAME -n NAMESPACE
kubectl rollout undo deployment/DEPLOYMENT_NAME -n NAMESPACE

解读证据

说明性诊断案例

以下假设案例用于解释推理，并非客户真实事故，也不代表已在你的技术环境中测试。

容器初始化需要 70 秒，但存活探针在 30 秒附近反复终止它。上一轮日志显示启动仍在进行，事件指向探针失败。应测量启动时间并设置合理的启动探针预算；不要用放宽所有探针来掩盖应用主动退出。

验证恢复

• 确认目标副本全部 Ready，且多个探针周期内重启次数不再增加。
• 复测实际业务请求和依赖健康；Pod 变绿并不等于业务路径恢复。

回滚与停止条件

Deployment 回滚恢复旧 Pod 模板，不会撤销外部数据库变更或共享 ConfigMap/Secret 的修改。先确认兼容性，并在替换 Pod 前保留故障证据。