【故障排查指南】Service不通？DNS解析失败？训练营教我的K8s网络诊断“五步法”救了产线！
上周三凌晨2点，公司核心业务突然告警：用户无法访问订单服务。监控显示Pod运行正常，但上游服务调用超时。作为刚转岗SRE不到三个月的新人，我一度手足无措——直到想起「云原生实战训练营」教的 K8s网络诊断“五步法” 。凭借这套方法论，我在15分钟内定位并修复问题，避免了重大损失。今天，我想把这套救命的排查逻辑分享给每一位奋战在产线的工程师。
第一步：确认Pod是否就绪（Is the Pod Ready?）
很多人一上来就查Service或Ingress，却忽略了最基础的前提：目标Pod是否真正就绪？
我先执行：
kubectl get pods -l app=order-service
发现Pod状态为 Running，但 READY 列显示 0/1。进一步查看事件：
kubectl describe pod <pod-name>
原来就绪探针（Readiness Probe）连续失败！检查应用日志后，发现数据库连接池耗尽。问题根源不在网络，而在应用自身。重启Pod临时恢复服务，同时通知开发优化连接管理。
✅ 教训：Service流量只转发给“就绪”的Pod，未就绪的Pod会被自动剔除，导致“看似有实例，实则不可达”。
第二步：验证Service配置与Endpoints（Is the Service Wired Correctly?）
若Pod就绪仍不通，则检查Service是否正确关联到Pod：
kubectl get svc order-service
kubectl get endpoints order-service
如果Endpoints为空，说明Label Selector不匹配。曾有一次，开发误将Deployment的app标签从order-service改为order-svc，导致Service“断连”。修正标签后，Endpoints自动生成。
第三步：测试集群内DNS解析（Can I Resolve the Service Name?）
在K8s中，Service通过CoreDNS提供域名解析（如 order-service.default.svc.cluster.local）。
我进入一个调试Pod执行：
nslookup order-service
若解析失败，可能是CoreDNS异常或NetworkPolicy阻断了53端口。一次事故中，安全团队误配NetworkPolicy，禁止了非白名单Pod访问CoreDNS，导致大量服务“失联”。通过临时放行策略快速恢复。
第四步：从Pod内发起直连测试（Can I Reach the Target Port?）
即使DNS正常，仍可能因网络插件（CNI）或防火墙阻断通信。
我在调试Pod中直接telnet目标Service的ClusterIP和端口：
telnet 10.96.123.45 8080
若连接拒绝，说明Pod未监听该端口；若超时，则可能是Calico/Flannel策略或节点安全组拦截。曾因云厂商安全组未开放Pod网段，导致跨节点通信失败。
第五步：检查Ingress与外部访问链路（Is the External Path Broken?）
若内部通信正常但外部无法访问，则聚焦Ingress Controller：
- 查看Ingress资源是否绑定正确Service；
- 检查Ingress Controller日志（如Nginx Ingress）是否有404/502；
- 验证负载均衡器（如AWS ALB）健康检查状态。
结语：方法论比命令更重要
K8s网络涉及Pod、Service、DNS、CNI、Ingress等多层抽象，盲目试错只会延长MTTR。训练营传授的“五步法”之所以有效，是因为它遵循“由内到外、由简到繁”的故障隔离原则，每一步都用最小成本排除一类可能。如今，这套方法已成为我们团队的标准SOP。记住：在复杂系统中，清晰的思路，永远比熟练的命令更值钱。
