Kubernetes 1.6新特性系列|在Kubernetes里配置私有DNS区域和上游服务器

许多用户都试着将现有的域名区域(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

原文链接: http://blog.kubernetes.io/2017/04/configuring-private-dns-zones-upstream-nameservers-kubernetes.html