K8S Base: CrashLoopBackOff
一、CrashLoopBackOff 是什么？
CrashLoopBackOff 是 Kubernetes 为防止容器频繁崩溃而设计的一种保护性机制。
当容器启动后迅速退出（无论是异常退出还是探针失败被重启），Kubernetes 会尝试重新启动它。如果连续失败，系统会指数级延长重启等待时间（10秒、20秒、40秒、80秒...），这就是“BackOff”。
此时：
-
Pod 状态可能仍显示为
Running -
但容器实际处于不断重启中
-
kubectl get pod的 RESTARTS 列会持续增加
二、第一步：快速定位问题
排查 CrashLoopBackOff 的第一步，是获取最直接的错误线索：
# 查看Pod事件与状态
kubectl describe pod <pod-name> -n <namespace># 查看容器当前日志
kubectl logs <pod-name> -n <namespace># 查看上一次崩溃的日志
kubectl logs <pod-name> -n <namespace> --previous# 查看资源使用情况（是否OOMKilled）
kubectl top pod <pod-name> -n <namespace># 进入容器内部进行手动排查
kubectl exec -it <pod-name> -n <namespace> -- sh关键命令是 describe 和 logs --previous。当日志清晰显示错误原因（例如连接失败或命令错误）时，可直接进行修复。若日志信息模糊或为空，则需要进入系统性排查阶段。
在需要等待依赖服务的情况下，可添加 Init Container：
initContainers:- name: wait-for-dbimage: busyboxcommand: ['sh', '-c', 'until nc -z db 3306; do echo waiting for db; sleep 3; done']
三、排查思维模型总结：从“症状”到“根因”
CrashLoopBackOff 只是症状，根因往往隐藏在更深层。
| 层级 | 典型问题 | 排查关键点 |
| 镜像层 | 命令错误 / 构建问题 | 本地验证镜像启动命令 |
| 运行时层 | 资源不足 / 存储失败 | 查看 Events 与 kubectl top pod |
| 应用层 | 异常或依赖未就绪 | 日志分析 + 网络连通性验证 |
| 探针层 | 误判 / 配置不当 | 调整 startupProbe / livenessProbe |
排查时遵循五步闭环：
现象 → 日志 → 层级 → 根因 → 优化