CrashLoopBackOff本质是容器进程非正常退出（如panic、segfault、未捕获异常）后被kubelet按restartPolicy持续拉起的指数退避循环；需通过kubectl describe pod查Events与Exit Code、kubectl logs --previous抓崩溃日志，并用sleep临时保活后exec进容器手动调试验证。
Pod 因应用未捕获系统错误而高频重启（CrashLoopBackOff），本质不是死锁，而是**进程非正常退出后被 Kubernetes 持续拉起的循环**。所谓“死锁”是误读——容器里没有线程阻塞等待资源，而是程序一启动就 panic、segfault、空指针或未处理异常，直接退出（exit code 非 0），kubelet 立即按 restartPolicy 重启，形成指数退避循环。
确认是否真由未捕获错误导致
先排除其他高频干扰项，再聚焦应用层：
- 执行 kubectl describe pod <name>，检查 Events 中是否有 OOMKilled (137)、ImagePullBackOff、FailedScheduling —— 这些与应用代码无关
- 看 Containers → Last State → Exit Code：若为 2（bash 命令未找到）、127（command not found）、134（SIGABRT）、139（SIGSEGV）等，基本指向应用启动失败或运行时崩溃
- 对比 Restart Count 和 Age：若重启次数高但 Pod 存活时间极短（如几秒），说明进程几乎没跑起来，大概率是启动阶段就挂了
获取真实崩溃现场日志
普通 kubectl logs 可能为空，因为容器已重启、旧实例销毁。关键动作是抓取上一轮输出：
- 运行 kubectl logs <pod-name> --previous（单容器）或 kubectl logs -c <container-name> <pod-name> --previous（多容器）
- 重点搜：panic:、Exception in thread、Segmentation fault、java.lang.NullPointerException、ModuleNotFoundError、ImportError
- 若日志仍为空，说明进程在打印任何内容前就崩溃了（如 C/C++/Go 的 init 段段错误，或 Python 导入时报 core dump）
让容器“先活下来”，再深入诊断
不修改代码也能快速验证：绕过原启动逻辑，保持容器运行，然后进去查环境、依赖、配置：
- 临时 patch Deployment：kubectl patch deploy <name> --type='json' -p='[{"op":"replace","path":"/spec/template/spec/containers/0/command","value":["sleep","infinity"]}]'
- 等 Pod 变成 Running 后，执行 kubectl exec -it <pod-name> -- /bin/sh（或
/bin/bash） - 进容器后手动执行原启动命令（如
./app或python main.py），观察实时报错；同时检查：
–ls -l /app（文件权限、是否存在）
–ldd ./app（动态库缺失）
–env | grep -i "db\|config"（关键环境变量是否注入）
–cat /proc/1/cmdline | tr '\0' ' '（确认实际执行路径）
从构建和运行时加固预防
避免下次部署重蹈覆辙：
- 镜像内加入最小化健康检查：在 entrypoint 脚本开头加
set -e，并在关键步骤后加echo "[OK] loaded config"，让失败点更早暴露 - 应用启动时增加基础防护：如 Go 加
defer func(){ if r := recover(); r != nil { log.Fatal("PANIC: ", r) } }()；Python 加全局sys.excepthook捕获未处理异常并写日志 - CI/CD 阶段增加启动冒烟测试：用
docker run --rm <image> /bin/sh -c './app --help || exit 1'验证二进制可执行、依赖可加载 - 资源限制设合理下限：至少保证
requests.memory: 128Mi，防止因调度到内存紧张节点触发 cgroup OOM 杀进程，掩盖真实错误
