在 Kubernetes 中配置私有 DNS 区域和上游 Nameserver

编者注：本文是关于 Kubernetes 1.6 新特性的系列深度文章的一部分

许多用户拥有现有的域名区域，他们希望将其集成到他们的 Kubernetes DNS 命名空间中。例如，混合云用户可能希望在集群内解析其内部“.corp”域地址。其他用户可能拥有一个由非 Kubernetes 服务发现系统（如 Consul）填充的区域。我们很高兴地宣布，在Kubernetes 1.6中，kube-dns 添加了对可配置私有 DNS 区域（通常称为“stub domain”）和外部上游 DNS nameserver 的支持。在这篇博文中，我们将介绍如何配置和使用此功能。

默认查找流程

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）将转发到从节点继承的上游 nameserver。在此功能之前，通常通过将上游 DNS 替换为自定义解析器来引入 stub domain。然而，这导致自定义解析器本身成为 DNS 解析的关键路径，其中可伸缩性和可用性问题可能导致集群失去 DNS 功能。此功能允许用户引入自定义解析，而无需接管整个解析路径。

自定义 DNS 流程

从 Kubernetes 1.6 开始，集群管理员可以通过为 kube-dns 提供一个 ConfigMap 来指定自定义 stub domain 和上游 nameserver。例如，下面的配置插入一个 stub domain 和两个上游 nameserver。如指定的那样，带有“.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。带 stub domain 后缀（例如；“.acme.local”）的名称将被发送到配置的自定义解析器。最后，不匹配任何这些后缀的请求将转发到上游 DNS。

下表显示了示例域名以及这些域名查询的目标服务器

ConfigMap 配置注意事项

• stubDomains（可选）

  • 格式：一个 JSON map，使用 DNS 后缀作为键（例如；“acme.local”），值是一个包含 DNS IP 数组的 JSON 数组。
  • 注意：目标 nameserver 本身可以是 Kubernetes service。例如，您可以运行自己的 dnsmasq 实例，将自定义 DNS 名称导出到 ClusterDNS 命名空间。

• upstreamNameservers（可选）

  • 格式：一个 DNS IP 数组的 JSON 数组。
  • 注意：如果指定，则指定的值将替换默认情况下从节点 /etc/resolv.conf 获取的 nameserver。
  • 限制：最多可指定三个上游 nameserver

示例 #1：添加 Consul DNS Stub Domain

在此示例中，用户希望将 Consul DNS 服务发现系统与 kube-dns 集成。consul 域服务器位于 10.150.0.1，所有 consul 名称都带有“.consul.local”后缀。要配置 Kubernetes，集群管理员只需创建一个 ConfigMap 对象，如下所示。注意：在此示例中，集群管理员不希望覆盖节点的上游 nameserver，因此他们无需指定可选的 upstreamNameservers 字段。

apiVersion: v1

kind: ConfigMap

metadata:

  name: kube-dns

  namespace: kube-system

data:

  stubDomains: |

    {“consul.local”: [“10.150.0.1”]}

示例 #2：替换上游 Nameserver

在此示例中，集群管理员希望明确强制所有非集群 DNS 查找通过其位于 172.16.0.1 的 nameserver 进行。这也很容易实现；他们只需创建一个带有 upstreamNameservers 字段的 ConfigMap，指定所需的 nameserver。

apiVersion: v1

kind: ConfigMap

metadata:

  name: kube-dns

  namespace: kube-system

data:

  upstreamNameservers: |

    [“172.16.0.1”]




**Get involved**  

If you’d like to contribute or simply help provide feedback and drive the roadmap, [join our community](https://github.com/kubernetes/community#kubernetes-community). Specifically for network related conversations participate though one of these channels:  

- Chat with us on the Kubernetes [Slack network channel](https://kubernetes.slack.com/messages/sig-network/)
- Join our Special Interest Group, [SIG-Network](https://github.com/kubernetes/community/wiki/SIG-Network), which meets on Tuesdays at 14:00 PT
Thanks for your support and contributions. Read more in-depth posts on what's new in Kubernetes 1.6 [here](https://kubernetes.ac.cn/blog/2017/03/five-days-of-kubernetes-1-6).


- Post questions (or answer questions) on [Stack Overflow](http://stackoverflow.com/questions/tagged/kubernetes)
- Join the community portal for advocates on [K8sPort](http://k8sport.org/)
- Get involved with the Kubernetes project on [GitHub](https://github.com/kubernetes/kubernetes)
- Follow us on Twitter [@Kubernetesio](https://twitter.com/kubernetesio) for latest updates
- Connect with the community on [Slack](http://slack.k8s.io/)
- [Download](http://get.k8s.io/) Kubernetes

• ←上一篇
• 下一篇→