自定义 DNS 服务

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

    • 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 命令行工具。 如果你还没有集群,你可以通过 构建一 个你自己的集群,或者你可以使用下面任意一个 Kubernetes 工具构建:

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

    • Kubernetes 版本 1.6 或更新。如果与 CoreDNS 匹配,版本 1.9 或更新。

    介绍

    DNS 是使用插件管理器自动启动的内置的 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是通用的权威DNS服务器,可以用作集群DNS,符合dns 规范

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

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

    Corefile 配置包括以下 CoreDNS 的 插件

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

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

    示例

    如果集群操作员的 域服务器位于 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 配置如下所示:

    在 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 缓存以提高性能。
    • ““:提供单个运行状况检查端点,对 dnsmasq 和 Kubedns 进行健康检查。

    集群管理员可以指定自定义存根域和上游域名服务器通过为 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. {"acme.local": ["1.2.3.4"]}
    8. upstreamNameservers: |
    9. ["8.8.8.8", "8.8.4.4"]

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

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

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

    对 Pod 的影响

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

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

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

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

    1.首先将查询发送到 kube-dns 中的 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 服务器。

    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. kind: ConfigMap
    2. metadata:
    3. name: kube-dns
    4. namespace: kube-system
    5. data:
    6. upstreamNameservers: |
    7. ["172.16.0.1"]

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

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

    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

    带有默认插件的完整 Corefile:

    迁移到 CoreDNS

    ## 下一步是什么 - 。 ```