自定义 DNS 流程

从 Kubernetes 1.6 开始，集群管理员能够利用 ConfigMap 指定自定义的存根域以及上级 NameServer。下文的配置包含一个存根域和两个上级域名服务器。对域名后缀为.my.io的查询会被发送到地址为 10.100.100.14 的 DNS 服务。另外会把 Google 公共 DNS 作为上级服务器。注意本节末尾对 ConfigMap 中的数据格式进行的解释。

apiVersion: v1
kind: ConfigMap
metadata:
  name: kube-dns
  namespace: kube-system
data:
  stubDomains: |
    {"my.io": ["10.100.100.14"]}
  upstreamNameservers: |
    ["8.8.8.8", "8.8.4.4"]

下图显示了配置中所指示的 DNS 查询过程。当dnsPolicy设置为ClusterFirst时，DNS 查询首先被发送到 kube-dns 的 DNS 缓存层。从这里开始检查域名后缀，然后发送到指定的 DNS。在本例中，集群后缀的域名（.cluster.local），被发送到 kube-dns，最后不符合上面后缀的其他查询被转发到上级 DNS 去进行解析。

下文表格用来说明域名解析的过程：

ConfigMap 配置说明

stubDomains (可选)

格式：一个 JSON 编码的 Map 格式，其 Key 为 DNS 后缀（也就是my.io），值是一个 JSON 数组，代表一组 DNS IP。
注意：目标域名服务器也可以是 Kuernetes 服务。例如可以用 dnsmasq 把自定义 DNS 导出到 ClusterDNS 的命名空间中。

upstreamNameservers

格式：一个 DNS IP 组成的 JSON 数组。
注意：如果指定了这个值，那么从节点的 /etc/resolv.conf 继承过来的值就会被覆盖。
限制：最多可以指定三个。
例 1：添加一个 Consul DNS 存根域
这个例子中，用户希望把 Consul DNS 服务集成到 kube-dns。Consul 服务位于10.150.0.1，所有的 consul 命名后缀都是.consul.local。Kubernetes 管理员简单的创建一个ConfigMap对象就可以完成。注意：本例中管理员不想覆盖节点的上级 DNS 定义，所以不需要指定upstreamNameservers：

apiVersion: v1
kind: ConfigMap
metadata:
  name: kube-dns
  namespace: kube-system
data:
  stubDomains: |
    {"my.io": "10.100.100.14"}

例 2：替换上级 Nameserver
这个例子中，集群管理员希望所有的集群外 DNS 查询由172.16.0.1的服务来完成，同样的用一个 ConfigMap 完成：

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