Pod崩溃后需用kubectl logs --previous查看上一次运行日志，单容器直接加参数，多容器须指定-c；若失败则查kubectl describe中的Events和Exit Code，结合资源监控与临时调试容器深入排查。
Pod 崩溃后日志往往不在当前运行的容器里，直接 kubectl logs 通常为空或只显示启动失败后的极短片段。真正有用的日志，是它上一次崩溃前输出的内容——Kubernetes 通过 --previous 参数保留了这部分。
用 --previous 查看上一次崩溃日志
这是最常用也最有效的第一步。Kubelet 默认会保留前一个已退出容器的日志（前提是该容器曾成功启动并写入 stdout/stderr）。
- 单容器 Pod：
kubectl logs--previous -n - 多容器 Pod：必须指定容器名，
kubectl logs--previous -c -n - 若报错
Error from server (BadRequest): previous terminated container "xxx" not found，说明该容器从未成功启动过（例如镜像拉取失败、启动命令不存在），此时应转向事件排查
结合 describe 查看事件和退出原因
日志只是应用层线索，底层触发因素藏在 Pod 事件中。执行 kubectl describe pod 后重点关注两处：
-
Events 列表：找 Warning 级别事件，如
OOMKilled（内存超限，exit code 137）、BackOff（反复重启）、FailedPostStartHook（启动后钩子失败） -
Containers → Last State：查看
Exit Code和Reason，例如Exit Code: 1表示应用异常退出，Exit Code: 137几乎肯定为 OOM，Reason: Error可能是进程未启动即崩溃
确认资源是否被强制终止
很多 CrashLoopBackOff 实际是内存爆掉被内核 kill，而非程序逻辑错误。需交叉验证：
- 运行
kubectl top pod查看实时内存/CPU 使用量--containers -n - 同步执行
kubectl describe pod查看配置的 memory limits-n | grep -A 5 "Limits\|Requests" - 若内存使用长期贴近 limits，且 Events 中有
OOMKilled，就该调高resources.limits.memory或优化应用内存占用
进阶：临时容器调试（无日志时兜底）
当 --previous 返回空、describe 无有效事件、且容器镜像又没 shell（如 distroless），可用临时调试容器深入现场：
- 执行
kubectl debug -it--image=busybox:latest --share-processes -n - 进入后可查看
/proc/1/root/下原容器文件系统，或用ps auxf看进程树残留 - 注意：需集群启用 Ephemeral Containers 特性（v1.25+ 默认开启）
