pod出现crashloopbackoff说明容器启动后迅速退出，需通过kubectl describe查看events和exit code（如137=oomkilled）、kubectl logs --previous获取前次崩溃日志、kubectl top比对资源限制与实际使用、检查livenessprobe配置是否匹配应用启动耗时、验证configmap/secret挂载及依赖服务连通性。
Pod 出现 CrashLoopBackOff，说明容器启动后很快退出（非零退出码），Kubernetes 不断尝试重启并拉长间隔。关键不是“怎么等它好”，而是快速定位“它为什么一启动就挂”。下面几步直击核心，不绕弯。
先看退出码和事件日志
执行 kubectl describe pod <pod-name> -n <namespace></namespace></pod-name>，重点盯三处：
-
Events 区域：找 Warning 类事件，比如
OOMKilled（退出码 137）、ImagePullBackOff、FailedMount、CrashLoopBackOff自身的警告行 - Containers → Last State → Reason / Exit Code：退出码是关键线索——0 表示正常结束（但 restartPolicy=Always 会再启），1–126 多为应用错误，137=被 OOMKilled，143=被 SIGTERM 正常终止
- Conditions 和 Ready 字段：确认是否曾短暂进入 Running 状态，还是压根没起来
立刻查上一轮崩溃日志
当前容器可能还没来得及打日志就退出了，所以 kubectl logs <pod-name></pod-name> 常为空。必须加 --previous：
kubectl logs <pod-name> -n <namespace> --previous</namespace></pod-name>- 若 Pod 有多个容器，补上
-c <container-name></container-name> - 搜索关键词：
Exception、Connection refused、No such file、Permission denied、OutOfMemoryError
检查资源限制与实际消耗
内存超限是最隐蔽也最常见原因：
- 在
kubectl describe输出中看Resources Limits和Requests配置 - 运行
kubectl top pod <pod-name> -n <namespace></namespace></pod-name>查看实时内存/CPU 使用量，对比 limits 值 - 如果 Events 中有
OOMKilled，且kubectl top显示内存使用逼近或达到 limits，直接调高resources.limits.memory - Java/Node.js 等应用注意：JVM 堆外内存、Node 的 V8 内存限制也会计入容器总内存，不能只看应用内配置
验证探针与启动节奏是否匹配
存活探针（livenessProbe）不是保命符，配错反而会“亲手杀死”正在启动的应用：
- 用
kubectl get pod <pod-name> -o yaml</pod-name>或describe输出，找到livenessProbe配置 - 重点核对：
initialDelaySeconds是否大于应用真实冷启动耗时（Spring Boot 常需 45s+，慢查询服务可能超 2 分钟） - 检查
failureThreshold和timeoutSeconds：超时太短（如设成 1s）、阈值太低（如 failureThreshold=1），容易误判 - 临时禁用探针验证：
kubectl patch pod <pod-name> -p '{"spec":{"containers":[{"name":"<container-name>","livenessProbe":null}]}}'</container-name></pod-name>
别漏掉基础依赖和权限
很多崩溃发生在“还没走到业务代码”阶段：
-
ConfigMap/Secret 挂载：检查
kubectl get cm,secret -n <namespace></namespace>是否存在，describe输出中Volumes是否显示Mounted By成功 -
Init 容器失败：
describe中 Init Containers 状态是否为 Completed；若卡在 Waiting/ErrImagePull，主容器不会启动 -
网络与依赖服务：用
kubectl exec -it <pod-name> -- sh</pod-name>进入容器（若还能进），手动curl或telnet测试数据库、Redis、下游 API 地址和端口 -
命令与参数：确认 YAML 中
command和args是否指向可执行文件，路径是否存在，权限是否为可执行（尤其自定义脚本）
