如何在 K8S 中配置私有 DNS 区域和上游 NS
许多用户想将现有的域名 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。
时速云翻译，转载请注明出处！