Minikube中CoreDNS无法跨Namespace解析服务域名问题

从你描述的症状来看，核心问题是跨Namespace的完整Service域名被错误解析到外部地址，而Pod/Service IP、同Namespace内Pod的域名访问正常，这大概率和DNS解析的搜索域配置、CoreDNS的域名匹配逻辑有关。下面是一步步的排查和解决方案：

一、先确认CoreDNS是否正确处理Cluster内部域名请求 #

首先要验证CoreDNS本身能不能正确解析目标Service的域名：
在任意Pod中执行以下命令，直接指定CoreDNS的IP（10.96.0.10）来查询完整域名：

nslookup blockchain-influxdb-local.influx.svc.cluster.local 10.96.0.10

• 如果返回正确的Service ClusterIP：说明CoreDNS的kubernetes插件工作正常，问题出在Pod的DNS搜索域或resolv.conf配置上。
• 如果仍然返回外部地址nc-ass-vip.sdv.fr：说明CoreDNS没有正确识别该域为集群内部域名，需要检查CoreDNS的配置和权限。

二、针对CoreDNS的排查（如果第一步返回异常） #

1. 查看CoreDNS Pod日志，检查是否有访问Kubernetes API的错误：

kubectl logs -n kube-system $(kubectl get pods -n kube-system -l k8s-app=kube-dns -o name)

如果日志中出现类似Failed to list services或权限相关的错误，说明CoreDNS Pod没有足够权限访问API Server获取Service/Endpoint数据，需要确认kube-system下的coredns ServiceAccount是否绑定了正确的ClusterRole。

2. 验证CoreDNS的kubernetes插件配置：
   你的Corefile中kubernetes块配置是正确的，但可以尝试添加debug日志来跟踪域名处理流程：
   修改CoreDNS ConfigMap：

apiVersion: v1
data:
  Corefile: |
    .:53 {
        errors
        debug # 添加这行开启调试日志
        health {
           lameduck 5s
        }
        ready
        kubernetes cluster.local in-addr.arpa ip6.arpa {
           pods insecure
           fallthrough in-addr.arpa ip6.arpa
           ttl 30
        }
        prometheus :9153
        forward . /etc/resolv.conf
        cache 30
        loop
        reload
        loadbalance
    }

然后重启CoreDNS Pod：

kubectl rollout restart deployment coredns -n kube-system

再次查询域名，查看日志中是否有该域名的处理记录，确认是否进入了kubernetes插件处理逻辑。

三、针对Pod DNS搜索域的排查（如果第一步返回正确） #

你的Pod的/etc/resolv.conf中有两个关键配置：

• search influx.svc.cluster.local svc.cluster.local cluster.local numericable.fr
• options ndots:5

根据DNS解析规则，当查询的域名包含的点数量小于ndots值时，系统会依次尝试将搜索域追加到域名末尾进行解析。你的完整域名blockchain-influxdb-local.influx.svc.cluster.local包含4个点，而ndots设置为5，所以系统会认为这不是一个绝对域名，尝试追加搜索域（比如numericable.fr），变成blockchain-influxdb-local.influx.svc.cluster.local.numericable.fr，而外部DNS恰好有匹配的记录，导致解析到外部地址。

解决方法： #

1. 临时测试：在Pod中手动修改ndots值，或者使用绝对域名（末尾加.）来查询：

curl blockchain-influxdb-local.influx.svc.cluster.local.

末尾的.会告诉DNS这是绝对域名，不会使用搜索域。如果能正常访问，说明就是ndots的问题。

2. 永久解决：
   • 方法一：修改Pod的DNS配置，在Pod的YAML中添加dnsConfig：

     spec:
       dnsConfig:
         options:
           - name: ndots
             value: "4"
     

     这样4个点的域名会被当作绝对域名，直接解析，不会追加搜索域。
   • 方法二：修改Minikube的集群默认DNS配置，调整ndots值。可以通过启动Minikube时添加参数：

     minikube start --kubelet-arg="cluster-dns=10.96.0.10" --kubelet-arg="cluster-domain=cluster.local" --kubelet-arg="resolv-conf=/run/systemd/resolve/resolv.conf" --kubelet-arg="dns-ndots=4"
     

     或者修改kubelet的配置文件，调整默认的ndots值。

四、额外验证：确认Service存在且配置正确 #

最后再确认目标Service是否存在，并且ClusterIP正确：

kubectl get svc blockchain-influxdb-local -n influx

检查输出中的ClusterIP是否和你手动访问的一致，同时确认Service的selector是否正确匹配Pod的标签，保证Endpoint是正常的。

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