自定义 DNS 服务

本页说明如何配置 DNS Pod 和自定义 DNS 解析过程。 在 Kubernetes 1.11 和更高版本中,CoreDNS 位于 GA 并且默认情况下与 kubeadm 一起安装。 请参见CoreDNS 的 ConfigMap 选项 and 使用 CoreDNS 进行服务发现

准备开始

要获知版本信息,请输入 kubectl version.

  • Kubernetes version 1.6 or later. To work with CoreDNS, version 1.9 or later.
  • The appropriate add-on: kube-dns or CoreDNS. To install with kubeadm, see the kubeadm reference documentation. —>
  • 你必须拥有一个 Kubernetes 的集群,同时你的 Kubernetes 集群必须带有 kubectl 命令行工具。 如果你还没有集群,你可以通过 Minikube 构建一 个你自己的集群,或者你可以使用下面任意一个 Kubernetes 工具构建:

要获知版本信息,请输入 kubectl version.

  • Kubernetes 版本 1.6 或更新。如果与 CoreDNS 匹配,版本 1.9 或更新。
  • 合适的 add-on 插件: kube-dns 或 CoreDNS. 使用 kubeadm 安装,请参见 kubeadm 帮助文档.

介绍

DNS 是使用插件管理器集群 add-on自动启动的内置的 Kubernetes 服务。

从 Kubernetes v1.12 开始,CoreDNS 是推荐的 DNS 服务器,取代了kube-dns。 但是,默认情况下,某些 Kubernetes 安装程序工具仍可能安装 kube-dns。 请参阅安装程序提供的文档,以了解默认情况下安装了哪个 DNS 服务器。

CoreDNS 的部署,作为一个 Kubernetes 服务,通过静态 IP 的方式暴露。 CoreDNS 和 kube-dns 服务在 metadata.name 字段中均被命名为 kube-dns。 这样做是为了与依靠传统 kube-dns 服务名称来解析集群内部地址的工作负载具有更大的互操作性。它抽象出哪个 DNS 提供程序在该公共端点后面运行的实现细节。 kubelet 使用 --cluster-dns = <dns-service-ip> 标志将 DNS 传递到每个容器。

DNS 名称也需要域。 您可在 kubelet 中使用 --cluster-domain = <default-local-domain> 标志配置本地域。

DNS 服务器支持正向查找(A 记录),端口发现(SRV 记录),反向 IP 地址发现(PTR 记录)等。 更多信息,请参见Pod 和 服务的 DNS

如果 Pod 的 dnsPolicy 设置为 “default“,则它将从 Pod 运行所在节点上的配置中继承名称解析配置。 Pod 的 DNS 解析应该与节点相同。 但请参阅已知问题

如果您不想这样做,或者想要为 Pod 使用其他 DNS 配置,则可以 使用 kubelet 的 --resolv-conf 标志。 将此标志设置为 “” 以避免 Pod 继承 DNS。 将其设置为有效的文件路径以指定除以下以外的文件 /etc/resolv.conf,用于 DNS 继承。

CoreDNS

CoreDNS是通用的权威DNS服务器,可以用作集群DNS,符合dns 规范

CoreDNS ConfigMap 选项

CoreDNS 是模块化且可插拔的 DNS 服务器,每个插件都为 CoreDNS 添加了新功能。 可以通过维护Corefile,即CoreDNS 配置文件。 集群管理员可以修改 CoreDNS Corefile 的 ConfigMap,以更改服务发现的工作方式。

在 Kubernetes 中,已经使用以下默认 Corefile 配置安装了 CoreDNS。

  1. apiVersion: v1
  2. kind: ConfigMap
  3. metadata:
  4. name: coredns
  5. namespace: kube-system
  6. data:
  7. Corefile: |
  8. .:53 {
  9. errors
  10. health
  11. kubernetes cluster.local in-addr.arpa ip6.arpa {
  12. pods insecure
  13. upstream
  14. fallthrough in-addr.arpa ip6.arpa
  15. }
  16. prometheus :9153
  17. proxy ./etc/resolv.conf
  18. cache 30
  19. loop
  20. reload
  21. loadbalance
  22. }

Corefile 配置包括以下 CoreDNS 的 插件

提供 pods insecure 选项是为了与 kube-dns 向前兼容。 您可以使用 pods verified 选项,该选项仅在相同名称空间中存在具有匹配 IP 的 pod 时才返回 A 记录。 如果您不使用 Pod 记录,则可以使用 pods disabled 选项。 ‘Upstream’ 用来解析指向外部主机的服务(外部服务)。

  • prometheus:CoreDNS的度量标准以Prometheus格式在 http://localhost:9153/metrics 上提供。
  • proxy: 不在 Kubernetes 集群域内的任何查询都将转发到预定义的解析器 (/etc/resolv.conf).
  • cache:这将启用前端缓存。
  • loop:检测到简单的转发循环,如果发现死循环,则中止 CoreDNS 进程。
  • reload:允许自动重新加载已更改的 Corefile。 编辑 ConfigMap 配置后,请等待两分钟,以使更改生效。
  • loadbalance:这是一个轮询 DNS 负载均衡器,它在应答中随机分配 A,AAAA 和 MX 记录的顺序。

您可以通过修改 ConfigMap 来修改默认的 CoreDNS 行为。

使用 CoreDN 配置存根域和上游域名服务器

CoreDNS 能够使用 proxy plugin. 配置存根域和上游域名服务器。

示例

如果集群操作员的 Consul 域服务器位于 10.150.0.1,并且所有 Consul 名称都带有后缀.consul.local。 要在 CoreDNS 中对其进行配置,集群管理员可以在 CoreDNS 的 ConfigMap 中创建加入以下字段。

  1. consul.local:53 {
  2. errors
  3. cache 30
  4. proxy . 10.150.0.1
  5. }

要显式强制所有非集群 DNS 查找通过特定的域名服务器(位于172.16.0.1),请将 proxyforward 指向域名服务器,而不是 /etc/resolv.conf

  1. proxy . 172.16.0.1

最终的 ConfigMap 以及默认的 Corefile 配置如下所示:

  1. apiVersion: v1
  2. kind: ConfigMap
  3. metadata:
  4. name: coredns
  5. namespace: kube-system
  6. data:
  7. Corefile: |
  8. .:53 {
  9. errors
  10. health
  11. kubernetes cluster.local in-addr.arpa ip6.arpa {
  12. pods insecure
  13. upstream 172.16.0.1
  14. fallthrough in-addr.arpa ip6.arpa
  15. }
  16. prometheus :9153
  17. proxy . 172.16.0.1
  18. cache 30
  19. loop
  20. reload
  21. loadbalance
  22. }
  23. consul.local:53 {
  24. errors
  25. cache 30
  26. proxy . 10.150.0.1
  27. }

在 Kubernetes 1.10 和更高版本中,kubeadm 支持将 kube-dns ConfigMap 自动转换为 CoreDNS ConfigMap。 注意:尽管kube-dns接受 stubdomain 和 nameserver 的 FQDN(例如:ns.foo.com),但 CoreDNS 不支持此功能。 转换期间,CoreDNS 配置中将省略所有 FQDN 域名服务器。

Kube-dns

由于 CoreDNS 现在是默认设置,因此 Kube-dns 现在可以用作可选的 DNS 服务器。 正在运行的DNS Pod包含3个容器:

  • kubedns“:监测 Kubernetes 主节点的服务和 Endpoints 的更改,并维护内存中的查找结构以服务 DNS 请求。
  • dnsmasq“:添加 DNS 缓存以提高性能。
  • sidecar“:提供单个运行状况检查端点,对 dnsmasq 和 Kubedns 进行健康检查。

配置存根域和上游 DNS 服务器

集群管理员可以指定自定义存根域和上游域名服务器通过为 kube-dns (kube-system:kube-dns) 提供 ConfigMap。

例如,以下 ConfigMap 使用单个存根域和两个上游域名服务器设置 DNS 配置:

  1. apiVersion: v1
  2. kind: ConfigMap
  3. metadata:
  4. name: kube-dns
  5. namespace: kube-system
  6. data:
  7. stubDomains: |
  8. {"acme.local": ["1.2.3.4"]}
  9. upstreamNameservers: |
  10. ["8.8.8.8", "8.8.4.4"]

带 “.acme.local” 后缀的 DNS 请求 被转发到侦听 1.2.3.4 的 DNS。 通过 Google 公共 DNS 进行向上查询。

下表描述了具有特定域名的查询如何映射到 其目标DNS服务器:

域名服务器回答查询
kubernetes.default.svc.cluster.localkube-dns
foo.acme.local自定义 DNS(1.2.3.4)
widget.com上游 DNS(8.8.8.8、8.8.4.4中的一个)

请参见 ConfigMap options 有关配置选项格式的详细信息。

对 Pod 的影响

自定义上游域名服务器和存根域不影响 dnsPolicy 设置为 “Default” 或 “None” 的 Pod。

如果 Pod 的 dnsPolicy 设置为 “ClusterFirst“,则根据是否配置了存根域和上游 DNS 服务器来不同地处理其名称解析。

不使用自定义配置:任何与配置不匹配的查询 集群域后缀(例如 “www.kubernetes.io”)将转发到从节点继承的上游域名服务器。

使用自定义配置:如果存根域和上游 DNS 服务器 配置完成后,DNS 查询将按照以下流程进行路由::

1.首先将查询发送到 kube-dns 中的 DNS 缓存层。

1.在以下情况下,从缓存层检查请求的后缀,然后将其转发到适当的 DNS::

* *带集群后缀的名称*,例如 “.cluster.local”: 该请求被发送到 kube-dns。

* *带存根域名后缀的名称*,例如 “.acme.local”: 该请求将发送到已配置的自定义 DNS 解析器,例如在 1.2.3.4 处进行侦听。

* *名称没有匹配的后缀*,例如 “widget.com”: 该请求被转发到上游 DNS, 例如位于 8.8.8.8 和 8.8.4.4 的 Google 公共 DNS 服务器。

DNS 查询流程

ConfigMap 选项

kube-dns kube-system:kube-dns 的 ConfigMap 选项:

领域格式描述
stubDomains(可选)使用 DNS 后缀键(例如“ acme.local”)和由 DNS IP 的 JSON 数组组成的值的 JSON 映射。目标域名服务器本身可以是 Kubernetes 服务。 例如,您可以运行自己的 dnsmasq 副本,以将自定义 DNS 名称导出到 ClusterDNS 命名空间中。
upstreamNameservers(可选)DNS IP的 JSON 数组。如果指定,则这些值替换默认情况下从节点的 /etc/resolv.conf 中获取的域名服务器。 限制:最多可以指定三个上游域名服务器。

例子

示例:存根域

在此示例中,用户具有他们想与 kube-dns 集成的 Consul DNS 服务发现系统。 consul 域服务器位于 10.150.0.1,所有领事名称均带有后缀 .consul.local。 要配置 Kubernetes,集群管理员将创建以下 ConfigMap:

yaml apiVersion: v1 kind: ConfigMap metadata: name: kube-dns namespace: kube-system data: stubDomains: | {"consul.local": ["10.150.0.1"]} ​

需要注意的是集群管理员不希望覆盖节点的上游域名服务器,所以他们没有指定可选的 upstreamNameservers 字段。

示例: 上游域名服务器

在此示例中,集群管理员希望显式强制所有非集群 DNS 查找通过其自己的域名服务器172.16.0.1)。 在这种情况下,他们使用指定所需域名服务器的 upstreamNameservers 字段创建一个 ConfigMap:

  1. apiVersion: v1
  2. kind: ConfigMap
  3. metadata:
  4. name: kube-dns
  5. namespace: kube-system
  6. data:
  7. upstreamNameservers: |
  8. ["172.16.0.1"]

CoreDNS 配置等同于 kube-dns

CoreDNS 不仅仅提供 kube-dns 的功能。 为 kube-dns 创建的 ConfigMap 支持 StubDomainsupstreamNameservers 转换为 CoreDNS 中的 proxy 插件。 同样,kube-dns 中的 Federations 插件会转换为 CoreDNS 中的 federation 插件。

示例

用于 kubedns 的此示例 ConfigMap 描述了 federations, stubdomains and upstreamnameservers:

  1. apiVersion: v1
  2. data:
  3. federations: |
  4. {"foo" : "foo.feddomain.com"}
  5. stubDomains: |
  6. {"abc.com" : ["1.2.3.4"], "my.cluster.local" : ["2.3.4.5"]}
  7. upstreamNameservers: |
  8. ["8.8.8.8", "8.8.4.4"]
  9. kind: ConfigMap

CoreDNS 中的等效配置将创建一个 Corefile:

  • For federations:

    1. federation cluster.local {
    2. foo foo.feddomain.com
    3. }
  • For stubDomains:

    1. abc.com:53 {
    2. errors
    3. cache 30
    4. proxy . 1.2.3.4
    5. }
    6. my.cluster.local:53 {
    7. errors
    8. cache 30
    9. proxy . 2.3.4.5
    10. }

带有默认插件的完整 Corefile:

  1. .:53 {
  2. errors
  3. health
  4. kubernetes cluster.local in-addr.arpa ip6.arpa {
  5. upstream 8.8.8.8 8.8.4.4
  6. pods insecure
  7. fallthrough in-addr.arpa ip6.arpa
  8. }
  9. federation cluster.local {
  10. foo foo.feddomain.com
  11. }
  12. prometheus :9153
  13. proxy . 8.8.8.8 8.8.4.4
  14. cache 30
  15. }
  16. abc.com:53 {
  17. errors
  18. cache 30
  19. proxy . 1.2.3.4
  20. }
  21. my.cluster.local:53 {
  22. errors
  23. cache 30
  24. proxy . 2.3.4.5
  25. }

迁移到 CoreDNS

要将 kube-dns 迁移到 CoreDNS,可使用 详细博客 来帮助用户在迁移自 kube-dns。 集群管理员还可以使用部署脚本 进行迁移。

## 下一步是什么 - 调试 DNS 解析。 ```