.NET Core API在Kubernetes环境下无法与Service2通信的问题求助

问题现象 #

• 失败场景：.NET Core API 1（运行于Pod1内）通过http://service2:8080调用Service2失败，但使用HttpClient调用google.com可正常获取响应，排除.NET代码逻辑问题。
• 成功场景：通过Ingress控制器可实现API1与API2的连接；登录Pod1执行curl http://service2:8080可成功获取Pod2的响应。

排查解决思路 #

• 检查.NET应用的DNS解析行为

  • 在.NET代码中添加日志，调用Dns.GetHostEntryAsync("service2")并输出解析结果，确认是否能获取到Service2的ClusterIP。
  • 调整.NET Core的DNS缓存设置，比如将ServicePointManager.DnsRefreshTimeout设为30秒，或在HttpClientHandler中禁用DNS缓存：

    var handler = new HttpClientHandler
    {
        UseCookies = false,
        AutomaticDecompression = DecompressionMethods.GZip | DecompressionMethods.Deflate
    };
    handler.ServicePointManager.DnsRefreshTimeout = 30000;
    var client = new HttpClient(handler);
    

  • 查看Pod1内的/etc/resolv.conf，确认nameserver指向K8s集群DNS服务（通常为10.96.0.10）。

• 验证Pod的DNS访问权限

  • 在Pod1内执行nslookup service2，确认是否能正常解析出Service2的ClusterIP，对比curl的结果差异。
  • 测试Pod1到K8s DNS服务的连通性：执行telnet <dns-cluster-ip> 53或nc -zv <dns-cluster-ip> 53（若容器内有对应工具），确认53端口（UDP/TCP）可访问。
  • 检查是否存在NetworkPolicy限制Pod1访问DNS服务，确保允许Pod1与kube-system命名空间下的DNS Pod通信。

• 检查Service与端点配置

  • 执行kubectl get endpoints service2，确认端点列表中存在正常运行的Pod2实例。
  • 验证Service2的spec.selector是否与Pod2的标签完全匹配，spec.ports[].port是否为8080，targetPort是否对应Pod2的监听端口。
  • 尝试直接用Service2的ClusterIP调用（如http://<cluster-ip>:8080），若.NET应用能成功，则问题确实出在DNS解析环节；若仍失败，需排查网络连通性问题。

• 检查容器镜像与DNS策略

  • 通过kubectl describe pod <pod1-name>查看容器的dnsPolicy配置，确认其为ClusterFirst（K8s默认值），若设置为Default会使用宿主机DNS，无法解析内部Service。
  • 检查容器镜像是否自定义了/etc/resolv.conf，或内置了代理配置导致DNS请求被拦截。

• 排查K8s DNS服务状态

  • 执行kubectl get pods -n kube-system，确认coredns（或kube-dns）Pod处于Running状态且无重启记录。
  • 查看DNS服务日志：kubectl logs -n kube-system <coredns-pod-name>，搜索是否存在与service2相关的解析错误。
  • 测试集群内其他Pod对service2的解析情况，若其他Pod正常，则问题聚焦在Pod1或其所在节点的网络配置。

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