CrashLoopBackOff 是什么
CrashLoopBackOff 不是一种故障原因，而是实例反复崩溃后集群采取的退避重试状态：进程退出、容器被重建、再次退出，每次重试间隔成倍拉长。它的现场有两份，一份是集群记录的状态与事件，一份是已经终止的那个实例留下的输出，两份都要看。
基本信息
| 崩溃现场 | 读上一个已终止实例的输出，当前实例往往刚启动没有内容 |
|---|---|
| 状态查询 | 读取实例状态里的终止原因与退出码，区分是被杀还是自退 |
| 退避规律 | 间隔按指数增长，从几秒逐步拉长到几分钟 |
| 常见原因 | 配置缺失、环境变量错误、依赖连不上、内存不足、启动命令写错 |
| 探针因素 | 存活探针失败也会触发重启，事件里会留下痕迹 |
| 验证方式 | 用临时容器或进入实例手动执行启动命令复现 |
典型排查动作
- 先读上一实例日志，拿到进程退出前的最后输出
- 再看退出码与终止原因，区分异常退出还是被外部终止
- 核对配置与密钥是否挂载成功，缺失时应用通常在启动阶段就报错
- 核对依赖服务是否可达，数据库与缓存连接串写错是高频原因
- 核对存活探针参数，启动慢的应用被误判为卡死会反复重启
- 手动执行启动命令复现，把环境差异与代码问题分开
退出码与线索对照
| 信号 | 含义 | 排查方向 |
|---|---|---|
| 退出码 1 | 应用自身报错退出 | 看日志里的异常堆栈与配置项 |
| 退出码 127 | 命令不存在 | 启动命令或工作目录写错 |
| 退出码 137 | 被强制终止 | 内存超限或健康检查失败被杀 |
| 退出码 143 | 收到终止信号 | 优雅退出流程或人为重启 |
| 探针失败事件 | 存活检查不通过 | 调整探针参数或修复依赖 |
| 挂载失败事件 | 配置或密钥未就绪 | 核对挂载名称与命名空间 |
排查命令
排查命令
kubectl logs web-1 --previous --tail=200 # 崩溃现场
kubectl describe pod web-1 | grep -A5 -i "back-off" # 事件与退避信息
kubectl get pod web-1 -o jsonpath='{.status.containerStatuses[0].lastState}' # 终止原因与退出码
kubectl exec -it web-1 -- sh # 手动复现启动流程
# 修完配置别干等退避：删除实例让控制器立刻重建退避间隔会指数增长：修复后不必等下一次重试窗口，直接让控制器重建新实例，验证速度会快很多。
存活探针探到依赖是常见误配：数据库或缓存抖动会触发全量重启，存活探针只应判断进程自身是否还在工作。
不要靠反复重启赌运气：同一份配置不修改，重启多少次结果都一样，先拿到上一实例的日志再动手。
配置与密钥缺失会让应用在启动阶段直接退出，这类问题的表现是日志很短且集中在启动流程，与依赖超时的长日志有明显区别。
修复后的验证动作
- 修复后主动重建实例，不必等待退避窗口结束
- 验证阶段持续观察重启次数是否停止增长
- 确认就绪状态恢复正常，而不是仅仅处于运行中
- 把根因与修复动作记录下来，同类问题可以快速复用
- 如果与探针配置有关，调整后要用真实流量再验证一遍
- 上线后设置重启次数告警，避免同类问题静默复发