crashloopbackoff 表示容器启动后立即退出，排查须分三步：先用 kubectl describe pod 查 events 中的 warning（如 oomkilled）和 last state 的 exit code（如137为oom）；再用 kubectl logs --previous 获取崩溃前日志，重点搜索异常关键词；最后核对资源配置，如 memory limits 过低、livenessprobe 初始延迟不足或 command 路径错误等。
CrashLoopBackOff 不是 Pod 没启动，而是容器启动后立刻退出 —— 查看它必须分三步：先看事件、再捞前次日志、最后核对资源配置。
用 kubectl describe pod 抓关键事件和退出码
这是第一反应动作，kubectl describe pod <pod-name> -n <namespace></namespace></pod-name> 输出里最值得盯的是两块：
-
Events区域的Warning条目：比如OOMKilled（内存超限）、FailedScheduling（调度失败）、ImagePullBackOff（镜像拉不到） -
Containers下的Last State字段：看Exit Code是多少 ——137基本就是 OOM，1或2多是应用启动报错，126通常是权限问题（比如command不可执行）
用 kubectl logs --previous 读上一轮崩溃前的日志
当前容器可能根本没来得及打日志就挂了，--previous 是唯一能拿到崩溃现场输出的方式：
Codex Auth Cleaner
下载
一款AI工具，主要用于Monitor and clean up invalid Codex authentication files in CPA. Check quota status, disable files returning 401 errors, and perform dual verification before deletion.，适合需要提升相关任务效率的用户。
- 单容器 Pod：
kubectl logs <pod-name> -n <namespace> --previous</namespace></pod-name> - 多容器 Pod：必须加
-c <container-name></container-name>，否则报错multiple containers - 重点搜：
Exception、Connection refused、No such file、java.lang.OutOfMemoryError、exec format error（常见于 ARM 镜像跑在 x86 节点）
检查资源限制与探针配置是否反向杀死自己
很多 CrashLoopBackOff 其实是自限制造成的：
-
resources.limits.memory设太低？Java 应用默认堆大小可能直接超限，Exit Code 137就是证据 -
livenessProbe初始探测时间（initialDelaySeconds）太短？应用还没起来就被 probe 杀掉，反复循环 -
readinessProbe配了但路径返回非 200？虽然不直接导致 Crash，但配合某些 sidecar 或服务网格逻辑可能触发异常重启 - Init 容器失败也会卡住主容器启动 ——
kubectl describe里看Init Containers状态，不是只盯主容器
真正难定位的，往往是 Exit Code 1 + --previous 日志里只有半行报错，或者日志全空 —— 这时候得怀疑是不是命令写错了（比如 command: ["sh", "-c", "app.sh"] 但 app.sh 根本没 COPY 进镜像），或者用了 busybox 类无守护进程镜像却没给 sleep 参数，一启动就退出。这些细节不在事件或日志里体现，得翻 kubectl get pod -o yaml 对照镜像实际内容看。
