摘要 ： 本文是关于 Kubernetes 中 Service 无法访问问题的深度分析，结合根本原因、诊断策略与解决方案的系统性指南：

---

Kubernetes Service 访问故障全景解析：从底层机制到实战修复

Service 作为 Kubernetes 集群内网络通信的核心抽象，其不可访问问题往往涉及多层级故障。本文将从配置层、网络层、控制平面层三个维度展开深度分析，并提供可落地的排查框架。

---

一、配置层：Service 与 Pod 的关联失效

1. 标签选择器（Selector）匹配失败

• 现象：Service 的 Endpoints 列表为空（kubectl get endpoints <svc> 无输出）。
• 根本原因：
  • Pod 的标签（Labels）与 Service 的 selector 不一致；
  • 标签拼写错误或大小写敏感问题（如 app: myapp vs app: MyApp）。
• 解决方案：

  # 检查 Pod 标签  
  kubectl get pods --show-labels | grep <app-name>  
  # 修改 Service 的 selector 或修正 Pod 标签  
  kubectl edit svc <service-name>
  

2. 端口映射错误

• 现象：kubectl describe svc 显示端口配置，但 targetPort 与 Pod 监听端口不匹配。
• 案例：
  • Service 定义 targetPort: 8080，但 Pod 实际监听 80 端口。
• 修复：

  spec:ports:- port: 80        # Service 暴露端口targetPort: 80  # 必须与 Pod 容器端口一致
  

3. Service 类型误用

• 常见错误：
  • 需外部访问的服务误用 ClusterIP（仅限集群内访问）；
  • NodePort 端口被节点防火墙阻断。
• 纠正方案：

  spec:type: LoadBalancer  # 外部访问推荐类型# 或 NodePort + 放行防火墙规则
  

---

二、网络层：流量拦截与路由失效

1. 网络策略（NetworkPolicy）阻断

• 现象：同一命名空间内可访问 Service，跨命名空间失败。
• 诊断：

  kubectl get networkpolicy -A          # 检查策略是否存在
  kubectl describe networkpolicy <name> # 查看策略规则
  

• 修复：调整策略允许跨命名空间访问：

  ingress:- from:- namespaceSelector: {}  # 允许所有命名空间
  

2. DNS 解析故障

• 典型表现：
  • 通过 Service IP 可访问，但域名解析失败；
  • nslookup my-svc 返回空或超时。
• 排查步骤：
  1. 检查 CoreDNS 状态：

     kubectl get pods -n kube-system -l k8s-app=kube-dns
     

  2. 在临时 Pod 中测试解析：

     kubectl run dns-test --image=busybox:1.28 -it --rm --restart=Never -- \nslookup my-svc.<namespace>.svc.cluster.local
     

  3. 验证 /etc/resolv.conf 配置：

     nameserver 10.96.0.10     # 必须指向集群 DNS IP
     search <ns>.svc.cluster.local  # 命名空间搜索域
     options ndots:5            # 至少为 5
     

3. kube-proxy 或 CNI 插件异常

• 关键指标：
  • NodePort 在节点本地无法访问（curl localhost:<NodePort> 失败）；
  • iptables-save | grep KUBE-SVC 无对应规则。
• 操作：

  # 重启 kube-proxy  
  kubectl delete pod -n kube-system -l k8s-app=kube-proxy  
  # 检查 CNI 插件日志（如 Calico）  
  kubectl logs -n kube-system -l k8s-app=calico-node
  

---

三、控制平面层：Endpoint 与路由同步失败

1. EndpointSlice 未同步

• 现象：kubectl get endpointslices 显示 Service 无关联 Pod IP。
• 根因：
  • 控制管理器（Controller Manager）故障；
  • 节点失联导致状态未更新。
• 强制刷新：

  kubectl patch endpoints <svc-name> -p '{"subsets":[]}'  # 清空 Endpoints 触发重建
  

2. 节点路由异常（跨节点通信）

• 诊断命令：

  # 在目标节点追踪 Service IP 路径
  mtr -n -T -P <targetPort> <Service IP>
  

• 常见问题：
  • VxLAN 端口（如 8472）被防火墙阻断；
  • 节点间路由表错误。
• 解决：

  iptables -I INPUT -p udp --dport 8472 -j ACCEPT  # 放行 Flannel 流量
  sysctl -w net.ipv4.ip_forward=1                  # 启用 IP 转发
  

---

四、进阶故障场景与深度修复工具

1. 延迟类问题（访问慢但非完全不可用）

• 排查工具：

  # 测量各阶段耗时（DNS/连接/数据传输）
  curl -o /dev/null -s -w \"DNS: %{time_namelookup}s | Connect: %{time_connect}s | Transfer: %{time_total}s\n" \http://my-svc:80
  

• 优化方向：
  • DNS 解析 >100ms → 检查 CoreDNS 负载；
  • 连接建立 >1s → 排查节点间网络质量。

2. 分布式追踪工具集成

• 方案：注入 Service Mesh 代理（如 Istio）捕获流量：

  sidecar.istio.io/inject: "true"  # 在 Pod 注解启用
  

• 价值：可视化跨 Service 的请求链路，定位延迟或丢弃点。

---

终极排查框架：六步定位法

1. 查状态：kubectl get svc,endpoints,pods -l app=<label> [[1][8]]；
2. 验网络：从临时诊断 Pod 发起 curl 和 nslookup（镜像：nicolaka/netshoot）；
3. 看策略：kubectl get networkpolicy -A 与 calicoctl get networkpolicy；
4. 溯日志：采集 kube-proxy、CoreDNS、CNI 插件日志；
5. 抓规则：节点执行 iptables-save | grep KUBE-SVC 验证 NAT 规则；
6. 跨节点：mtr 测试节点间路由，确认云厂商安全组放行。

典型故障案例复盘

• 案例 1：Endpoints 残留旧 IP → kubectl patch endpoints 强制刷新；
• 案例 2：NodePort 冲突 → ss -tuln | grep <port> 定位占用进程；
• 案例 3：ndots:5 配置缺失 → 修复 Pod 的 /etc/resolv.conf。

---

总结：Service 访问故障防御矩阵

层级	关键防御点	工具/命令
配置层	标签匹配、端口映射	kubectl describe svc
网络层	网络策略、DNS 解析、CNI 插件	nslookup, kubectl debug
控制平面层	EndpointSlice 同步、路由表	kubectl get endpointslices
节点层	防火墙、连接跟踪表（conntrack）	iptables-save, conntrack -L

黄金守则：优先通过集群内临时 Pod 测试（排除外部干扰），再逐层向上/向下排查[[1][39]]。 保持对 kube-proxy 模式（iptables/IPVS）的认知，是解锁复杂网络问题的钥匙。