许多用户都试着将现有的域名区域(domain name zones)集成到Kubernetes的DNS命名空间里。例如混合云用户可能想在集群里能解析他们内部的”.corp”域名,其他一些用户可能希望使用由其他的服务发现系统(比如Consul)管理的区域。




1

默认查找流 



Kubernetes目前支持两种的DNS策略,通过将Pod的dnsPolicy字段设置为”Default”或”ClusterFirst”来实现。如果dnsPolicy没有显式指明,将会开启”ClusterFirst”策略。

  • 如果dnsPolicy设置为”Default”,那么名称解析的配置会从该Pod所在的节点上继承过来。注意:这个特性不能跟dnsPolicy:”Default”关联使用
  • 如果dnsPolicy设置为”ClusterFirst”,那么DNS查询会被发送到kube-dns服务。对于含有集群域名后缀(上面例子中任何以”.cluster.local”结尾的地址)的根域名,将有kube-dns服务进行回应。所有其他的查询(例如,www.kubernetes.io)会被转发到继承自该节点的上游名称服务器。

在此之前,通常会使用自定义的解析器来替换上游DNS,最后得到存根域。然而,这会导致自定义的解析器自身变成DNS解析的关键路径,这样的话,扩展性和可用性的问题可能会导致集群丢失DNS功能。这个特性允许用户引入自定义解析而无需得到全部的解析路径。



2

定制DNS流 

从Kubernetes 1.6开始,集群管理员可以通过为kube-dns提供ConfigMap来实现对存根域以及上游名称服务器的自定义指定。例如,下面的配置插入了一个单独的存根域和两个上游名称服务器。如下所示,带有”.acme.local”后缀的DNS请求会被转发到监听地址为1.2.3.4的DNS服务器。另外,Google Public DNS也支持上游查询。想了解这些数据格式请参考下节的ConfigMap配置说明。

apiVersion: v1
kind: ConfigMap
metadata:
name: kube-dns
namespace: kube-system
data:
stubDomains: |
{“acme.local”: [“1.2.3.4”]}
upstreamNameservers: |
[“8.8.8.8”, “8.8.4.4”]

下面的图展示了上述特定配置下的DNS查询过程。通过将dnsPolicy设置为”ClusterFirst”,每个DNS查询请求首先会被发送到kube-dns的DNS缓存层。从此会检查请求的后缀,然后进一步发送到合适的DNS服务器。在这个例子里,带有集群后缀(例如:”.cluster.local”)的请求会被发往kube-dns。拥有存根域后缀的名称(例如:”.acme.local”)将会被发送到可配置的解析器去。最后,不满足任何这些后缀的请求将会被发送到上游DNS里。


下面是一张示例域名和针对这些域名查询目标地的表格:

Domain name

Server answering the query

kubernetes.default.svc.cluster.local

kube-dns

foo.acme.local

custom DNS (1.2.3.4)

widget.com

upstream DNS (one of 8.8.8.8, 8.8.4.4)

3

ConfigMap配置说明 

  • stubDomains(可选)
  • 格式: 一个使用DNS后缀作为key(例如:”acme.local”)和一个由DNS IPs构成的JSON数组的Value的JSON map
  • 注意: 目标名称服务器可能本身是一个Kubernetes的服务。比如,你可以运行你自己的dnsmasq来把自定义的DNS名称导出到ClusterDNS 命名空间里
  • upstreamNameservers(可选)
  • 格式:一个DNS IP的JSON数组
  • 注意:如果指定了,这些值将会替换那些从节点/etc/resolv.conf里得到的默认值
  • 限制:最多能指定三个上游服务器

例1:添加一个Consul DNS Stub Domain

在这个例子里,用户将把Consul DNS服务发现系统与kube-dns进行了集成。Consul的域名服务器为10.150.0.1,所有的Consul域名都拥有后缀”.consul.local”。为了配置Kubernetes,集群管理员只需创建一个ConfigMap对象(如下)。注意,在这个例子里,集群管理员并不希望覆盖节点的上游名称服务器,所以他们不需要指定那个可选的upstreamNameserver域。

apiVersion: v1
kind: ConfigMap
metadata:
name: kube-dns
namespace: kube-system
data:
stubDomains: |
{“consul.local”: [“10.150.0.1”]}

例2:替换上游名称服务器

在这个例子里,集群管理员想要显式强制所有非集群DNS的查找都经过他们自己在172.16.0.1的名称服务器。这还是很容易就可以完成。他们只需要创建一个带有upstreamNameservers域的ConfigMap,指定了期望的名称服务器即可。

apiVersion: v1
kind: ConfigMap
metadata:
name: kube-dns
namespace: kube-system
data:
upstreamNameservers: |
[“172.16.0.1”]


4

参与社区

如果你想要做一点小小的贡献,或者只是提供一些反馈和确定路线。加入社区吧。对于网络相关的会话请参与这些频道:

  • Kubernetes Slack上的网络频道
  • 加入我们的特别兴趣小组:SIG-Network,每周二14点(太平洋时间)在线会议(北京时间周二06:00)

感谢大家的支持和贡献,点击这里阅读其他的Kubernetes 1.6深度解析文章。

  • 在StackOverflow上提问
  • 加入K8sPort
  • 访问Github
  • 关注Twitter
  • 参与Slack
  • 下载Kubernetes