许多用户他们想要集成domain name zones（现有域名区域）到Kubernetes DNS 命名空间。例如，混合云用户可能希望在群集内解析其内部“.corp”域地址。其他用户可能具有由非Kubernetes服务发现系统（如Consul）组成的区域。我们很高兴地宣布，在Kubernetes 1.6中，kube-dns增加了对可配置的私有DNS区域（通常称为“存根域”）和外部上游DNS名称服务器的支持。在这篇博 文中，我们将介绍如何配置和使用此功能。
Default lookup flow
![0e67af4d83f79e692bc39c926a04e1d2853f693b]()
Kubernetes目前支持使用dnsPolicy标志在每个pod上指定的两个DNS策略：
如果未明确指定dnsPolicy，则默认使用“ClusterFirst”：
- 果将dnsPolicy设置为“Default”，则名称解析配置将从运行pod的node节点继承。注意：此功能不能与dnsPolicy一起使用：“Default”。
- 如果将dnsPolicy设置为“ClusterFirst”，则DNS查询将发送到kube-dns服务。对于以配置的集群域后缀为根的域（上面示例中以“.cluster.local”结尾的任何地址）的查询将由kube-dns服务应答。所有其他查询（例如，www.kubernetes.io）将被转发到从节点继承的上游名称服务器。在此功能之前，通常通过使用自定义解析程序替换上游DNS来引入存根域。但是，这导致自定义解析程序本身成为DNS解析的关键路径，其中可伸缩性和可用性问题可能导致群集丢失DNS功能。此特性允许用户在不接管整个解析路径的情况下引入自定义解析。
Customizing the DNS Flow
从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。
![0550b8b911f86e5782fc08d2a9917f0ecd499926]()
下面是一个示例域名和这些域名的查询目的地的表格：
| 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) |
ConfigMap Configuration Notes
示例 #1: 增加 Consul DNS Stub Domain
在该示例中，用户具有他们希望与kube-dns集成的Consul DNS服务发现系统。 consul域服务器位于10.150.0.1，所有consul名称的后缀为“.consul.local”。要配置Kubernetes，集群管理员只需创建一个ConfigMap对象，如下所示。注意：在此示例中，集群管理员不希望覆盖节点的上游名称服务器，因此他们不需要指定可选的upstreamNameservers字段。
apiVersion: v1 kind: ConfigMap metadata: name: kube-dns namespace: kube-system data: stubDomains: | {“consul.local”: [“10.150.0.1”]}
示例 #2: 替换Upstream Nameservers
在此示例中，集群管理员希望显式强制所有非集群DNS查找在172.16.0.1处通过自己的名称服务器。再次，这很容易实现;他们只需要使用upstreamNameservers字段创建一个ConfigMap，指定所需的名称服务器。
apiVersion: v1 kind: ConfigMap metadata: name: kube-dns namespace: kube-system data: upstreamNameservers: | [“172.16.0.1”]
总结
上文是kube-dns实现的解决方案。而stubDomains 和 upstreamNameservers 在coredns 中 通过 proxy 插件实现。coredns是接下来重点研究的东西。
本文转自中文社区-k8s与DNS--配置私有DNS Zones和Upstream Nameservers
