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

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

Default lookup flow

k8s与DNS--配置私有DNS Zones和Upstream Nameservers_第1张图片

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”]

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

k8s与DNS--配置私有DNS Zones和Upstream Nameservers_第2张图片

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

Domain name Server answering the query
kubernetes.default.svc.cluster.local kube-dns
foo.acme.local custom DNS (1.2.3.4)
widget.com upstream DNS (one of 8.8.8.8, 8.8.4.4)

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”]}

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

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

你可能感兴趣的:(kubernetes,k8s,dns)