K8s排错实战Service访问故障的七步排查法当你在Kubernetes集群中遇到Pod运行正常但Service无法访问的经典故障时就像侦探面对一个密室案件——所有表面证据都指向正常但关键通路却被神秘阻断。本文将带你用系统化的七步排查法像老练的运维侦探一样揭开表象下的真相。1. 案件现场初勘确认基础症状首先需要明确故障的具体表现。执行以下基础检查# 检查Service基础信息 kubectl get svc service-name -n namespace -o wide重点关注三个关键字段CLUSTER-IP确认Service是否有分配有效的集群IPPORT(S)检查端口映射是否正确SELECTOR是否存在标签选择器注意如果SELECTOR字段为空则该Service属于Headless类型或ExternalName类型不会自动创建Endpoints常见初级误判包括误用命名空间比如在default命名空间查询本该在kube-system的服务端口号混淆比如Service暴露的是8080而应用实际监听8000基础网络插件故障整个节点的kube-proxy服务异常2. 追踪数据链路解剖Endpoints真相Service的流量最终是通过Endpoints路由到Pod的这是排查的核心环节# 查看Endpoints详情 kubectl describe endpoints service-name -n namespace健康的Endpoints应该显示类似这样的输出Name: my-service Namespace: default Labels: none Annotations: none Subsets: Addresses: 10.244.1.5,10.244.2.3 NotReadyAddresses: none Ports: Name Port Protocol ---- ---- -------- http 8080 TCP危险信号解读表异常现象可能原因验证命令Addresses为空1. Selector不匹配2. 无Running状态的Podkubectl get pods -l selectorNotReadyAddresses非空Pod处于非Ready状态kubectl get pods -w端口不匹配Service与Pod端口映射错误kubectl describe pod pod-name3. 标签迷局破解Selector匹配问题当Endpoints为空时首要怀疑对象是标签选择器。执行以下诊断# 对比Service的Selector与Pod的Label kubectl get svc service-name -n namespace -o jsonpath{.spec.selector} kubectl get pods -n namespace --show-labels | grep -E keyvalue典型匹配问题场景大小写敏感appnginx与appNginx被视为不同标签多标签条件Service指定了多个标签但Pod只满足部分标签污染Pod有额外标签导致选择器失效如envprod,releasestable修复方案示例# 错误的Selector selector: app: MyApp tier: frontend # 修正为确认Pod实际标签 selector: app: myapp tier: frontend4. Pod状态深挖超越表面的Running即使Pod显示为Running也可能存在隐藏问题。深入检查# 全方位Pod诊断 kubectl describe pod pod-name -n namespace需要特别关注的段落Conditions特别是Ready和ContainersReady状态Events查找最近的异常事件Container Statuses检查重启次数和状态常见Pod伪健康状态状态表现真实问题排查命令Running但Ready0/1探针失败kubectl logs pod-name -c container频繁重启应用崩溃kubectl logs --previous调度失败资源不足/亲和性冲突kubectl describe node node-name5. 网络拓扑验证跨越命名空间的陷阱跨命名空间访问是常见故障点。检查网络策略# 检查NetworkPolicy限制 kubectl get networkpolicy -n namespace关键验证步骤从客户端Pod执行Service的ClusterIP连通性测试kubectl exec -it client-pod -- curl -v http://service-ip:port直接访问Pod IP验证基础网络kubectl exec -it client-pod -- ping pod-ip检查kube-proxy日志kubectl logs -l k8s-appkube-proxy -n kube-system6. 高级诊断工具深入内核层当常规手段无效时需要更底层的工具# 在节点上检查iptables规则Service的底层实现 iptables-save | grep service-name # 检查conntrack表项 conntrack -L | grep service-ip # 使用nsenter进入Pod网络命名空间 nsenter -t pid -n ip addr诊断矩阵参考工具检查目标健康表现iptablesKUBE-SERVICES链存在对应Service的跳转规则conntrack连接追踪建立到后端Pod的连接记录tcpdump实际流量能看到SYN包到达Pod IP7. 终极武器分布式追踪法对于复杂微服务场景需要全链路视角在应用容器中启用调试模式kubectl exec -it pod-name -- sh -c netstat -tulnp检查Service的流量分布kubectl top pods -l service-selector使用临时调试容器进行网络测试kubectl debug -it pod-name --imagenicolaka/netshoot最终检查清单[ ] Service的Selector与Pod Labels匹配[ ] Endpoints包含正确的Pod IP和端口[ ] Pod处于Ready状态且通过健康检查[ ] 网络策略允许流量通过[ ] kube-proxy规则正确生成[ ] 节点防火墙未拦截流量记住一次成功的排错就像完成一幅拼图——每个命令都是获取一块关键信息而真正的技巧在于知道如何将这些碎片组合成完整的图景。当你下次遇到Service不通的情况时不妨把这七步法当作你的调查手册逐步缩小嫌疑范围最终锁定真正的元凶。