企业官网建设流程全解析

核心是按 “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看崩溃前日志），从日志中定位代码错误、配置缺失等问题。