crashloopbackoff表示pod容器启动后频繁崩溃并被kubelet按指数退避策略重启；需依次执行kubectl get pods定位状态、kubectl describe pod查看events和退出码、kubectl logs --previous获取前次日志、检查资源限制与oomkilled事件、验证livenessprobe配置，并可借助kubectl-debug深入调试。
确认目标Pod处于CrashLoopBackOff状态
执行 kubectl get pods -n <namespace></namespace>，找到状态为 CrashLoopBackOff 且 RestartCount 持续上升的 Pod。注意：如果 Pod 还未进入退避周期（比如刚部署几秒就崩），可能显示为 ErrImagePull 或 ContainerCreating，此时不适用本流程。
安装 kubectl-debug 插件（如未安装）
运行 curl -sLO https://github.com/aylei/kubectl-debug/releases/download/v0.4.1/kubectl-debug_0.4.1_linux_amd64.tar.gz && tar zxvf kubectl-debug_0.4.1_linux_amd64.tar.gz && sudo mv kubectl-debug /usr/local/bin/。
验证安装：kubectl debug --help 应输出帮助信息。若提示 command not found，说明未正确放入 PATH 路径，需检查 /usr/local/bin 是否在 shell 的 $PATH 中。
用 kubectl-debug 启动调试容器并复现现场
方法一：直接 attach 到崩溃前的容器命名空间（推荐）
执行 kubectl debug <pod-name> -n <namespace> --image=nicolaka/netshoot --target=<container-name></container-name></namespace></pod-name>。其中 --target 参数必须指定，否则调试容器无法共享目标容器的 PID、网络或 IPC 命名空间，将无法看到真实进程树或监听端口。
方法二：进入 Pod 的 network namespace 但不共享进程空间
适用于需抓包但不关心进程状态的场景：kubectl debug <pod-name> -n <namespace> --image=nicolaka/netshoot --share-processes=false --network-target=<container-name></container-name></namespace></pod-name>。这一步不会看到目标容器的 ps aux，但 curl localhost:8080 或 tcpdump 仍有效。
【关键前提】 目标 Pod 所在节点必须已安装 debug-agent DaemonSet，否则 kubectl-debug 会卡住或报错 agent not found。若集群未预装，需先部署：kubectl apply -f https://raw.githubusercontent.com/aylei/kubectl-debug/master/scripts/agent_daemonset.yml。
在 debug 容器中定位根因
第一步：确认目标容器是否真的“刚崩”
执行 ps aux | grep <your-app-binary></your-app-binary>。如果进程不存在，说明它已退出；如果存在但 CPU 占用为 0%，可能是卡死而非崩溃。
第二步：检查端口与健康探针路径
运行 ss -tuln | grep :8080（替换为你应用的实际端口）。若无监听，说明应用根本没启动成功——问题在启动阶段，不是运行时崩溃。
第三步：模拟存活探针请求
执行 curl -v http://localhost:8080/healthz 2>&1 | head -20。如果返回 connection refused，说明应用未监听；如果超时或返回非 2xx，要检查应用日志里是否有初始化失败（如数据库连不上、配置文件解析异常）。
第四步：查看宿主机资源瓶颈
运行 df -h /var/lib/docker 和 free -h。若磁盘使用率 >95% 或可用内存
获取崩溃前最后一刻的日志线索
在 debug 容器中执行：kubectl logs <pod-name> -n <namespace> --previous -c <container-name> 2>&1 | tail -30</container-name></namespace></pod-name>。
这一步必须加 --previous，否则只能看到空日志或 debug 容器自己的输出。很多崩溃发生在主进程启动后 2 秒内，标准 kubectl logs 根本来不及捕获。
重点搜索三类关键词：Exception（Java/Python）、Segmentation fault（C/C++）、no such file or directory（路径或动态库缺失）。若看到 OutOfMemoryError 或 Killed process，立即跳转检查资源限制和 OOMKilled 事件。
