新闻详情

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

39
发表时间:2020-07-15 10:27作者:ZDNS

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方面的坑?不要着急,我们将持续带来相关干货内容的分享,记得多多关注哦。


_______________
_______________
_______________
_______________
友情互联:
___________________________________________________________________________________________________________________
邮箱:web@zdns.cn
7*24小时客户服务
咨询电话:400-6688-876
标签:
请输入要描述的内容进行内容补充 请输入要描述的内容
01
03
请输入要描述的内容进行内容补充 请输入要描述的内容
___________________________________________________________________________________________________________________
京ICP备15027496号-3 | 京公网安备11010802021115号 | All rights reserved
扫码了解更多详情
DNS 云解析