自定义 DNS 服务

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

准备开始
介绍
CoreDNS
Kube-dns
CoreDNS 配置等同于 kube-dns
迁移到 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。

apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns
  namespace: kube-system
data:
  Corefile: |
    .:53 {
        errors
        health
        kubernetes cluster.local in-addr.arpa ip6.arpa {
           pods insecure
           upstream
           fallthrough in-addr.arpa ip6.arpa
        }
        prometheus :9153
        proxy ./etc/resolv.conf
        cache 30
        loop
        reload
        loadbalance
    }

Corefile 配置包括以下 CoreDNS 的插件：

错误：错误记录到 stdout。
健康：CoreDNS 的健康报告给 http://localhost:8080/health。
kubernetes：CoreDNS 将基于 Kubernetes 的服务和 Pod 的 IP 答复 DNS 查询。您可以在此处.

提供 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 中创建加入以下字段。

consul.local:53 {
        errors
        cache 30
        proxy . 10.150.0.1
    }

要显式强制所有非集群 DNS 查找通过特定的域名服务器（位于172.16.0.1），请将 proxy 和 forward 指向域名服务器，而不是 /etc/resolv.conf。

proxy .  172.16.0.1

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

apiVersion: v1
kind: ConfigMap
metadata:
  name: coredns
  namespace: kube-system
data:
  Corefile: |
    .:53 {
        errors
        health
        kubernetes cluster.local in-addr.arpa ip6.arpa {
           pods insecure
           upstream 172.16.0.1
           fallthrough in-addr.arpa ip6.arpa
        }
        prometheus :9153
        proxy . 172.16.0.1
        cache 30
        loop
        reload
        loadbalance
    }
    consul.local:53 {
        errors
        cache 30
        proxy . 10.150.0.1
    }

在 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 配置：

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

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

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

域名	服务器回答查询
kubernetes.default.svc.cluster.local	kube-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：

apiVersion: v1
kind: ConfigMap
metadata:
  name: kube-dns
  namespace: kube-system
data:
  upstreamNameservers: |
    ["172.16.0.1"]

CoreDNS 配置等同于 kube-dns

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

示例

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

apiVersion: v1
data:
  federations: |
    {"foo" : "foo.feddomain.com"}
  stubDomains: |
    {"abc.com" : ["1.2.3.4"], "my.cluster.local" : ["2.3.4.5"]}
  upstreamNameservers: |
    ["8.8.8.8", "8.8.4.4"]
kind: ConfigMap

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

For federations:

federation cluster.local {
       foo foo.feddomain.com
    }

For stubDomains:

abc.com:53 {
    errors
    cache 30
    proxy . 1.2.3.4
}
my.cluster.local:53 {
    errors
    cache 30
    proxy . 2.3.4.5
}

带有默认插件的完整 Corefile：

.:53 {
        errors
        health
        kubernetes cluster.local in-addr.arpa ip6.arpa {
           upstream  8.8.8.8 8.8.4.4
           pods insecure
           fallthrough in-addr.arpa ip6.arpa
        }
        federation cluster.local {
           foo foo.feddomain.com
        }
        prometheus :9153
        proxy .  8.8.8.8 8.8.4.4
        cache 30
    }
    abc.com:53 {
        errors
        cache 30
        proxy . 1.2.3.4
    }
    my.cluster.local:53 {
        errors
        cache 30
        proxy . 2.3.4.5
    }

迁移到 CoreDNS

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

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

反馈

此页是否对您有帮助？

感谢反馈。如果您有一个关于如何使用 Kubernetes 的特定的、需要答案的问题，可以访问 Stack Overflow. 在 GitHub 仓库上登记新的问题报告问题或者提出改进建议.

任务