碰到这种Pod无法连接Service的超时问题，我通常会按从基础到复杂的顺序逐步排查，下面是具体的步骤和可能的原因：

1. 先确认Service与后端Pod的关联是否正常 #

这是最常见的问题根源，先排查这个：

• 执行kubectl get endpoints <your-service-name>，查看结果里是否有对应的Pod IP和端口。如果Endpoints列表为空，说明Service没找到匹配的Pod。
• 核对Service的spec.selector和Pod的metadata.labels是否完全一致——哪怕是大小写、空格或者标签键值对的细微差异，都会导致匹配失败。
• 用kubectl describe svc <your-service-name>查看Events字段，有没有类似“no endpoints available”的错误提示。

2. 绕过Service，直接测试Pod间的连通性 #

如果Service和Endpoints关联正常，那下一步要确认是不是Pod之间本身就不通：

• 进入发起连接的Pod（kubectl exec -it <source-pod-name> -- /bin/bash），直接用后端Pod的IP和容器端口测试，比如telnet <target-pod-ip> <container-port>或者curl http://<target-pod-ip>:<container-port>。
  • 如果直接连Pod也超时，说明问题出在Pod间的网络通信，和Service无关，直接跳到后面的网络策略、节点网络排查。
  • 如果直接连Pod能通，那问题就锁定在Service或kube-proxy层面。

3. 检查NetworkPolicy（网络策略）是否限制了流量 #

很多时候超时是因为网络策略拦截了请求：

• 执行kubectl get networkpolicy -A查看集群中所有的网络策略。
• 重点检查发起连接的Pod和后端Pod所在namespace的策略，确认是否允许源Pod访问目标Pod/Service的端口。比如有没有配置只允许特定标签的Pod访问，或者直接拒绝了所有入站/出站流量。

4. 检查节点层面的网络与转发规则 #

节点之间的网络连通性和kube-proxy的转发规则是关键：

• 节点间网络检查：从发起连接的Pod所在节点，ping后端Pod所在节点的IP，如果不通，大概率是节点的安全组、防火墙规则限制了集群内部的网络流量（比如禁止了Pod网段之间的通信）。
• kube-proxy规则检查：
  • 先确认kube-proxy的运行模式（iptables或ipvs），可以通过kubectl describe configmap kube-proxy -n kube-system | grep mode查看。
  • 如果是iptables模式，登录节点执行iptables-save | grep <service-cluster-ip>，看有没有对应的转发规则；如果是ipvs模式，执行ipvsadm -L检查是否存在Service的IP和端口条目。
  • 检查kube-proxy Pod的状态：kubectl get pods -n kube-system | grep kube-proxy，如果有Pod重启或处于异常状态，查看日志kubectl logs <kube-proxy-pod-name> -n kube-system，看有没有规则更新失败的错误。

5. 检查Pod自身的网络配置 #

Pod的网络初始化或DNS问题也可能导致超时：

• 检查发起连接的Pod是否处于Ready状态：kubectl get pod <source-pod-name>，如果状态异常，用kubectl describe pod <source-pod-name>查看Events，有没有CNI插件初始化失败的提示。
• 虽然你是直接用ClusterIP连接，但还是可以确认下DNS是否正常：在Pod里执行nslookup <your-service-name>，看能否解析到正确的ClusterIP（避免后续用域名连接时出问题）。

6. 验证Service和后端Pod的端口配置 #

别忽略了端口不匹配的情况：

• 确认Service的spec.ports[].targetPort是否和后端Pod的容器端口完全一致。比如Service的targetPort设为8080，但Pod里的应用实际监听的是80，这种情况可能会出现超时（而非直接连接拒绝）。
• 检查后端Pod的应用是否监听了正确的地址：如果应用只监听127.0.0.1，那只能在Pod内部访问，外部（包括其他Pod和Service）都无法连接，也会导致超时。可以进入后端Pod执行netstat -tulpn查看监听地址。

可能的核心原因总结 #

• Service的标签选择器与Pod标签不匹配，导致Endpoints为空
• NetworkPolicy拦截了Pod与Service之间的流量
• 节点间的安全组/防火墙规则限制了集群内部网络通信
• kube-proxy故障，未正确生成Service的转发规则
• 后端Pod的应用未监听0.0.0.0，仅允许本地访问
• CNI网络插件异常，导致Pod间无法通信

内容的提问来源于stack exchange，提问作者Pensu