我创建了一个指向外部服务的ExternalName类型Service，配置如下：

apiVersion: v1
kind: Service
metadata:
  name: test
spec:
  type: ExternalName
  externalName: google.com

但当我执行DNS查询时，无法得到有效结果：

# dig test.development.svc.cluster.local.
; <<>> DiG 9.9.5-9+deb8u15-Debian <<>> test.development.svc.cluster.local.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 58159
;; ...

排查思路与解决方法 #

帮你梳理几个最可能导致这个问题的原因，以及对应的验证和修复步骤：

• 确认Service的命名空间匹配
  你查询的域名是test.development.svc.cluster.local，这意味着Service需要部署在development命名空间下。先检查你的Service实际所在的命名空间：

  kubectl get svc test -o jsonpath='{.metadata.namespace}'
  

  如果返回的不是development，那你需要修改查询域名（比如默认命名空间的话是test.default.svc.cluster.local），或者把Service迁移到development命名空间。

• 检查CoreDNS/KubeDNS的配置
  集群的DNS组件（现在大多是CoreDNS）需要正确处理ExternalName类型的Service。查看CoreDNS的ConfigMap：

  kubectl get configmap coredns -n kube-system -o yaml
  

  找到Corefile里的kubernetes块，确保没有添加externalname: false这样的禁用配置——默认情况下这个参数是开启的，如果被手动关闭了，就会导致ExternalName Service无法被解析。如果有这个配置，删掉它然后重启CoreDNS：

  kubectl rollout restart deployment coredns -n kube-system
  

• 在集群内部测试解析
  集群外部的dig查询可能受限于本地DNS配置，无法正确访问集群内部的DNS服务。建议在集群内启动一个测试Pod来验证：

  kubectl run -it --rm --image=busybox:1.28 dns-test -- nslookup test.development.svc.cluster.local
  

  如果这个命令能返回google.com的IP，说明集群内部解析正常，问题出在外部访问的DNS配置上；如果还是不行，再回到前面的步骤排查CoreDNS和Service配置。

• 清除DNS缓存
  有时候DNS组件的缓存会导致解析异常，重启CoreDNS Pod可以强制刷新缓存：

  kubectl rollout restart deployment coredns -n kube-system
  

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