标准答案
- 查看当前和 previous 日志、容器退出码、终止原因、事件和实际启动命令，区分应用主动退出、信号、OOM 和探针杀死。
- 核对 ConfigMap、Secret、挂载、工作目录、用户、依赖连接和镜像架构，避免只盯应用代码。
- 如果是 liveness 过早失败，先修正 startup/readiness/liveness 边界；如果是配置或依赖失败，应修复启动条件。
- 临时调试可复制同一镜像和配置到隔离环境，避免直接修改线上 Pod 掩盖证据。
题目解析
CrashLoopBackOff 是 kubelet 对反复退出容器增加退避等待的状态，不是根因。退出可能来自应用配置错误、主动返回非零、信号、OOM、入口失败或探针杀死；第一次失败时的日志和退出码通常比后续重复启动更有信息。
排查先看当前与 --previous 日志、container state/lastState、退出码、events、实际 command/args、ConfigMap/Secret、挂载、用户、依赖和探针。不要先 rollout restart 清除现场；修复后要验证启动时间、readiness、流量和重启次数恢复。
常见误区
- 误区：只执行 logs 不加 --previous。改正：同时查看上一次实例的日志、退出码和终止原因。
- 误区：盲目 rollout restart。改正：先保留事件和配置证据，确认是新版本、配置、探针还是资源问题。