Pod异常状态需分层排查：先用kubectl describe查看状态与Events，再查日志和exec调试，接着验证节点资源与调度约束，最后逐层检查CNI、DNS及Service网络连通性。
Pod 一直处于 Pending、CrashLoopBackOff 或 NotReady 状态，通常不是单一原因导致，而是资源、配置、镜像、节点或网络中某一个环节出了问题。快速定位的关键是分层检查：先看 Pod 自身状态和事件，再查容器日志，接着验证节点资源与调度约束，最后聚焦网络连通性与 CNI 插件行为。
看 Pod 状态和 Events 是第一反应
运行 kubectl describe pod ，重点关注两块内容：
-
Conditions：比如
Initialized=False可能是 Init 容器失败；Ready=False说明主容器没通过 readiness probe；ContainersReady=False表示至少一个容器未就绪 -
Events（最实用）：常见提示如
FailedScheduling（资源不足/污点不匹配）、ImagePullBackOff（镜像名错/私有仓库没 secret）、FailedMount（PV/PVC 绑定失败或权限问题）
如果 Events 里出现 NodeAffinity 或 Taints 相关拒绝信息，要同步检查节点的 taint 和 Pod 的 toleration 配置是否匹配。
查容器日志和 exec 进去诊断
即使 Pod 处于 CrashLoopBackOff，只要它启动过，就能拿到上一次崩溃前的日志：
-
kubectl logs查上一轮容器输出-n --previous -
kubectl logs指定多容器中的某一个-n -c - 如果容器还能短暂运行，用
kubectl exec -it进入调试（注意：有些精简镜像不含 sh，可试 ash 或 /bin/bash）-n -- sh
进容器后优先检查：配置文件路径是否存在、环境变量是否注入正确、依赖服务 DNS 是否能解析（nslookup kubernetes.default.svc.cluster.local）、端口是否被占用（netstat -tuln）。
确认节点资源与调度是否正常
Pod 卡在 Pending，大概率是调度器找不到合适节点。执行以下命令交叉验证：
-
kubectl get nodes -o wide看节点是否 Ready，资源（CPU/Mem）是否充足 -
kubectl top nodes查实时资源使用率（需 metrics-server 已部署） -
kubectl get events --sort-by=.lastTimestamp | tail -20找集群级调度失败事件 - 检查 Pod 的 resource requests 是否远超节点可用容量，或设置了 nodeSelector 但没有节点打对应 label
临时测试可删掉 resource request/limit 或修改 nodeSelector，看 Pod 是否能成功调度——这能帮你快速隔离是策略问题还是资源问题。
网络不通？从底层 CNI 到 Service 逐层验证
Pod 之间 ping 不通、无法访问 Service、DNS 解析失败，按这个顺序排查：
-
Pod IP 层通信：在源 Pod 中
ping。失败说明 CNI 插件未正确配置（如 calico/node 未运行、flannel 启动失败、kube-proxy 异常） -
DNS 解析：
nslookup kubernetes.default.svc.cluster.local。失败先查 CoreDNS Pod 是否 Running，再看其日志（kubectl logs -n kube-system deployment/coredns），并确认 kubelet 的--cluster-dns参数指向正确地址 -
Service 访问：用 ClusterIP + port curl，同时查
kubectl get endpoints确认后端 Pod 地址已同步；再查 iptables/ipvs 规则是否生成（kubectl get svc对比 endpoint IPs 是否一致）-o wide
如果所有 Pod 都无法访问外网，检查节点 host 上的 iptables FORWARD 链是否被 DROP，以及 CNI 插件是否配置了正确的 masquerade 规则。
