crashloopbackoff

Kubernetes Pod CrashLoopBackOff 的定位与修复

现象

kubectl get pod 显示 CrashLoopBackOff，容器启动后很快退出，重启间隔逐步拉长。常见原因是应用启动失败、配置缺失、探针过严或 OOMKilled。

快速定位

kubectl get pod <pod> -o wide
kubectl describe pod <pod>
kubectl logs <pod> --previous
kubectl logs <pod> -c <container> --previous
kubectl get events --sort-by=.lastTimestamp | tail -20
kubectl get pod <pod> -o jsonpath='{.status.containerStatuses[*].lastState}'

资源与探针：

kubectl get pod <pod> -o yaml | grep -A8 -E 'resources:|livenessProbe:|readinessProbe:|startupProbe:'

常见根因

应用启动报错：配置、环境变量、密钥、依赖服务不可达。
OOMKilled：内存 limit 太小或应用内存超限。
liveness/startup 探针过严，应用还没启动就被重启。
initContainer 失败或镜像入口命令错误。
权限、只读文件系统、挂载卷或 ServiceAccount 问题。

修复

先看 --previous 日志和 describe 的 Events，确认退出码和原因。
配置/密钥缺失就补齐 ConfigMap/Secret，并确认挂载路径。
OOMKilled 就调整 memory limit 或修内存问题。
探针失败就加 startupProbe、放宽 initialDelaySeconds/failureThreshold。
用 kubectl run 或临时 Pod 验证镜像入口和依赖连通性。

相关命令

kubectl — Pod 状态与日志
k8s 分支的 pod / deployment 页面 — 对象细节

读完自测

合上页面，先回答，再展开对照。

排查 CrashLoopBackOff 时，为什么优先看 kubectl logs <pod> --previous？
应用启动慢、还没就绪就被重启，应调整什么？
如何判断崩溃是否由 OOMKilled 引起？

答案

容器可能正在反复重启，--previous 能看到上一次退出的日志。再结合 describe 的 Events 确认退出码和原因。
加 startupProbe，并放宽 initialDelaySeconds/failureThreshold。这样可以避免应用还没启动就被 liveness 探针重启。
看 describe 的 Events 和 containerStatuses 的 lastState，确认是否 OOMKilled。若是，就调整 memory limit 或修内存问题。