从状态而不是猜测开始#
Pod 异常先分为 Pending、CrashLoopBackOff、ImagePullBackOff、Running 但不就绪、已被驱逐五类。先收集对象状态和事件，不要一上来进入节点重启 kubelet。
bash
kubectl get pod -n production -o wide
kubectl describe pod api-7d9f8c6f5b-x2k9m -n production
kubectl get events -n production --sort-by=.lastTimestamp | tail -30
按阶段排查#
| 状态 | 优先证据 | 常见方向 |
|---|---|---|
| Pending | Events、调度条件 | 资源、亲和性、PVC |
| ImagePullBackOff | Events | 镜像名、凭据、网络 |
| CrashLoopBackOff | 当前/上次日志 | 配置、依赖、启动命令 |
| NotReady | 探针、端点 | 路径、端口、启动时间 |
| OOMKilled | lastState、limits | 内存峰值、限制 |
bash
kubectl logs -n production api-7d9f8c6f5b-x2k9m -c api --tail=200
kubectl logs -n production api-7d9f8c6f5b-x2k9m -c api --previous
kubectl get pod api-7d9f8c6f5b-x2k9m -n production -o jsonpath='{.status.containerStatuses[*].lastState}'
kubectl get endpointslice -n production -l kubernetes.io/service-name=api
临时调试容器#
当业务镜像没有 shell、curl 或 dig 时，使用临时容器而不是修改生产镜像：
bash
kubectl debug -n production pod/api-7d9f8c6f5b-x2k9m -it --image=busybox:1.36 --target=api
完成定位后删除临时资源，并把可复用检查写入 readiness/startup probe 或监控。Kubernetes 官方的 Debug Pods 流程同样强调先查看状态和事件。
讨论区 42
分享你的经验、补充或不同观点。支持 Markdown 基础语法。