在 Kubernetes 中配置私有 DNS 区域和上游域名服务器

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

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

默认查找流程

Kubernetes 目前支持两种 DNS 策略，通过 dnsPolicy 标志在每个 Pod 基础上指定：“Default”和“ClusterFirst”。如果未明确指定 dnsPolicy，则使用“ClusterFirst”

• 如果 dnsPolicy 设置为“Default”，则名称解析配置将从 Pod 运行的节点继承。注意：此功能不能与 dnsPolicy: “Default” 结合使用。
• 如果 dnsPolicy 设置为“ClusterFirst”，则 DNS 查询将发送到 kube-dns 服务。对配置的集群域后缀（在上述示例中以“.cluster.local”结尾的任何地址）根目录下的域的查询将由 kube-dns 服务应答。所有其他查询（例如，www.kubernetes.io）将转发到从节点继承的上游命名服务器。在此功能之前，通常通过用自定义解析器替换上游 DNS 来引入存根域。然而，这导致自定义解析器本身成为 DNS 解析的关键路径，其中可扩展性和可用性问题可能导致集群失去 DNS 功能。此功能允许用户引入自定义解析，而无需接管整个解析路径。

自定义 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。

下面是示例域名及其查询目的地表

ConfigMap 配置说明

• 存根域 (stubDomains)（可选）

  • 格式：一个 JSON 映射，使用 DNS 后缀作为键（例如：“acme.local”），值是一个由 DNS IP 组成的 JSON 数组。
  • 注意：目标命名服务器本身可能是一个 Kubernetes 服务。例如，您可以运行自己的 dnsmasq 副本，将自定义 DNS 名称导出到 ClusterDNS 命名空间。

• 上游命名服务器 (upstreamNameservers)（可选）

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

示例 #1：添加 Consul DNS 存根域

在此示例中，用户有一个希望与 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：替换上游命名服务器

在此示例中，集群管理员希望明确强制所有非集群 DNS 查找都通过其位于 172.16.0.1 的自己的命名服务器。同样，这很容易实现；他们只需创建一个 ConfigMap，并在 upstreamNameservers 字段中指定所需的命名服务器。

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

• ←上一篇
• 下一篇→