排障决策树：Pending / ImagePull / CrashLoop

决策树要「分流」而不是「并列猜」。Pending：容器还没真正跑起来，优先调度与资源——FailedScheduling、节点污点、资源请求过大、PVC 未 Bound。ImagePullBackOff / ErrImagePull：镜像名、tag、仓库鉴权、节点出网——Events 里的 Failed 拉取信息几乎总是第一证据。CrashLoopBackOff：进程起来又退出，或 liveness 反复杀死——logs --previous 看被杀前最后一行，再决定是改应用、改命令参数，还是收回过激探针。把顺序练成条件反射，比背十个冷门命令更有用。

# 1) 分流
kubectl get pods -o wide
kubectl get pods --field-selector=status.phase!=Running

# 2) 证据（按 STATUS 选一条）
kubectl describe pod <pod>
kubectl logs <pod> --previous --tail=100
kubectl get events --sort-by='.lastTimestamp' | tail -n 30

# 3) 对照样本（仅 Running 时）
kubectl exec -it <healthy-pod> -- sh -c 'ps aux; printenv | head'

写故障报告时，强迫自己用「可复查的命令」代替形容词。不要写「好像是网络问题」，要写「describe Events 在 14:02 出现 FailedScheduling: 0/1 nodes are available: 1 Insufficient memory」。不要写「可能是镜像坏了」，要写「Events: Failed to pull image "nginx:does-not-exist-xyz": not found」。这种证据习惯迁移到工单与复盘里，会直接减少来回追问。若同时出现多种 STATUS，按「能否调度 → 能否拉镜像 → 能否稳定运行」的依赖顺序处理，先打通上游阻塞。

要点

先 STATUS 分流，再 Events 钉证据，最后 logs 对齐应用——删 Pod 是手段，不是诊断。

中阶收官时，你应能对同事做三道口头题：Pending 第一步敲什么？ImagePull 在 describe 里找哪类句子？CrashLoop 为什么常常需要 --previous？答得出且能指向具体命令，排障决策树就算长进肌肉里了。之后高阶的网络、存储、RBAC，只是在同一棵树上长出的旁支：仍然是 get 看清对象，describe/logs 收集证据，再改期望状态而不是 SSH 进节点硬修。