本地K8s部署ASP.NET+MongoDB报30000ms连接选择超时异常

从错误栈的System.Net.Dns.InternalGetHostByName调用失败、连接目标显示Unspecified/mongo:27017可以直接定位：ASP.NET应用Pod无法解析MongoDB服务的域名。
docker-compose部署时同网络下的服务会自动注册短域名，直接写服务名mongo就能连通，但Kubernetes的域名解析规则和docker-compose不通用，直接复用compose里的mongo:27017连接地址会触发解析失败，和MongoDB StatefulSet本身运行状态无关——毕竟你已经用Mongo-Express验证过Mongo服务正常。

• 核对MongoDB Service的基础信息
  执行kubectl get svc -A查看MongoDB对应Service的名称、所在命名空间：
  • 同命名空间部署场景：连接地址里的域名必须和Mongo Service名完全一致，比如Service叫mongodb-svc，就不能写mongo，要写成mongodb-svc:27017
  • 跨命名空间部署场景：必须使用K8s全限定域名（FQDN），格式为<mongo-service-name>.<mongo所在命名空间>.svc.cluster.local:27017，例如Mongo在db命名空间、Service名为mongodb，连接地址就写mongodb.db.svc.cluster.local:27017
• 验证Pod内DNS解析有效性
  进入正在运行的ASP.NET应用Pod执行解析测试，确认能拿到Mongo Service的ClusterIP：

  kubectl exec -it <dotnet应用的Pod名称> -- nslookup <连接串里配置的Mongo域名>
  

  如果命令返回域名不存在，回头检查Service名、命名空间配置是否写错；如果能正常返回IP，说明解析链路没问题。
• 核对连接字符串配置
  把ConfigMap里存储的MongoDB连接串改成上述符合K8s规则的地址，重启ASP.NET应用的Deployment让新配置生效即可。
• 改完仍报错的补充排查项
  • 检查MongoDB Service的端口配置：确认Service暴露的端口是27017，targetPort正确指向Mongo Pod的27017监听端口，没有端口映射错误
  • 检查集群NetworkPolicy规则：确认没有策略拦截ASP.NET应用所在命名空间到MongoDB所在命名空间的27017端口出站流量
  • 检查ASP.NET应用镜像：确认镜像内没有硬编码修改/etc/resolv.conf覆盖K8s自动注入的集群DNS配置

不要直接复用docker-compose里的服务名连接配置，这是从compose迁移到K8s最常见的配置错误。

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