Kubernetes Service 访问不通的三层深度排查

Kubernetes Service 访问不通的三层深度排查在 Kubernetes 生产环境中“Service 访问不通”是一个发生频次极高、排查链路横跨多个网络层级的复杂故障。很多初级工程师在遇到curl order-service:8080报错Connection refused或i/o timeout时往往陷入迷茫只能盲目地重启 Pod 或重启节点。Kubernetes 的 Service 并不是一个物理实体它本质上是由 DNS 解析、APIServer 端点控制器、以及节点内核网络规则iptables / IPVS共同编织出的一层分布式虚拟负载均衡网络。要快速定位 Service 访问不通的根因必须建立起一套严密的**“DNS 解析层 → 控制面 Endpoint 发现层 → 数据面内核数据包转发层”**三层排查链条。[ 客户端 Pod 发起: curl order-service:8080 ] │ ▼ (第一层排查: CoreDNS 域名解析) [ CoreDNS 是否正确返回 ClusterIP: 10.96.12.34 ? ] │ (是) ▼ (第二层排查: 控制面 Endpoint 挂载) [ Endpoints / EndpointSlice 是否包含健康的 Pod IP ? ] │ (是) ▼ (第三层排查: 数据面内核转发规则) [ 宿主机 iptables / IPVS 规则与 CNI 网络插件是否正常 ? ] │ (是) ▼ [ 成功到达目标 Pod ]第一层排查CoreDNS 域名解析与 ndots 机制当客户端使用服务名如order-service发起请求时首先依赖 CoreDNS 完成域名到 ClusterIP 的解析。1. 排查诊断命令# 登录排障客户端 Pod kubectl exec -it debug-pod -n prod -- sh # 1.1 直接测试 DNS 解析 nslookup order-service.prod.svc.cluster.local # 1.2 若解析超时直接测试能否解析 CoreDNS 自身 dig 10.96.0.10 order-service.prod.svc.cluster.local short2. 常见故障点与根因CoreDNS 自身高负载或挂掉检查kubectl get pods -n kube-system -l k8s-appkube-dns确认 CoreDNS 副本是否处于 Running 状态无 OOMKilled。/etc/resolv.conf的ndots:5放大效应由于默认ndots:5每次查询短域名都会在prod.svc.cluster.local、svc.cluster.local、cluster.local之间递归追溯 4 次以上高并发下导致 CoreDNS 被打爆。在客户端引入完整 FQDN 域名或配置 NodeLocal DNSCache 即可解决。第二层排查控制面 Endpoint 关联与就绪探针如果 DNS 能够成功解析出 ClusterIP如10.96.12.34但curl该 IP 依然报错Connection refused说明问题出在控制面的 Pod 端点发现阶段。1. 排查诊断命令# 检查 Service 关联的 Endpoints 与 EndpointSlice kubectl get endpoints order-service -n prod kubectl get endpointslice -l kubernetes.io/service-nameorder-service -n prod # 检查 Service 的 Label Selector kubectl get svc order-service -n prod -o jsonpath{.spec.selector}2. 常见故障点与根因Label Selector 标签不匹配Service 的spec.selector拼写错误如app: order-svc误写为app: order-service导致没有匹配到任何底层 PodENDPOINTS显示为none。就绪探针Readiness Probe失败Pod 虽然处于Running状态但由于健康检查接口返回 500 或超时K8s 判定其尚未就绪主动将该 Pod 的 IP 从 Endpoints 列表中剔除。必须通过kubectl describe pod pod_name查看 Readiness 事件。端口映射错位Port vs TargetPortService 的port是 Service 暴露的虚拟端口而targetPort必须严格等于容器进程实际监听的物理端口。第三层排查数据面 iptables / IPVS 内核转发与 CNI 插件如果 Endpoints 列表里存在健康的 Pod IP例如10.244.1.45:8080直接curl 10.244.1.45:8080正常但curl 10.96.12.34:8080通过 ClusterIP却不通说明问题出在节点内核的kube-proxy数据转发层。1. 排查诊断命令登录客户端 Pod 所在物理宿主机# 1.1 若 kube-proxy 为 IPVS 模式: 查看虚拟服务器与真实 Real Server 映射 ipvsadm -ln | grep -A 3 10.96.12.34 # 1.2 若 kube-proxy 为 iptables 模式: 检查 KUBE-SERVICES 链 iptables -t nat -L KUBE-SERVICES -n -v | grep 10.96.12.34 # 1.3 查看 kube-proxy 组件日志 kubectl logs -n kube-system -l k8s-appkube-proxy --tail1002. 常见故障点与根因kube-proxy发生死锁或崩溃由于 APIServer 压力大kube-proxy与 APIServer 的 Watch 连接中断未能及时同步最新的网络规则。Linux 内核bridge-nf-call-iptables被关闭在某些节点初始化脚本中若未设置sysctl -w net.bridge.bridge-nf-call-iptables1二层网桥流量不会经过 iptables 规则链导致 ClusterIP 的 NAT 地址转换彻底失效。跨主机 CNI 隧道丢包Calico / Flannel MTU 错位如果物理宿主机网络 MTU 为 1500而 Calico VXLAN 隧道网卡 MTU 也设为 1500封装后的外层报文超过 1500 且开启了禁止分片DF大包跨主机传输时会被网卡静默丢弃。必须将 CNI 网卡 MTU 调小为1450预留 50 字节头部开销。总结排查 Kubernetes Service 访问故障绝不能无目的地乱试。严格遵循**“先看 DNS 能否出 IP → 再看 Endpoints 是否挂着 Pod → 最后下沉到宿主机看 IPVS 转发与 MTU”**的三层诊断路径任何复杂的网络断连问题都能在 3 分钟内精准定位根因。