CoreDNS是一款使用Go语言实现的专为云原生应用而生的DNS服务器。本文介绍CoreDNS在特定实际场景下的一种进阶使用实践，也许能为其他也在使用CoreDNS做服务发现的同学提供一些启发和思考。

背景介绍

在我们的实际生产环境中，往往会将关键服务部署在各自独立的k8s集群中，一方面是为了减小故障半径，另一方面也是为了资源最优分配（不同业务对机型、规格要求不同，比如计算型服务、存储型服务对机型有各自比较严格的要求才能实现机器资源的最佳利用）。

然而这些服务之间往往又不是逻辑独立的，相互之间存在依赖关系。比如服务A部署在k8s集群1中，服务B部署在k8s集群2中，而服务A、B之间存在依赖关系，服务A需要调用B提供的接口实现某些功能。这个时候就需要服务A能够通过某种方式能直接访问到服务B。

在我们的生产环境中存在大量的内部服务，相互之间有错综复杂的调用关系（数百个内部服务，分布在数十个不同的k8s集群上）。为了应对这些内部服务之间的服务发现需求，在我们的生产环境中借助CoreDNS来实现跨k8s集群的service域名解析。

使用条件

使用CoreDNS来实现跨集群的service域名解析并达到服务发现的效果，是需要有一些前提条件的。

1. 跨集群POD IP可直通。这也就意味着，在k8s集群1上的业务POD A中，只要获取到k8s集群2上业务POD B的POD IP，就可以通过这个POD IP进行直接通信。这就要求容器网络插件能提供支持（比如Cilium就能实现这种跨集群POD直通），在我们内部是自研了一套网络插件，实现了跨集群POD IP直通，具备了本文方案的基础。

2. 跨集群服务使用headless service的FQDN域名。由于本质上跨集群的服务通信是依赖于POD IP，即最终要解析得到对端服务的POD IP，这就意味着我们可以通过headless service的FQDN作为服务域名。一个完整的headless service格式为：
   {service_name}.{namespace}.svc.{cluster_domain}

3. 每个k8s集群都有唯一的cluster domain。有了多集群中之后，为了唯一标识一个k8s集群，我们在创建k8s集群的时候就为其指定了独一无二的cluster domain，即/etc/kubernetes/kubelet-config.yaml中的clusterDomain字段（该字段如果不设置的话，默认为cluster.local）。指定了该字段之后，在创建dnsPolicy为ClusterFirst/ClusterFirstWithHostNet等业务POD时，POD的/etcd/resolv.conf中search域就会带上该cluster domain。如果创建k8s集群时没有指定的话，search域默认为：

search {ns}.svc.cluster.local svc.cluster.local cluster.local

有了上述3个前提之后，我们就可以设计CoreDNS跨集群service解析的方案了。

实现方案

在我们的方案中，主要利用CoreDNS forward插件能力。具体来说，将每个k8s集群独一无二的cluster domain作为Corefile的一个zone，然后CoreDNS在解析FQDN格式的service时，匹配到某个zone（cluster domain）时，就请求forward到对应的k8s集群的CoreDNS。

现在以两个k8s集群（cluster domain配置分别为cluster1.local、cluster2.local）为例说明实施步骤：

1. 分别在两个k8s集群中为CoreDNS创建NodePort service（默认端口范围为30000-32768，这里选择的端口为32710）：
   
2. 分别配置两个k8s集群中Corefile（一般为kube-system命名空间下的coredns configmap）：
   
3. 等待CoreDNS自动reload Corefile之后，即可跨集群解析headless service了。