Pod 进入 CrashLoopBackOff，表示容器启动后反复退出，Kubelet 正在逐步延长重启间隔。它不是根因，而是结果。排查必须先确认退出原因，再判断是应用、配置、探针、资源还是节点问题。
一、保存现场
kubectl get pod -n <NS> -o wide
kubectl describe pod <POD> -n <NS>
kubectl logs <POD> -n <NS> --previous
kubectl get events -n <NS> --sort-by=.lastTimestamp | tail -50--previous 用于读取上一次已退出容器的日志，是定位重启最关键的命令之一。记录重启次数、节点、镜像版本、退出码和事件时间。
二、根据退出码分类
OOMKilled或 137：检查容器 limit、工作集、内存泄漏和节点压力；1 或其他应用错误码：查看启动日志、配置、依赖和参数；
143：通常收到 SIGTERM，检查发布、缩容或探针；
Completed 后仍重启：确认 Deployment 中是否错误运行一次性任务。
kubectl get pod <POD> -n <NS> -o jsonpath='{.status.containerStatuses[*].lastState}'三、检查配置与依赖
确认 ConfigMap、Secret、挂载路径、环境变量、Service DNS、数据库和消息队列是否可用。配置更新不一定会自动重启 Pod，也要确认应用读取的是新配置。
kubectl exec -n <NS> <POD> -- env
kubectl get configmap,secret -n <NS>
kubectl get endpoints -n <NS>四、检查探针
启动时间较长却配置过短的 livenessProbe，会让容器在完成初始化前被杀死。优先使用 startupProbe 保护慢启动，再合理配置 readinessProbe 和 livenessProbe。探针应检查必要能力，避免执行昂贵查询。
五、检查资源与节点
kubectl top pod <POD> -n <NS> --containers
kubectl describe node <NODE>检查 request/limit、CPU throttling、内存压力、磁盘压力和临时存储。只有单个节点上的 Pod 异常时，应重点检查节点网络、存储和运行时。
六、紧急止血与治理
可回滚镜像、恢复配置、临时扩容资源、关闭错误探针或把流量切到健康版本。长期应建立退出原因、重启次数、OOM、探针失败和发布版本关联告警，并在发布前验证启动、终止和依赖异常场景。
总结
CrashLoopBackOff 的正确路径是：事件确定阶段，--previous 获取证据，退出码缩小范围，再检查配置、探针、资源和节点。不要用反复删除 Pod 代替根因分析。