第 10 章 DNS [operator.openshift.io/v1]


描述
DNS 管理 CoreDNS 组件,为集群中的 pod 和服务提供名称解析服务。这支持基于 DNS 的服务发现规格: https://github.com/kubernetes/dns/blob/master/docs/specification.md 更多详情: https://kubernetes.io/docs/tasks/administer-cluster/coredns 兼容性级别 1: 在主发行版本中至少为 12 个月或 3 个次版本(以更长的时间为准)。
类型
对象

10.1. 规格

属性类型描述

apiVersion

字符串

APIVersion 定义对象的这个表示法的版本化的 schema。服务器应该将识别的模式转换为最新的内部值,并可拒绝未识别的值。更多信息: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources

kind

字符串

kind 是一个字符串值,代表此对象所代表的 REST 资源。服务器可以从客户端向其提交请求的端点推断。无法更新。采用驼峰拼写法 (CamelCase)。更多信息: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds

metadata

ObjectMeta

标准对象元数据。更多信息: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata

spec

对象

spec 是 DNS 所需的行为的规格。

status

对象

Status 是 DNS 最近观察到的状态。

10.1.1. .spec

描述
spec 是 DNS 所需的行为的规格。
类型
object
属性类型描述

缓存

object

cache 描述了适用于 Corefile 中列出的所有服务器块的缓存配置。此字段允许集群管理员选择性地配置:* positiveTTL,它是一个应缓存正响应的持续时间。* 负TTL,这是应缓存负响应的持续时间。如果没有配置,OpenShift 将使用可能会更改的默认值配置正和负缓存。在编写本文时,默认的 positiveTTL 是 900 秒,默认的负TTL 为 30 秒,或者在您的 OpenShift 版本对应的 Corefile 中记录。

logLevel

string

Loglevel 描述了 CoreDNS 所需的日志详细程度。可以指定以下值之一: 上游解析器中的普通日志错误。* 调试日志错误、NXDOMAIN 响应和 NODATA 响应。* 跟踪日志错误和所有响应。设置 logLevel: Trace 将生成非常详细的日志。有效值为:"Normal", "Debug", "Trace"。默认值为 "Normal"。

managementState

字符串

managementState 指明 DNS 操作器是否应该管理集群 DNS

nodePlacement

对象

nodePlacement 提供对 DNS pod 调度的明确控制。通常,在每个节点上运行 DNS pod,以便 DNS 查询始终由本地 DNS pod 处理,而不是通过网络传输到另一个节点上的 DNS pod。但是,安全策略可能需要将 DNS pod 的放置限制到特定的节点。例如,如果安全策略禁止任意节点上的 pod 与 API 通信,则可以指定节点选择器,将 DNS pod 限制到允许与 API 通信的节点。相反,如果需要在具有特定污点的节点上运行 DNS pod,可以为该污点指定容限。如果未设置,则使用默认值。如需了解更多详细信息,请参阅 nodePlacement。

operatorLogLevel

string

operatorLogLevel 控制 DNS Operator 的日志记录级别。有效值为:"Normal", "Debug", "Trace"。默认为 "Normal"。设置 operatorLogLevel: Trace 将生成非常详细的日志。

服务器

array

服务器是 DNS 解析器列表,它为集群域范围之外的一个或多个子域提供名称查询委托。如果服务器由多个服务器组成,则将使用最长后缀匹配来确定服务器。例如,如果有两个服务器,一个用于 "foo.com",另一个用于 "a.foo.com",名称查询是 "www.a.foo.com",它将路由到带有 Zone "a.foo.com" 的 Server。如果此字段为 nil,则不会创建服务器。

servers[]

对象

服务器定义每个 CoreDNS 实例运行的服务器的 schema。

upstreamResolvers

object

upstreamResolver 定义了一个模式,用于将 CoreDNS 配置为将 DNS 消息代理到默认(".")服务器的情况(如果未指定此字段),则使用上游将默认为 /etc/resolv.conf,策略 "sequential"

10.1.2. .spec.cache

描述
cache 描述了适用于 Corefile 中列出的所有服务器块的缓存配置。此字段允许集群管理员选择性地配置:* positiveTTL,它是一个应缓存正响应的持续时间。* 负TTL,这是应缓存负响应的持续时间。如果没有配置,OpenShift 将使用可能会更改的默认值配置正和负缓存。在编写本文时,默认的 positiveTTL 是 900 秒,默认的负TTL 为 30 秒,或者在您的 OpenShift 版本对应的 Corefile 中记录。
类型
object
属性类型描述

negativeTTL

string

negativeTTL 是可选的,指定应缓存负响应的时间长度。如果配置,它必须是 1s (1 秒)或大于理论最多的数年值。此字段需要未签名的持续时间字符串为十进制数字,每个数字都有可选的 fraction 和一个单元后缀,如。"100s", "1m30s", "12h30m10s".值为一秒的分数值将舍入到最接近的秒。如果配置的值小于 1s,则使用默认值。如果没有配置,则该值为 0,OpenShift 将使用默认值 30 秒,除非在相应 OpenShift 版本的 Corefile 中另有说明。默认值 30 秒可能会改变。

positiveTTL

string

positiveTTL 是可选的,指定应缓存正响应的时间长度。如果配置,它必须是 1s (1 秒)或大于理论最多的数年值。此字段需要未签名的持续时间字符串为十进制数字,每个数字都有可选的 fraction 和一个单元后缀,如。"100s", "1m30s", "12h30m10s".值为一秒的分数值将舍入到最接近的秒。如果配置的值小于 1s,则使用默认值。如果没有配置,则该值为 0s,OpenShift 将使用默认值 900 秒,除非在相应 OpenShift 版本的 Corefile 中另有说明。900 秒的默认值可能会改变。

10.1.3. .spec.nodePlacement

描述
nodePlacement 提供对 DNS pod 调度的明确控制。通常,在每个节点上运行 DNS pod,以便 DNS 查询始终由本地 DNS pod 处理,而不是通过网络传输到另一个节点上的 DNS pod。但是,安全策略可能需要将 DNS pod 的放置限制到特定的节点。例如,如果安全策略禁止任意节点上的 pod 与 API 通信,则可以指定节点选择器,将 DNS pod 限制到允许与 API 通信的节点。相反,如果需要在具有特定污点的节点上运行 DNS pod,可以为该污点指定容限。如果未设置,则使用默认值。如需了解更多详细信息,请参阅 nodePlacement。
类型
object
属性类型描述

nodeSelector

对象(字符串)

nodeSelector 是应用到 DNS pod 的节点选择器。如果为空,则使用默认值,它目前如下:kubernetes.io/os: linux,这是可能会更改的。如果设置,则使用指定的选择器并替换默认值。

容限(tolerations)

array

tolerations 是应用到 DNS pod 的容限列表。如果为空,DNS 操作器会为 "node-role.kubernetes.io/master" 污点设置容限。这个默认设置可能会改变。在没有包括 "node-role.kubernetes.io/master" 污点的容限的情况下指定容限可能会带来风险,因为在所有 worker 节点都不可用时可能会导致停机。请注意,守护进程控制器也会添加一些容限。请参阅 https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/

tolerations[]

对象

此 Toleration 附加到 pod,以使用匹配的 operator <operator> 容许与 triple <key,value,effect> 匹配的任何污点。

10.1.4. .spec.nodePlacement.tolerations

描述
tolerations 是应用到 DNS pod 的容限列表。如果为空,DNS 操作器会为 "node-role.kubernetes.io/master" 污点设置容限。这个默认设置可能会改变。在没有包括 "node-role.kubernetes.io/master" 污点的容限的情况下指定容限可能会带来风险,因为在所有 worker 节点都不可用时可能会导致停机。请注意,守护进程控制器也会添加一些容限。请参阅 https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/
类型
array

10.1.5. .spec.nodePlacement.tolerations[]

描述
此 Toleration 附加到 pod,以使用匹配的 operator <operator> 容许与 triple <key,value,effect> 匹配的任何污点。
类型
object
属性类型描述

effect

字符串

effect 表示要匹配的污点效果。空意味着匹配所有污点效果。指定后,允许的值为 NoSchedule,PreferNoSchedule 和 NoExecute。

key

字符串

key 是容限应用到的污点键。empty 表示与所有污点键匹配。如果键为空,则必须存在运算符;组合意味着匹配所有值和所有键。

operator

字符串

Operator 代表键与值的关系。有效的运算符是 Exists 和 Equal。默认值为 Equal。exists 等同于值的通配符,以便 pod 可以容忍特定类别的所有污点。

tolerationSeconds

整数

tolerationSeconds 代表容限的期间(必须生效 NoExecute,否则此字段将被忽略)可以容忍污点。默认情况下,它不会被设置,这意味着容许任何污点(不要驱除)。零值和负值将被视为 0 (立即删除)。

value

字符串

value 是容限匹配的污点值。如果运算符是 Exists,则该值应该为空,否则仅是一个常规字符串。

10.1.6. .spec.servers

描述
服务器是 DNS 解析器列表,它为集群域范围之外的一个或多个子域提供名称查询委托。如果服务器由多个服务器组成,则将使用最长后缀匹配来确定服务器。例如,如果有两个服务器,一个用于 "foo.com",另一个用于 "a.foo.com",名称查询是 "www.a.foo.com",它将路由到带有 Zone "a.foo.com" 的 Server。如果此字段为 nil,则不会创建服务器。
类型
array

10.1.7. .spec.servers[]

描述
服务器定义每个 CoreDNS 实例运行的服务器的 schema。
类型
object
属性类型描述

forwardPlugin

对象

forwardPlugin 定义了一个模式,用于将 CoreDNS 配置为将 DNS 信息代理到上游解析器。

name

字符串

name 是必需的,并指定服务器的唯一名称。name 必须符合 rfc6335 的 Service Name 语法。

zones

数组(字符串)

zones 是必需的,并指定服务器对其具有权威的子域。zones 必须符合子域的 rfc1123 定义。指定集群域(例如,"cluster.local")无效。

10.1.8. .spec.servers[].forwardPlugin

描述
forwardPlugin 定义了一个模式,用于将 CoreDNS 配置为将 DNS 信息代理到上游解析器。
类型
object
属性类型描述

policy

string

策略用于决定选择上游服务器进行查询的顺序。可以指定以下值之一:*"Random"为每个查询选择一个随机的上游服务器。* "robin" 以轮循顺序选择上游服务器,移动到每个新查询的下一服务器。* "sequential" 会尝试以顺序顺序查询上游服务器,直到一个响应,从第一个服务器开始进行每个新查询。默认值为 "Random"

protocolStrategy

string

protocolStrategy 指定用于上游 DNS 请求的协议。protocolStrategy 的有效值为 "TCP" 并省略。省略时,这意味着没有建议,平台会被保留选择合理的默认值,这可能会随时间变化。当前的默认值是使用原始客户端请求的协议。"TCP"指定平台应对所有上游 DNS 请求使用 TCP,即使客户端请求使用了 UDP。"TCP"对于特定于 UDP 的问题(如由不合规的上游解析器创建)非常有用,但可能会消耗更多带宽或增加 DNS 响应时间。请注意,protocolStrategy 只会影响 CoreDNS 向上游解析器进行的 DNS 请求的协议。它不会影响客户端和 CoreDNS 之间的 DNS 请求的协议。

transportConfig

object

transportConfig 用于配置传输类型、服务器名称和可选的自定义 CA 或 CA 捆绑包,以便在将 DNS 请求转发到上游解析器时使用。默认值为 "" (空),这会导致在将 DNS 请求转发到上游解析器时使用的标准明文连接。

upstreams

数组(字符串)

upstreams 是为区域子域转发名称查询的解析器列表。CoreDNS 的每个实例都执行 Upstreams 的健康检查。当一个健康的上游在交换过程中返回错误时,会从 Upstreams 试图另一个解析器。Upstreams 按照 Policy 中指定的顺序选择。如果上游监听 53 之外的端口,则每个上游都由 IP 地址或 IP:port 表示。每个 ForwardPlugin 最多允许 15 个 upstreams。

10.1.9. .spec.servers[].forwardPlugin.transportConfig

描述
transportConfig 用于配置传输类型、服务器名称和可选的自定义 CA 或 CA 捆绑包,以便在将 DNS 请求转发到上游解析器时使用。默认值为 "" (空),这会导致在将 DNS 请求转发到上游解析器时使用的标准明文连接。
类型
object
属性类型描述

tls

object

TLS 包含将 Transport 设置为 "TLS" 时使用的附加配置选项。

传输

string

通过传输,集群管理员可以选择在集群 DNS 和上游解析器之间使用 DNS-over-TLS 连接。在没有配置 CABundle 的情况下将 TLS 配置为传输会导致系统证书用于验证上游解析器的服务证书。可能的值有: "" (empty)- 这意味着没有明确的选择,平台会选择可能会随时间变化的默认值。当前默认为 "Cleartext"。"cleartext" - Cluster admin 指定明文选项。这会导致功能与空值相同,但当集群管理员想要更明确地了解传输时,或者希望明确从 "TLS" 切换到 "Cleartext" 时,可能会很有用。"TLS" - 这表示 DNS 查询应该通过 TLS 连接发送。如果传输设置为 TLS,则必须同时设置 ServerName。如果上游 IP 不包含端口,则根据 RFC 7858 第 3.1 节 https://datatracker.ietf.org/doc/html/rfc7858#section-3.1,默认尝试端口 853。

10.1.10. .spec.servers[].forwardPlugin.transportConfig.tls

描述
TLS 包含将 Transport 设置为 "TLS" 时使用的附加配置选项。
类型
object
必填
  • serverName
属性类型描述

caBundle

object

CABundle 引用必须包含单个 CA 证书或 CA 捆绑包的 ConfigMap。这允许集群管理员提供自己的 CA 或 CA 捆绑包来验证上游解析器的证书。1.configmap 必须包含 ca-bundle.crt 键。2.该值必须是 PEM 编码的 CA 证书或 CA 捆绑包。3.管理员必须在 openshift-config 命名空间中创建此 configmap。4.上游服务器证书必须包含与 ServerName 匹配的主题备用名称(SAN)。

serverName

string

ServerName 是在转发 DNS 查询时要连接的上游服务器。当将 Transport 设置为 "TLS" 时,需要此项。ServerName 将根据 RFC 1123 中的 DNS 命名约定进行验证,并且应与上游解析器中安装的 TLS 证书匹配。

10.1.11. .spec.servers[].forwardPlugin.transportConfig.tls.caBundle

描述
CABundle 引用必须包含单个 CA 证书或 CA 捆绑包的 ConfigMap。这允许集群管理员提供自己的 CA 或 CA 捆绑包来验证上游解析器的证书。1.configmap 必须包含 ca-bundle.crt 键。2.该值必须是 PEM 编码的 CA 证书或 CA 捆绑包。3.管理员必须在 openshift-config 命名空间中创建此 configmap。4.上游服务器证书必须包含与 ServerName 匹配的主题备用名称(SAN)。
类型
object
必填
  • name
属性类型描述

name

字符串

name 是引用的配置映射的 metadata.name

10.1.12. .spec.upstreamResolvers

描述
upstreamResolver 定义了一个模式,用于将 CoreDNS 配置为将 DNS 消息代理到默认(".")服务器的情况(如果未指定此字段),则使用上游将默认为 /etc/resolv.conf,策略 "sequential"
类型
object
属性类型描述

policy

string

策略用于决定选择上游服务器进行查询的顺序。可以指定以下值之一:*"Random"为每个查询选择一个随机的上游服务器。* "robin" 以轮循顺序选择上游服务器,移动到每个新查询的下一服务器。* "sequential" 会尝试以顺序顺序查询上游服务器,直到一个响应,从第一个服务器开始进行每个新查询。默认值为 "Sequential"

protocolStrategy

string

protocolStrategy 指定用于上游 DNS 请求的协议。protocolStrategy 的有效值为 "TCP" 并省略。省略时,这意味着没有建议,平台会被保留选择合理的默认值,这可能会随时间变化。当前的默认值是使用原始客户端请求的协议。"TCP"指定平台应对所有上游 DNS 请求使用 TCP,即使客户端请求使用了 UDP。"TCP"对于特定于 UDP 的问题(如由不合规的上游解析器创建)非常有用,但可能会消耗更多带宽或增加 DNS 响应时间。请注意,protocolStrategy 只会影响 CoreDNS 向上游解析器进行的 DNS 请求的协议。它不会影响客户端和 CoreDNS 之间的 DNS 请求的协议。

transportConfig

object

transportConfig 用于配置传输类型、服务器名称和可选的自定义 CA 或 CA 捆绑包,以便在将 DNS 请求转发到上游解析器时使用。默认值为 "" (空),这会导致在将 DNS 请求转发到上游解析器时使用的标准明文连接。

upstreams

数组

upstreams 是向 "." 域转发名称查询的解析器列表。CoreDNS 的每个实例都执行 Upstreams 的健康检查。当一个健康的上游在交换过程中返回错误时,会从 Upstreams 试图另一个解析器。Upstreams 按照 Policy 中指定的顺序选择。每个 ForwardPlugin 最多允许 15 个 upstreams。如果没有指定 Upstreams,则默认使用 /etc/resolv.conf

upstreams[]

object

上游可以类型为 SystemResolvConf,或者类型为 Network。- 对于 Upstream 类型的 SystemResolvConf,则不需要进一步的字段:上游将配置为使用 /etc/resolv.conf。- 对于 Upstream 类型的 Network,如果上游侦听一个端口,则 NetworkResolver 字段需要使用 IP 地址或 IP:port 定义(如果上游侦听一个端口不是 53 的端口)。

10.1.13. .spec.upstreamResolvers.transportConfig

描述
transportConfig 用于配置传输类型、服务器名称和可选的自定义 CA 或 CA 捆绑包,以便在将 DNS 请求转发到上游解析器时使用。默认值为 "" (空),这会导致在将 DNS 请求转发到上游解析器时使用的标准明文连接。
类型
object
属性类型描述

tls

object

TLS 包含将 Transport 设置为 "TLS" 时使用的附加配置选项。

传输

string

通过传输,集群管理员可以选择在集群 DNS 和上游解析器之间使用 DNS-over-TLS 连接。在没有配置 CABundle 的情况下将 TLS 配置为传输会导致系统证书用于验证上游解析器的服务证书。可能的值有: "" (empty)- 这意味着没有明确的选择,平台会选择可能会随时间变化的默认值。当前默认为 "Cleartext"。"cleartext" - Cluster admin 指定明文选项。这会导致功能与空值相同,但当集群管理员想要更明确地了解传输时,或者希望明确从 "TLS" 切换到 "Cleartext" 时,可能会很有用。"TLS" - 这表示 DNS 查询应该通过 TLS 连接发送。如果传输设置为 TLS,则必须同时设置 ServerName。如果上游 IP 不包含端口,则根据 RFC 7858 第 3.1 节 https://datatracker.ietf.org/doc/html/rfc7858#section-3.1,默认尝试端口 853。

10.1.14. .spec.upstreamResolvers.transportConfig.tls

描述
TLS 包含将 Transport 设置为 "TLS" 时使用的附加配置选项。
类型
object
必填
  • serverName
属性类型描述

caBundle

object

CABundle 引用必须包含单个 CA 证书或 CA 捆绑包的 ConfigMap。这允许集群管理员提供自己的 CA 或 CA 捆绑包来验证上游解析器的证书。1.configmap 必须包含 ca-bundle.crt 键。2.该值必须是 PEM 编码的 CA 证书或 CA 捆绑包。3.管理员必须在 openshift-config 命名空间中创建此 configmap。4.上游服务器证书必须包含与 ServerName 匹配的主题备用名称(SAN)。

serverName

string

ServerName 是在转发 DNS 查询时要连接的上游服务器。当将 Transport 设置为 "TLS" 时,需要此项。ServerName 将根据 RFC 1123 中的 DNS 命名约定进行验证,并且应与上游解析器中安装的 TLS 证书匹配。

10.1.15. .spec.upstreamResolvers.transportConfig.tls.caBundle

描述
CABundle 引用必须包含单个 CA 证书或 CA 捆绑包的 ConfigMap。这允许集群管理员提供自己的 CA 或 CA 捆绑包来验证上游解析器的证书。1.configmap 必须包含 ca-bundle.crt 键。2.该值必须是 PEM 编码的 CA 证书或 CA 捆绑包。3.管理员必须在 openshift-config 命名空间中创建此 configmap。4.上游服务器证书必须包含与 ServerName 匹配的主题备用名称(SAN)。
类型
object
必填
  • name
属性类型描述

name

字符串

name 是引用的配置映射的 metadata.name

10.1.16. .spec.upstreamResolvers.upstreams

描述
upstreams 是向 "." 域转发名称查询的解析器列表。CoreDNS 的每个实例都执行 Upstreams 的健康检查。当一个健康的上游在交换过程中返回错误时,会从 Upstreams 试图另一个解析器。Upstreams 按照 Policy 中指定的顺序选择。每个 ForwardPlugin 最多允许 15 个 upstreams。如果没有指定 Upstreams,则默认使用 /etc/resolv.conf
类型
数组

10.1.17. .spec.upstreamResolvers.upstreams[]

描述
上游可以类型为 SystemResolvConf,或者类型为 Network。- 对于 Upstream 类型的 SystemResolvConf,则不需要进一步的字段:上游将配置为使用 /etc/resolv.conf。- 对于 Upstream 类型的 Network,如果上游侦听一个端口,则 NetworkResolver 字段需要使用 IP 地址或 IP:port 定义(如果上游侦听一个端口不是 53 的端口)。
类型
object
必填
  • type
属性类型描述

address

string

当 Type 设为 Network 时,必须定义地址。否则它将会被忽略。它必须是有效的 ipv4 或 ipv6 地址。

port

整数

当 Type 设为 Network 时,可以定义端口。否则它将会被忽略。端口必须在 65535 之间

type

string

type 定义此上游是否包含 IP/IP:port 解析器或本地 /etc/resolv.conf。type 接受 2 可能的值: SystemResolvConf 或 Network。* 当使用 SystemResolvConf 时,Upstream 结构不需要定义任何其他字段:/etc/resolv.conf 将使用 * when Network 时,Upstream 结构必须至少包含一个地址

10.1.18. .status

描述
Status 是 DNS 最近观察到的状态。
类型
object
必填
  • clusterDomain
  • clusterIP
属性类型描述

clusterDomain

字符串

clusterDomain 是 DNS 服务的本地集群 DNS 域后缀。这将是 RFC 1034 中定义的子域,第 3.5 节: https://tools.ietf.org/html/rfc1034#section-3.5 示例: "cluster.local" more info: https://kubernetes.io/docs/concepts/services-networking/dns-pod-service

clusterIP

字符串

ClusterIP 是提供此 DNS 的服务 IP。如果是默认的 DNS,它将是一个已知的 IP,用作使用默认 ClusterFirst DNS 策略的 pod 的默认名称服务器。通常,此 IP 可以在 pod 的 spec.dnsConfig.nameservers 列表中指定,或者在从集群中执行名称解析时明确使用。示例:dig foo.com @<service IP> 更多信息: https://kubernetes.io/docs/concepts/services-networking/service/#virtual-ips-and-service-proxies

conditions

array

条件提供有关集群中 DNS 状态的信息。这些是支持的 DNS 条件:在满足以下条件时为 Available - True :如果有任何条件不满意,则为 False。

conditions[]

对象

OperatorCondition 只是标准条件字段。

10.1.19. .status.conditions

描述
条件提供有关集群中 DNS 状态的信息。这些是支持的 DNS 条件:在满足以下条件时为 Available - True :如果有任何条件不满意,则为 False。
类型
array

10.1.20. .status.conditions[]

描述
OperatorCondition 只是标准条件字段。
类型
object
必填
  • type
属性类型描述

lastTransitionTime

字符串

 

message

字符串

 

reason

字符串

 

status

字符串

 

type

字符串

 
Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

© 2024 Red Hat, Inc.