核心是按 “Pod 状态→网络连通→服务配置→依赖组件” 的顺序逐层定位，高效锁定根因：
1. 先查 Pod 自身状态：确认是否存活 / 正常运行
这是最基础一步，先判断 Pod 是否本身就没跑起来。
- 执行命令：
kubectl describe pod <Pod名称> -n <命名空间>，重点看Events字段（底部），排查是否有 “拉取镜像失败”“资源不足被驱逐”“健康检查失败” 等错误。 - 同步查看 Pod 状态：
kubectl get pods -n <命名空间>，若状态是CrashLoopBackOff（反复崩溃）、ImagePullBackOff（镜像拉取失败），优先解决 Pod 启动问题。
2. 再测 Pod 内部连通性：确认容器内服务是否正常
若 Pod 状态是Running，需进一步检查容器内的应用是否真的在提供服务。
- 进入 Pod 容器：
kubectl exec -it <Pod名称> -n <命名空间> -- /bin/bash（若没有 bash，换sh）。 - 内部测试服务端口：用
curl localhost:<服务端口>（或wget），若连本地都不通，说明是应用本身故障（如配置错误、进程未启动），与 K8s 调度无关。
3. 接着查 Pod 外部网络：确认网络是否能访问 Pod
若内部服务正常，问题通常在网络层面（如 Service 配置、网络插件）。
- 检查 Service 与 Pod 的关联：执行
kubectl describe svc <Service名称> -n <命名空间>，查看Endpoints字段是否包含目标 Pod 的 IP + 端口，若为空，说明 Service 的selector标签与 Pod 不匹配（标签写错是高频问题）。 - 测试节点到 Pod 的连通：在集群任意节点执行
curl <Pod的IP>:<服务端口>，若不通，排查网络插件（如 Calico、Flannel）是否故障；若通，再测集群外访问（如 Ingress 转发是否正常）。
4. 最后查依赖与日志：定位深层故障
若以上都正常，需从依赖和日志找线索。
- 检查依赖组件：确认 Pod 依赖的数据库、中间件是否正常（用
kubectl logs看 Pod 是否有 “连接超时” 错误）。 - 查看应用详细日志：
kubectl logs <Pod名称> -n <命名空间>（加-f实时查看，加--previous看崩溃前日志），从日志中定位代码错误、配置缺失等问题。
