如何在 Kubernetes 中配置私有 DNS 区域和上游 NS

[Tenxcloud10]

许多用户想将现有的域名 zones 集成到其 Kubernetes DNS 命名空间中。例如，混合云用户可能希望解决集群内部的“.corp ”域地址问题。其他用户可能是有由非 Kubernetes 服务发现系统的 zone （如 Consul ）问题。在 Kubernetes 1.6 中， kube-dns 增加了对可配置的专用 DNS zones （通常称为“ stub domains ”）和外部上游 DNS 名称服务器的支持。在这篇博文中，我们将介绍如何配置和使用此功能。

1.默认查找流程

Kubernetes 目前支持两种 DNS 策略： ” Default ”和” ClusteFirst ”。 如果 dnsPolicy 的 Flag 没有特别指明，则默认使用” ClusterFirst ”。 如果 dnsPolicy 设置为“ Default ”，则名称解析配置将从 pod 运行的节点继承。

如果 dnsPolicy 设置为“ ClusterFirst ”，则 DNS 查询将被发送到 kube-dns 服务。 基于 cluster domaim 后缀（上述示例中以.cluster.local 结尾的地址）的域查询将由 kube-dns 服务应答。 所有其他查询（例如 www.kubernetes.io ）将被转发到从节点继承的上游 NS 。

在此之前，通常使用自定义解析器替换上游 DNS 来引入存根域。 然而，这会导致自定义解析器本身成为 DNS 解析的关键路径，其中可扩展性和可用性的问题可能导致集群丢失 DNS 功能。 现在，允许用户引入自定义解析而不占用整个解析路径。

2.自定义 DNS Flow 从 Kubernetes 1.6 开始，集群管理员可以通过为 kube-dns 提供的 ConfigMap 来指定自定义存根域和上游 NS 。 例如，下面的配置插入一个单独的存根域和两个上游 NS 。 如下所示，以“.acme.local ”为后缀的 DNS 请求将被转发到监听在 1.2.3.4 上的 DNS 服务来处理。此外， Google 公共 DNS 将提供上游查询。 有关数据格式的一些说明，请参阅本节末尾的 ConfigMap 配置说明。

下图显示了上述配置中指定的 DNS 查询流程。

将 dnsPolicy 设置为“ ClusterFirst ”后，首先将 DNS 查询发送到 kube-dn s 中的 DNS 缓存层。 从这里，请求的后缀被检查，然后转发到相应的 DNS 。 在这种情况下，具有集群后缀（例如“.cluster.local ”）的名称将发送到 kube-dns 。 使用存根域后缀（例如“.acme.local ”）的名称将被发送到配置的自定义解析器。 最后，与这些后缀不匹配的请求将转发到上游 DNS 。

以下是一些域名示例以及查询这些域名的目标服务器：

3.ConfigMap 配置注意事项 stubDomains （可选） 格式：以 DNS 后缀（如“ acme.local ”）为键， DNS IP 数组为值的 JSON 映射。 注意：目标名称服务器本身可能是 Kubernetes 服务。 例如，您可以运行自己的 dnsmasq 副本将自定义 DNS 名称导出到 ClusterDNS 命名空间中。

upstreamNameservers （可选） 格式： DNS I P 的 JSON 数组。 注意：如果指定，那么指定的值将替代默认从节点的 /etc/resolv.conf 中获取的名称服务器 限制：最多可以指定三个上游名称服务器

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

示例 2 ：替换上游 NS 在此示例中，集群管理员希望明确强制所有非集群的 DNS 查询通过运行 在 172.16.0.1 上的他们自己的 NS 来完成。 这很容易完成,他们只需要使用指定所需名称 服务器的 upstreamNameservers 字段创建一个 ConfigMap 。