OpenShift 文档正在迁移，很快将只在 docs.redhat.com（所有 Red Hat 产品文档的中心）提供。立即体验 新的文档体验。
  1. 文档
    2. history bug_report picture_as_pdf
×

OpenShift 容器平台中的 DNS 运算符

在 OpenShift Container Platform 中，DNS 操作符部署和管理 CoreDNS 实例，为集群内的 Pod 提供名称解析服务，启用基于 DNS 的 Kubernetes 服务发现，并解析内部 `cluster.local` 名称。

检查 DNS 操作符的状态

DNS 操作符实现来自 `operator.openshift.io` API 组的 `dns` API。操作符使用守护程序集部署 CoreDNS，为守护程序集创建服务，并配置 kubelet 以指示 Pod 使用 CoreDNS 服务 IP 地址进行名称解析。

步骤

DNS 操作符在安装期间使用 `Deployment` 对象部署。

  1. 使用 `oc get` 命令查看部署状态

    $ oc get -n openshift-dns-operator deployment/dns-operator
    示例输出
    NAME           READY     UP-TO-DATE   AVAILABLE   AGE
dns-operator   1/1       1            1           23h

  2. 使用 `oc get` 命令查看 DNS 操作符的状态

    $ oc get clusteroperator/dns
    示例输出
    NAME      VERSION     AVAILABLE   PROGRESSING   DEGRADED   SINCE   MESSAGE
dns       4.1.15-0.11  True        False         False      92m

    `AVAILABLE`、`PROGRESSING` 和 `DEGRADED` 提供有关操作符状态的信息。当 CoreDNS 守护程序集中的至少 1 个 Pod 报告 `Available` 状态条件并且 DNS 服务具有集群 IP 地址时，`AVAILABLE` 为 `True`。

查看默认 DNS

每个新的 OpenShift Container Platform 安装都具有名为 `default` 的 `dns.operator`。

步骤

  1. 使用 `oc describe` 命令查看默认 `dns`

    $ oc describe dns.operator/default
    示例输出
    Name:         default
Namespace:
Labels:       <none>
Annotations:  <none>
API Version:  operator.openshift.io/v1
Kind:         DNS
...
Status:
  Cluster Domain:  cluster.local (1)
  Cluster IP:      172.30.0.10 (2)
...
    1 集群域字段是用于构建完全限定的 Pod 和服务域名名的基本 DNS 域名。
    2 集群 IP 是 Pod 查询名称解析的地址。IP 定义为服务 CIDR 范围中的第 10 个地址。

  2. 要查找集群的服务 CIDR 范围，请使用 `oc get` 命令

    $ oc get networks.config/cluster -o jsonpath='{$.status.serviceNetwork}'
    示例输出
    [172.30.0.0/16]

使用 DNS 转发

您可以使用 DNS 转发以以下方式覆盖 `/etc/resolv.conf` 文件中的默认转发配置

  • 为每个区域指定名称服务器 ( `spec.servers` )。如果转发的区域是 OpenShift Container Platform 管理的入口域名，则上游名称服务器必须为此域名授权。

  • 提供上游 DNS 服务器列表 ( `spec.upstreamResolvers` )。

  • 更改默认转发策略。

默认域的 DNS 转发配置可以同时具有 `/etc/resolv.conf` 文件中指定的默认服务器和上游 DNS 服务器。
步骤

  1. 修改名为 `default` 的 DNS 操作符对象

    $ oc edit dns.operator/default

    发出之前的命令后，操作符将使用基于 `spec.servers` 的附加服务器配置块创建并更新名为 `dns-default` 的配置映射。如果没有任何服务器的区域与查询匹配，则名称解析将回退到上游 DNS 服务器。

    配置 DNS 转发
    apiVersion: operator.openshift.io/v1
kind: DNS
metadata:
  name: default
spec:
  cache:
    negativeTTL: 0s
    positiveTTL: 0s
  logLevel: Normal
  nodePlacement: {}
  operatorLogLevel: Normal
  servers:
  - name: example-server (1)
    zones:
    - example.com (2)
    forwardPlugin:
      policy: Random (3)
      upstreams: (4)
      - 1.1.1.1
      - 2.2.2.2:5353
  upstreamResolvers: (5)
    policy: Random (6)
    protocolStrategy: ""  (7)
    transportConfig: {}  (8)
    upstreams:
    - type: SystemResolvConf (9)
    - type: Network
      address: 1.2.3.4 (10)
      port: 53 (11)
    status:
      clusterDomain: cluster.local
      clusterIP: x.y.z.10
      conditions:
   ...
    1 必须符合 `rfc6335` 服务名称语法。
    2 必须符合 `rfc1123` 服务名称语法中子域的定义。集群域名 `cluster.local` 是 `zones` 字段的无效子域名。
    3 定义选择 `forwardPlugin` 中列出的上游解析器的策略。默认值为 `Random`。您还可以使用 `RoundRobin` 和 `Sequential` 值。
    4 每个 `forwardPlugin` 最多允许 15 个 `upstreams`。
    5 您可以使用 `upstreamResolvers` 覆盖默认转发策略并将 DNS 解析转发到为默认域指定的 DNS 解析器（上游解析器）。如果您没有提供任何上游解析器，则 DNS 名称查询将转到 `/etc/resolv.conf` 中声明的服务器。
    6 确定列在upstreams中的上游服务器查询顺序。您可以指定以下值之一：Random、RoundRobin或Sequential。默认值为Sequential。
    7 如果省略，平台将选择默认值，通常是原始客户端请求的协议。设置为TCP以指定平台应为所有上游DNS请求使用TCP，即使客户端请求使用UDP。
    8 用于配置传输类型、服务器名称以及转发DNS请求到上游解析器时使用的可选自定义CA或CA捆绑。
    9 您可以指定两种类型的upstreams：SystemResolvConf或Network。SystemResolvConf将上游配置为使用/etc/resolv.conf，而Network定义一个Networkresolver。您可以指定一个或两个。
    10 如果指定的类型为Network，则必须提供IP地址。address字段必须是有效的IPv4或IPv6地址。
    11 如果指定的类型为Network，则可以选择提供端口。port字段的值必须在1和65535之间。如果您没有为上游指定端口，则默认端口为853。
附加资源

检查DNS Operator状态

您可以使用oc describe命令检查DNS Operator的状态并查看其详细信息。

步骤

  • 查看DNS Operator的状态

    $ oc describe clusteroperators/dns

    尽管在特定版本中消息和拼写可能会有所不同，但预期的状态输出如下所示

    Status:
  Conditions:
    Last Transition Time:  <date>
    Message:               DNS "default" is available.
    Reason:                AsExpected
    Status:                True
    Type:                  Available
    Last Transition Time:  <date>
    Message:               Desired and current number of DNSes are equal
    Reason:                AsExpected
    Status:                False
    Type:                  Progressing
    Last Transition Time:  <date>
    Reason:                DNSNotDegraded
    Status:                False
    Type:                  Degraded
    Last Transition Time:  <date>
    Message:               DNS default is upgradeable: DNS Operator can be upgraded
    Reason:                DNSUpgradeable
    Status:                True
    Type:                  Upgradeable

查看DNS Operator日志

您可以使用oc logs命令查看DNS Operator日志。

步骤

  • 查看DNS Operator的日志

    $ oc logs -n openshift-dns-operator deployment/dns-operator -c dns-operator

设置CoreDNS日志级别

CoreDNS和CoreDNS Operator的日志级别通过不同的方法设置。您可以配置CoreDNS日志级别以确定记录的错误消息的详细程度。CoreDNS日志级别的有效值为Normal、Debug和Trace。默认logLevel为Normal。

CoreDNS错误日志级别始终启用。以下日志级别设置报告不同的错误响应

  • logLevel：Normal启用“errors”类：log . { class error }。

  • logLevel：Debug启用“denial”类：log . { class denial error }。

  • logLevel：Trace启用“all”类：log . { class all }。
步骤

  • 要将logLevel设置为Debug，请输入以下命令

    $ oc patch dnses.operator.openshift.io/default -p '{"spec":{"logLevel":"Debug"}}' --type=merge

  • 要将logLevel设置为Trace，请输入以下命令

    $ oc patch dnses.operator.openshift.io/default -p '{"spec":{"logLevel":"Trace"}}' --type=merge
验证

  • 要确保设置了所需的日志级别，请检查配置映射

    $ oc get configmap/dns-default -n openshift-dns -o yaml

    例如，将logLevel设置为Trace后，您应该在每个服务器块中看到此节：

    errors
log . {
    class all
}

设置CoreDNS Operator日志级别

CoreDNS和CoreDNS Operator的日志级别通过不同的方法设置。集群管理员可以配置Operator日志级别以更快地追踪OpenShift DNS问题。operatorLogLevel的有效值为Normal、Debug和Trace。Trace具有最详细的信息。默认operatorlogLevel为Normal。Operator问题共有七个日志级别：Trace、Debug、Info、Warning、Error、Fatal和Panic。设置日志级别后，将记录具有该严重性或高于该严重性的日志条目。

  • operatorLogLevel: "Normal" 设置 logrus.SetLogLevel("Info")。

  • operatorLogLevel: "Debug" 设置 logrus.SetLogLevel("Debug")。

  • operatorLogLevel: "Trace" 设置 logrus.SetLogLevel("Trace")。

步骤

  • 要将operatorLogLevel设置为Debug，请输入以下命令

    $ oc patch dnses.operator.openshift.io/default -p '{"spec":{"operatorLogLevel":"Debug"}}' --type=merge

  • 要将operatorLogLevel设置为Trace，请输入以下命令

    $ oc patch dnses.operator.openshift.io/default -p '{"spec":{"operatorLogLevel":"Trace"}}' --type=merge
验证

  1. 要查看结果更改，请输入以下命令

    $ oc get dnses.operator -A -oyaml

    您应该看到两个日志级别条目。operatorLogLevel适用于OpenShift DNS Operator问题，而logLevel适用于CoreDNS pod的daemonset。

     logLevel: Trace
 operatorLogLevel: Debug

  2. 要查看daemonset的日志，请输入以下命令

    $ oc logs -n openshift-dns ds/dns-default

调整CoreDNS缓存

对于CoreDNS，您可以配置成功或不成功缓存的最大持续时间，分别称为正缓存或负缓存。调整DNS查询响应的缓存持续时间可以减少任何上游DNS解析器的负载。

将TTL字段设置为较低的值可能会导致集群、任何上游解析器或两者的负载增加。
步骤

  1. 通过运行以下命令编辑名为default的DNS Operator对象

    $ oc edit dns.operator.openshift.io/default

  2. 修改生存时间(TTL)缓存值

    配置DNS缓存
    apiVersion: operator.openshift.io/v1
kind: DNS
metadata:
  name: default
spec:
  cache:
    positiveTTL: 1h (1)
    negativeTTL: 0.5h10m (2)
    1 字符串值1h由CoreDNS转换为相应的秒数。如果省略此字段，则该值假定为0s，并且集群使用内部默认值900s作为后备。
    2 字符串值可以是单位的组合，例如0.5h10m，并由CoreDNS转换为相应的秒数。如果省略此字段，则该值假定为0s，并且集群使用内部默认值30s作为后备。
验证

  1. 要查看更改，请再次查看配置映射，方法是运行以下命令

    oc get configmap/dns-default -n openshift-dns -o yaml

  2. 验证您是否看到如下所示的条目

           cache 3600 {
            denial 9984 2400
        }
附加资源

有关缓存的更多信息，请参阅CoreDNS缓存。

高级任务

更改DNS Operator managementState

DNS Operator管理CoreDNS组件，为集群中的pod和服务提供名称解析服务。DNS Operator的managementState默认为Managed，这意味着DNS Operator正在主动管理其资源。您可以将其更改为Unmanaged，这意味着DNS Operator不管理其资源。

以下是更改DNS Operator managementState的用例

  • 您是开发人员，想要测试配置更改以查看它是否可以修复CoreDNS中的问题。您可以通过将managementState设置为Unmanaged来阻止DNS Operator覆盖配置更改。

  • 您是集群管理员，并且已报告了CoreDNS问题，但需要应用解决方法直到问题得到解决。您可以将DNS Operator的managementState字段设置为Unmanaged以应用解决方法。

步骤

  1. 在DNS Operator中将managementState更改为Unmanaged

    oc patch dns.operator.openshift.io default --type merge --patch '{"spec":{"managementState":"Unmanaged"}}'

  2. 使用jsonpath命令行JSON解析器查看DNS Operator的managementState

    $ oc get dns.operator.openshift.io default -ojsonpath='{.spec.managementState}'
    示例输出
    "Unmanaged"

当managementState设置为Unmanaged时，您无法进行升级。

控制DNS pod放置

DNS Operator有两个daemon set：一个用于CoreDNS，称为dns-default；另一个用于管理/etc/hosts文件，称为node-resolver。

您可能需要控制哪些节点分配并运行CoreDNS pod，尽管这不是常见操作。例如，如果集群管理员配置了可以禁止节点对之间通信的安全策略，则需要限制运行CoreDNS的daemonset的节点集。如果DNS pod在集群中的某些节点上运行，并且未运行DNS pod的节点与运行DNS pod的节点具有网络连接，则所有pod都可以使用DNS服务。

node-resolver daemon set必须在每个节点主机上运行，因为它添加了集群镜像注册表的条目以支持拉取镜像。node-resolver pod只有一个作业：查找image-registry.openshift-image-registry.svc服务的集群IP地址，并将其添加到节点主机的/etc/hosts中，以便容器运行时可以解析服务名称。

作为集群管理员，您可以使用自定义节点选择器来配置 CoreDNS 的守护程序集，使其在特定节点上运行或不运行。

先决条件

  • 您已安装 oc 命令行界面。

  • 您已以具有 cluster-admin 权限的用户身份登录到集群。

  • 您的 DNS 运营商 managementState 设置为 Managed。

步骤

  • 要允许 CoreDNS 的守护程序集在特定节点上运行，请配置污点和容忍。

    1. 修改名为 `default` 的 DNS 操作符对象

      $ oc edit dns.operator/default

    2. 指定污点键和污点的容忍。

       spec:
   nodePlacement:
     tolerations:
     - effect: NoExecute
       key: "dns-only"
       operators: Equal
       value: abc
       tolerationSeconds: 3600 (1)
      1 如果污点是 dns-only，则可以无限期地容忍它。您可以忽略 tolerationSeconds。

使用 TLS 配置 DNS 转发

在高度受管控的环境中工作时，您可能需要在将请求转发到上游解析器时保护 DNS 流量，以便您可以确保额外的 DNS 流量和数据隐私。

请注意，CoreDNS 会缓存转发连接 10 秒。如果未发出请求，CoreDNS 将保持 TCP 连接打开 10 秒。对于大型集群，请确保您的 DNS 服务器知道它可能会保持许多新的打开连接，因为您可以为每个节点启动一个连接。相应地设置您的 DNS 层次结构以避免性能问题。

步骤

  1. 修改名为 `default` 的 DNS 操作符对象

    $ oc edit dns.operator/default

    集群管理员可以为转发的 DNS 查询配置传输层安全 (TLS)。

    使用 TLS 配置 DNS 转发
    apiVersion: operator.openshift.io/v1
kind: DNS
metadata:
  name: default
spec:
  servers:
  - name: example-server (1)
    zones:
    - example.com (2)
    forwardPlugin:
      transportConfig:
        transport: TLS (3)
        tls:
          caBundle:
            name: mycacert
          serverName: dnstls.example.com  (4)
      policy: Random (5)
      upstreams: (6)
      - 1.1.1.1
      - 2.2.2.2:5353
  upstreamResolvers: (7)
    transportConfig:
      transport: TLS
      tls:
        caBundle:
          name: mycacert
        serverName: dnstls.example.com
    upstreams:
    - type: Network (8)
      address: 1.2.3.4 (9)
      port: 53 (10)
    1 必须符合 `rfc6335` 服务名称语法。
    2 必须符合 rfc1123 服务名称语法中子域的定义。集群域 cluster.local 是 zones 字段的无效子域。集群域 cluster.local 是 zones 的无效 subdomain。
    3 为转发的 DNS 查询配置 TLS 时，请将 transport 字段的值设置为 TLS。
    4 为转发的 DNS 查询配置 TLS 时，这是一个强制性的服务器名称，用作服务器名称指示 (SNI) 的一部分，用于验证上游 TLS 服务器证书。
    5 定义选择上游解析器的策略。默认值为 Random。您还可以使用 RoundRobin 和 Sequential 值。
    6 必需。使用它来提供上游解析器。每个 forwardPlugin 条目最多允许 15 个 upstreams 条目。
    7 可选。您可以使用它来覆盖默认策略并将 DNS 解析转发到为默认域指定的 DNS 解析器（上游解析器）。如果您没有提供任何上游解析器，则 DNS 名称查询将转到 /etc/resolv.conf 中的服务器。
    8 使用 TLS 时，只允许 Network 类型，并且您必须提供 IP 地址。Network 类型表示此上游解析器应单独处理转发的请求，而不是 /etc/resolv.conf 中列出的上游解析器。
    9 address 字段必须是有效的 IPv4 或 IPv6 地址。
    10 您可以选择提供端口。port 的值必须介于 1 和 65535 之间。如果您没有为上游指定端口，则默认端口为 853。

    如果 servers 未定义或无效，则 config map 只包含默认服务器。
验证

  1. 查看 config map

    $ oc get configmap/dns-default -n openshift-dns -o yaml
    基于 TLS 转发示例的示例 DNS ConfigMap
    apiVersion: v1
data:
  Corefile: |
    example.com:5353 {
        forward . 1.1.1.1 2.2.2.2:5353
    }
    bar.com:5353 example.com:5353 {
        forward . 3.3.3.3 4.4.4.4:5454 (1)
    }
    .:5353 {
        errors
        health
        kubernetes cluster.local in-addr.arpa ip6.arpa {
            pods insecure
            upstream
            fallthrough in-addr.arpa ip6.arpa
        }
        prometheus :9153
        forward . /etc/resolv.conf 1.2.3.4:53 {
            policy Random
        }
        cache 30
        reload
    }
kind: ConfigMap
metadata:
  labels:
    dns.operator.openshift.io/owning-dns: default
  name: dns-default
  namespace: openshift-dns
    1 对 forwardPlugin 的更改将触发 CoreDNS 守护程序集的滚动更新。
附加资源