DNS云学堂 | DNS老司机带你探秘k8s中的CoreDNS

ZDNS

2020-07-15

1、引言

由谷歌开源推出的k8s，作为现在容器编排领域的事实标准，已经被各大云计算厂商及互联网公司广泛推崇使用。熟悉k8s的小伙伴们可能都知道k8s中有一个很重要的DNS组件，叫CoreDNS，作为一个专注于DNS领域干货分享的栏目，我们不禁要问这个CoreDNS有什么特殊的地方吗，与我们日常使用的DNS又有什么区别呢？今天，就让我们用几分钟时间来了解认识一下k8s中的这个CoreDNS。enjoy：

2、磨刀不误砍柴工，先了解几个概念

因为本文需要涉及到一些k8s相关的内容，所以我们先认识几个新名词：

· Pod：k8s中容器的最小管理单位，一个Pod中可包含多个容器，这些容器共享网络空间和计算资源等，Pod的特点是变化性，所以没有固定的网络名称标识；

· Service：k8s内部服务资源对象，作为一组功能相同的容器的访问入口，提供多容器间流量负载均衡的作用；

· StatefulSet：k8s有状态服务资源对象，特点是会为其下的每一个Pod创建稳定的网络名称标识；

· Ingress：k8s对外服务的资源对象，简单的7层负载均衡策略，通常会通过域名或URL的方式区分不同后端Service的流量；

3、k8s为何对CoreDNS情有独钟？

经过之前几篇文章的学习，我们已经对DNS有初步的认识了，知道有权威DNS和递归DNS的区别，那么这个CoreDNS算是权威还是递归呢？它又有什么特异功能能被k8s相中呢？带着这两个疑问，我们先去官网一睹它的真容。

CoreDNS的官网长这个样子，大概意思呢是说：

· 第一、CoreDNS是一个用Go语言编写的DNS服务器软件；

· 第二、CoreDNS支持非常多的插件，灵活度很高，配置和使用也非常的简单；

· 第三、最最重要的一点来了，它集成了k8s插件，可以作为k8s的服务发现机制；

我们终于知道了CoreDNS被k8s青睐的原因，那就是最后这个插件为k8s增添的服务发现功能。可能有小伙伴又要问了，这个服务发现是个什么东东，而且听起来还很高大上的样子？

因为时间原因，我们就不玩欲擒故纵的游戏了，直接贴答案：

在k8s中，CoreDNS会监听3类k8s资源的事件，分别是Service、StatefulSet和Pod这3类资源，并会为这三类资源自动创建（更新/删除）相应的域名记录，k8s中各服务间可以直接通过服务域名的方式进行通信。

3.1 Service

CoreDNS会为Service创建3种域名记录：A或Cname、SRV、PTR

A/Cname的域名规则：

<svc-name>.<namespace-name>.svc.<cluster-domain>

举个例子，假如我们有一个域名后缀为cluster.local的k8s集群，并且我们在其中的test命名空间下创建了一个名为hello的Service，那么这个Service的域名为：

hello.test.svc.cluster.local

让我们来实际看一下CoreDNS会怎样解析这个域名吧

· 普通Service

（对于普通Service，CoreDNS会以A记录类型返回该Service的ServiceIP）

· Headless Service

（CoreDNS会直接将该Service的所有Ready状态的Pod IP以A记录方式返回）

· External Service

（以Cname+A的方式返回Service最终指向的外部服务的域名A记录）

SRV记录的域名命名规则：

<port-name>.<port-protocol>.<svc-name>.<namespace-name>.svc.<cluster-domain>

以上边创建normal-service验证一下：

PTR记录的域名记录规则：

<reverse-ip>.in-addr.arpa. ttl IN PTR <svc-FQDN>

同样，让我们实际解析验证一下：

3.2 StatefulSet

对于StatefulSet，CoreDNS会为其包含的每一个Pod创建A记录，域名命名规则如下：

<pod-name>.<svc-name>.<namespace-name>.svc.<cluster-domain>

我们的实际测试结果：

3.3 Pod

CoreDNS只会为一种Pod创建域名记录，记录类型为A：Pod配置了hostName和subdomain，并且该Pod的subdomain与该Pod关联的Service名称相同时，域名命名规则与StatefulSet的Pod类似。

<host-name>.<svc-name>.<namespace-name>.svc.<cluster-domain>

我们要创建的Pod定义如下：

用命令解析一下这个Pod的域名

看到这里小伙伴们可能已经想到了，所谓CoreDNS为k8s提供的服务发现功能，其实就是CoreDNS会自动维护3类资源的域名记录，而k8s中的数量繁多的微服务之间正是通过这些域名来相互通信访问的，这就是CoreDNS在k8s中的核心功能。

看到这里，一些DNS大拿、专家们可能已经认识到了，CoreDNS的这部分功能，和企业内网权威DNS是类似的，区别之处是CoreDNS提供了配置维护的自动化插件。

但是只有权威怎么能行呢，k8s中的容器如果想要访问一个外部的应用怎么办？所以CoreDNS作为一个标准的DNS Server，还提供了基本的递归功能，可能因为在k8s中递归需求占比比较小，所以CoreDNS只提供了最基本的缓存和转发功能，实际中还需要搭配上游递归DNS才可以。

4、自建DNS中k8s的最佳尝鲜方式

聊到这里，我们可以回答前边的第一个问题了，CoreDNS是权威DNS还是递归DNS？答案是：既是权威又是递归，当然它与我们日常所接触到的DNS还是有一些不同的：

· 相较于普通权威DNS特殊在CoreDNS会主动监听k8s中相关资源对象的变化，并根据监听到的资源变化情况自动创建、更新、删除相应的域名记录，无需人为参与。

· 相较于普通递归DNS，区别点在于CoreDNS仅支持最基本的缓存和转发功能，不具备完整的递归解析能力，需要配置上游转发DNS来实现对k8s集群外域名的解析。

俗话说学而不思则罔，那么我们也来“思”一下，k8s中还有什么地方在使用域名吗？如果我有自建的DNS，又想尝k8s的鲜，怎样搭配才合适呢？

· Ingress域名的自动化管理

作为k8s对外服务的资源对象，Ingress的域名一般需要在用户权威DNS上配置对应的解析记录，如果希望创建Ingress后能够自动关联权威DNS上的相关域名记录，一般需要用户自行开发相关的k8s插件，如果您的权威DNS是使用ZDNS-T系列硬件或ZDNS CLOUD云服务托管解析，那么通过我们简单易用的Restful API可以让您的插件开发工作事半功倍。

· 自建递归DNS作为CoreDNS的上游转发DNS

相较于运营商Local DNS和公共DNS，将自建递归DNS作为CoreDNS的上游转发DNS有两个好处：

第一、 CoreDNS在开启autopath功能后，转发请求比例很高，如果使用运营商Local DNS作为CoreDNS的上游DNS，可能会触发运营商Local DNS（或公共DNS）的限速策略，进而导致集群内服务异常。（注：autopath是CoreDNS针对k8s场景中DNS解析的一个优化插件，可以提高k8s中容器的解析效率）

第二、相较于运营商Local DNS和公共DNS，自建DNS的策略灵活度更高，可以更好的满足用户的一些特定DNS解析需求，例如可以在自建DNS上过滤非法域名解析请求。

5、结束语

看到这里，你是不是还有好多问题想问，比如还想知道k8s里DNS解析的具体过程，CoreDNS的转发配置怎么修改，k8s中有没有DNS方面的坑？不要着急，我们将持续带来相关干货内容的分享，记得多多关注哦。

声明：此篇为ZDNS-国家工程研究中心原创文章，转载请标明出处链接： https://m.zdns.cn/news/102.html

阅读4247