遇到 Pod 状态显示 CrashLoopBackOff 时，最推荐的做法是立即查看容器日志和事件信息，这适用于绝大多数应用启动失败或运行中崩溃的场景。
先说结论：CrashLoopBackOff 意味着容器反复启动失败，核心在于找出退出码和报错信息。
- 先确认：使用 kubectl describe 查看事件和状态详情
- 先处理：通过 kubectl logs 获取应用日志，定位代码或配置错误
- 再验证：修复配置或代码后重新部署，观察状态是否转为 Running
命令速用版
以下是排查时最常用的几条命令，直接替换命名空间和 Pod 名称即可执行：
kubectl get pods -n <namespace>
kubectl describe pod <pod-name> -n <namespace>
kubectl logs <pod-name> -n <namespace>
kubectl logs <pod-name> -n <namespace> `--previous`
为什么会这样
CrashLoopBackOff 不是具体的错误原因，而是 Kubernetes 的一种保护机制。当容器进程退出（通常是非零退出码）后，K8s 会尝试重启它。如果重启再次失败，系统会逐渐延长重启间隔，避免无限快速重启消耗节点资源，此时状态就会变为 CrashLoopBackOff。
常见触发原因包括应用代码异常、缺少环境变量、配置文件错误、依赖服务未就绪或资源限制导致被杀死（OOMKilled）。
分步处理
1. 确认 Pod 所在命名空间，使用 get 命令列出异常 Pod 名称。
2. 执行 describe 命令，重点查看 Events 部分和 Last State 信息。如果看到 Reason 为 OOMKilled，说明内存不足；如果看到 Exit Code 为 1 或其他非零值，说明应用内部报错。
3. 使用 logs 命令查看当前日志。如果容器已经重启，当前日志可能是空的，需要加上`--previous` 参数查看上一次崩溃前的日志。
4. 根据日志报错修改 Deployment 配置或代码，例如修正环境变量、增加内存限制或修复代码逻辑。
怎么验证是否生效
重新应用配置后，再次运行 kubectl get pods 命令。观察 READY 列是否变为 1/1，STATUS 列是否稳定显示为 Running。如果状态在 Running 保持超过几分钟不再变化，说明问题已解决。
常见坑
1. 命名空间错误：默认查询的是 default 命名空间，实际 Pod 可能在其他空间。
2. 多容器 Pod：如果 Pod 中有多个容器，必须使用-c 参数指定容器名称，否则可能看不到报错容器的日志。
3. 日志丢失：如果容器启动瞬间就崩溃，可能没有日志输出，此时需依赖 describe 中的事件信息或检查镜像入口命令。
参考来源
- Kubernetes Documentation, Pod Lifecycle, https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/
- Kubernetes Documentation, kubectl logs, https://kubernetes.io/docs/reference/kubectl/generated/kubectl/kubectl_logs/
原文链接：https://www.zjcp.cc/ask/10287.html