K8S Base: CrashLoopBackOff

一、CrashLoopBackOff 是什么？

CrashLoopBackOff 是 Kubernetes 为防止容器频繁崩溃而设计的一种保护性机制。

当容器启动后迅速退出（无论是异常退出还是探针失败被重启），Kubernetes 会尝试重新启动它。如果连续失败，系统会指数级延长重启等待时间（10秒、20秒、40秒、80秒...），这就是"BackOff"。

此时：

Pod 状态可能仍显示为 Running
但容器实际处于不断重启中
kubectl get pod 的 RESTARTS 列会持续增加

二、第一步：快速定位问题

排查 CrashLoopBackOff 的第一步，是获取最直接的错误线索：

bash 复制代码

# 查看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：

yaml 复制代码

initContainers:
  - name: wait-for-db
    image: busybox
    command: ['sh', '-c', 'until nc -z db 3306; do echo waiting for db; sleep 3; done']

三、排查思维模型总结：从"症状"到"根因"

CrashLoopBackOff 只是症状，根因往往隐藏在更深层。

|------|-------------|---------------------------------|
| 层级 | 典型问题 | 排查关键点 |
| 镜像层 | 命令错误 / 构建问题 | 本地验证镜像启动命令 |
| 运行时层 | 资源不足 / 存储失败 | 查看 Events 与 kubectl top pod |
| 应用层 | 异常或依赖未就绪 | 日志分析 + 网络连通性验证 |
| 探针层 | 误判 / 配置不当 | 调整 startupProbe / livenessProbe |

排查时遵循五步闭环：

现象 → 日志 → 层级 → 根因 → 优化