适用范围与前提
用于排查 Kubernetes 工作负载的 Pod 长时间等待、反复重启和未就绪问题。操作者需要目标命名空间的资源、事件及日志读取权限。先确认集群上下文、业务影响、最近发布版本和期望副本数；本文是待环境验证的排查参考，不表示任何集群已经完成演练。命令中的大写名称均为占位符，执行前替换为实际值。
先保存现场与时间线
先记录首次异常时间、Pod 名称、节点、镜像版本及所属控制器，再比较同一服务正常副本。不要把删除 Pod 作为取证的第一步，重建后名称和短期事件可能变化。采集日志时控制时间范围，并在分享前遮盖令牌、用户信息和连接字符串。
kubectl config current-context
kubectl -n NAMESPACE get pod POD_NAME -o wide
kubectl -n NAMESPACE describe pod POD_NAME
kubectl -n NAMESPACE logs POD_NAME -c CONTAINER_NAME --tail=200 --timestamps
kubectl -n NAMESPACE logs POD_NAME -c CONTAINER_NAME --previous --tail=200 --timestamps上一实例不存在时，--previous 可能无日志；这不能单独证明容器没有发生故障。将输出与发布记录按时间对应，并保存 restartCount、退出原因和事件消息。
Pending：定位阻塞条件
从调度事件区分资源不足、节点选择条件不匹配、污点限制与卷绑定等待。确认 requests、亲和性、容忍配置是否符合该工作负载的真实约束，再查看相关 PVC 和节点状态。单个 Pod 的 Pending 不足以证明集群容量不足；应核对同批次副本和候选节点。不要仅为消除告警而删除必要的调度隔离条件。
镜像拉取失败与反复退出
遇到镜像拉取错误，逐项核对完整镜像地址、标签、仓库可达性和拉取凭据引用，不输出 Secret 正文。遇到 CrashLoopBackOff，把它视为容器反复失败后的退避表现，而非根因。结合上一次日志、退出码和 lastState 判断启动参数、依赖连接、权限或资源限制问题。若显示 OOMKilled，继续检查内存趋势和工作负载限制，避免仅提高额度掩盖泄漏。
Running 但未就绪
Running 不等于能够承接业务请求。核对 readiness、startup 与 liveness 探针的目标、端口和超时，再检查容器是否监听预期地址。将依赖故障与进程自身故障分开记录，避免把短暂下游异常配置成频繁重启。随后核对 Service 选择器及 EndpointSlice，确认就绪副本进入正确服务端点；不要仅凭页面可以打开便认定全部流量路径恢复。
验收与交接记录
选择一个事先约定、覆盖业务请求和至少若干次探针周期的观察窗口。验收应同时满足期望副本就绪、重启计数稳定、异常事件不再持续增加、关键请求成功率和延迟恢复至团队基线。记录根因证据、修改对象、版本差异、未解决风险及跟进人；若仅重建后恢复而无证据解释原因，记录为临时恢复。
停止与回退条件
如果异常跨越多个服务或节点、控制面请求失败，停止重复修改单个工作负载并升级为集群级排查。涉及卷损坏或数据不一致时，先由存储或应用负责人确认数据保护方式。若新版本与异常时间明确相关，按该服务已验证的发布回退流程恢复已知版本；数据库迁移、持久化格式变化和 StatefulSet 不能简单套用无状态回退。回退后仍需完成上述验收。