科技 · 实用指南
Kubernetes 出现 CrashLoopBackOff？重启 Pod 前先保全上一次终止证据
CrashLoopBackOff 是退避状态，不是根因。删除或重启前，先保存准确容器、Last State、退出码、事件与 previous logs。
Pod 显示 CrashLoopBackOff，只说明某个容器反复终止，Kubernetes 正在延迟下一次重启；它还不能告诉你进程是正常结束、内存不足、探针失败还是应用崩溃。先保全上一实例，再让终止证据决定下一责任人。
冻结证据窗口
确认命名空间、Pod、准确容器与所属控制器，保存重启次数和时间。对 Pod 执行 describe，记录容器状态、Last State、原因、退出码、开始与结束时间及近期事件；再保存指定容器的 previous logs。必须在删除、rollout restart 或人工修改容器前完成。
previous logs 为空时
先确认命令指向正确容器；sidecar 与 init container 各有独立记录。即使没有应用日志，也要读取终止原因、退出码与事件。检查 termination-message 配置；权限允许时创建调试副本，而不是修改唯一失败样本。平台日志留存可辅助，但不能替代本地证据包。
按终止信号分支
退出 0 往往说明进程正常完成，却被放在需要持续重启的工作负载或命令中。OOMKilled 首先交给应用内存行为与容器限制。反复的 liveness 或 startup-probe 事件首先检查探针目标、时序和依赖就绪。带应用堆栈的非零退出交给失败代码或依赖。
不要混合原因家族
镜像拉取、调度失败与准入错误属于不同状态。当前日志可读不代表上次终止不存在；探针症状也不证明探针一定配置错误，进程可能确实不健康。把每项材料能证明的事实写清，将假设与退出、事件、日志证据分开。
只改一个责任层并观察完整窗口
只对已证实责任层做一次范围明确的修改：命令或控制器形态、内存行为或限制、探针配置，或应用/依赖故障。记录工作负载版本，并跨越预期启动与探针窗口持续观察重启次数、Last State 与事件，避免把短暂安静误当恢复。
用可复现证据收尾
只有预期控制器运行正确容器、重启次数不再增加、探针持续健康且原业务路径成功，事件才算结束。附上修改前证据包、唯一修改、修改后窗口与回滚步骤；若证据指向其他团队，就交付这份准确证据包，而不是盲目重启。
