k8s与DNS--配置私有DNS Zones和Upstream Nameservers

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

Default lookup flow

Kubernetes目前支持使用dnsPolicy标志在每个pod上指定的两个DNS策略：

• “Default”
• “ClusterFirst”

如果未明确指定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”]

        

          
        
        
        

          

          AI 代码解读
        
      
      

下图显示了上述配置中指定的DNS查询流。将dnsPolicy设置为“ClusterFirst”后，DNS查询将首先发送到kube-dns中的DNS缓存层。从此处检查请求的后缀，然后将其转发到相应的DNS。在这种情况下，具有集群后缀的名称（例如“.cluster.local”）将发送到kube-dns。具有存根域后缀的名称（例如“.acme.local”）将被发送到配置的自定义解析程序。最后，与这些后缀中的任何一个都不匹配的请求将被转发到上游DNS。

下面是一个示例域名和这些域名的查询目的地的表格：

ConfigMap Configuration Notes

• stubDomains存根区域(可选)

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

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

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

示例 #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”]}

        

          
        
        
        

          

          AI 代码解读
        
      
      

示例 #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”]

        

          
        
        
        

          

          AI 代码解读
        
      
      

总结
上文是kube-dns实现的解决方案。而stubDomains 和 upstreamNameservers 在coredns 中 通过 proxy 插件实现。coredns是接下来重点研究的东西。

本文转自中文社区-k8s与DNS--配置私有DNS Zones和Upstream Nameservers