第 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 定义对象的这个表示法的版本化的 schema。服务器应该将识别的模式转换为最新的内部值,并可拒绝未识别的值。更多信息: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#resources |
|
| kind 是一个字符串值,代表此对象所代表的 REST 资源。服务器可以从客户端向其提交请求的端点推断。无法更新。采用驼峰拼写法 (CamelCase)。更多信息: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#types-kinds |
| 标准对象元数据。更多信息: https://git.k8s.io/community/contributors/devel/sig-architecture/api-conventions.md#metadata | |
|
| spec 是 DNS 所需的行为的规格。 |
|
| Status 是 DNS 最近观察到的状态。 |
10.1.1. .spec
- 描述
- spec 是 DNS 所需的行为的规格。
- 类型
-
object
属性 | 类型 | 描述 |
---|---|---|
|
| cache 描述了适用于 Corefile 中列出的所有服务器块的缓存配置。此字段允许集群管理员选择性地配置:* positiveTTL,它是一个应缓存正响应的持续时间。* 负TTL,这是应缓存负响应的持续时间。如果没有配置,OpenShift 将使用可能会更改的默认值配置正和负缓存。在编写本文时,默认的 positiveTTL 是 900 秒,默认的负TTL 为 30 秒,或者在您的 OpenShift 版本对应的 Corefile 中记录。 |
|
| Loglevel 描述了 CoreDNS 所需的日志详细程度。可以指定以下值之一: 上游解析器中的普通日志错误。* 调试日志错误、NXDOMAIN 响应和 NODATA 响应。* 跟踪日志错误和所有响应。设置 logLevel: Trace 将生成非常详细的日志。有效值为:"Normal", "Debug", "Trace"。默认值为 "Normal"。 |
|
| managementState 指明 DNS 操作器是否应该管理集群 DNS |
|
| nodePlacement 提供对 DNS pod 调度的明确控制。通常,在每个节点上运行 DNS pod,以便 DNS 查询始终由本地 DNS pod 处理,而不是通过网络传输到另一个节点上的 DNS pod。但是,安全策略可能需要将 DNS pod 的放置限制到特定的节点。例如,如果安全策略禁止任意节点上的 pod 与 API 通信,则可以指定节点选择器,将 DNS pod 限制到允许与 API 通信的节点。相反,如果需要在具有特定污点的节点上运行 DNS pod,可以为该污点指定容限。如果未设置,则使用默认值。如需了解更多详细信息,请参阅 nodePlacement。 |
|
| operatorLogLevel 控制 DNS Operator 的日志记录级别。有效值为:"Normal", "Debug", "Trace"。默认为 "Normal"。设置 operatorLogLevel: Trace 将生成非常详细的日志。 |
|
| 服务器是 DNS 解析器列表,它为集群域范围之外的一个或多个子域提供名称查询委托。如果服务器由多个服务器组成,则将使用最长后缀匹配来确定服务器。例如,如果有两个服务器,一个用于 "foo.com",另一个用于 "a.foo.com",名称查询是 "www.a.foo.com",它将路由到带有 Zone "a.foo.com" 的 Server。如果此字段为 nil,则不会创建服务器。 |
|
| 服务器定义每个 CoreDNS 实例运行的服务器的 schema。 |
|
| 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 是可选的,指定应缓存负响应的时间长度。如果配置,它必须是 1s (1 秒)或大于理论最多的数年值。此字段需要未签名的持续时间字符串为十进制数字,每个数字都有可选的 fraction 和一个单元后缀,如。"100s", "1m30s", "12h30m10s".值为一秒的分数值将舍入到最接近的秒。如果配置的值小于 1s,则使用默认值。如果没有配置,则该值为 0,OpenShift 将使用默认值 30 秒,除非在相应 OpenShift 版本的 Corefile 中另有说明。默认值 30 秒可能会改变。 |
|
| 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 是应用到 DNS pod 的节点选择器。如果为空,则使用默认值,它目前如下:kubernetes.io/os: linux,这是可能会更改的。如果设置,则使用指定的选择器并替换默认值。 |
|
| 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/ |
|
| 此 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 表示要匹配的污点效果。空意味着匹配所有污点效果。指定后,允许的值为 NoSchedule,PreferNoSchedule 和 NoExecute。 |
|
| key 是容限应用到的污点键。empty 表示与所有污点键匹配。如果键为空,则必须存在运算符;组合意味着匹配所有值和所有键。 |
|
| Operator 代表键与值的关系。有效的运算符是 Exists 和 Equal。默认值为 Equal。exists 等同于值的通配符,以便 pod 可以容忍特定类别的所有污点。 |
|
| tolerationSeconds 代表容限的期间(必须生效 NoExecute,否则此字段将被忽略)可以容忍污点。默认情况下,它不会被设置,这意味着容许任何污点(不要驱除)。零值和负值将被视为 0 (立即删除)。 |
|
| 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 定义了一个模式,用于将 CoreDNS 配置为将 DNS 信息代理到上游解析器。 |
|
| name 是必需的,并指定服务器的唯一名称。name 必须符合 rfc6335 的 Service Name 语法。 |
|
| zones 是必需的,并指定服务器对其具有权威的子域。zones 必须符合子域的 rfc1123 定义。指定集群域(例如,"cluster.local")无效。 |
10.1.8. .spec.servers[].forwardPlugin
- 描述
- forwardPlugin 定义了一个模式,用于将 CoreDNS 配置为将 DNS 信息代理到上游解析器。
- 类型
-
object
属性 | 类型 | 描述 |
---|---|---|
|
| 策略用于决定选择上游服务器进行查询的顺序。可以指定以下值之一:*"Random"为每个查询选择一个随机的上游服务器。* "robin" 以轮循顺序选择上游服务器,移动到每个新查询的下一服务器。* "sequential" 会尝试以顺序顺序查询上游服务器,直到一个响应,从第一个服务器开始进行每个新查询。默认值为 "Random" |
|
| protocolStrategy 指定用于上游 DNS 请求的协议。protocolStrategy 的有效值为 "TCP" 并省略。省略时,这意味着没有建议,平台会被保留选择合理的默认值,这可能会随时间变化。当前的默认值是使用原始客户端请求的协议。"TCP"指定平台应对所有上游 DNS 请求使用 TCP,即使客户端请求使用了 UDP。"TCP"对于特定于 UDP 的问题(如由不合规的上游解析器创建)非常有用,但可能会消耗更多带宽或增加 DNS 响应时间。请注意,protocolStrategy 只会影响 CoreDNS 向上游解析器进行的 DNS 请求的协议。它不会影响客户端和 CoreDNS 之间的 DNS 请求的协议。 |
|
| transportConfig 用于配置传输类型、服务器名称和可选的自定义 CA 或 CA 捆绑包,以便在将 DNS 请求转发到上游解析器时使用。默认值为 "" (空),这会导致在将 DNS 请求转发到上游解析器时使用的标准明文连接。 |
|
| 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 包含将 Transport 设置为 "TLS" 时使用的附加配置选项。 |
|
| 通过传输,集群管理员可以选择在集群 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 引用必须包含单个 CA 证书或 CA 捆绑包的 ConfigMap。这允许集群管理员提供自己的 CA 或 CA 捆绑包来验证上游解析器的证书。1.configmap 必须包含 |
|
| 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 是引用的配置映射的 metadata.name |
10.1.12. .spec.upstreamResolvers
- 描述
- upstreamResolver 定义了一个模式,用于将 CoreDNS 配置为将 DNS 消息代理到默认(".")服务器的情况(如果未指定此字段),则使用上游将默认为 /etc/resolv.conf,策略 "sequential"
- 类型
-
object
属性 | 类型 | 描述 |
---|---|---|
|
| 策略用于决定选择上游服务器进行查询的顺序。可以指定以下值之一:*"Random"为每个查询选择一个随机的上游服务器。* "robin" 以轮循顺序选择上游服务器,移动到每个新查询的下一服务器。* "sequential" 会尝试以顺序顺序查询上游服务器,直到一个响应,从第一个服务器开始进行每个新查询。默认值为 "Sequential" |
|
| protocolStrategy 指定用于上游 DNS 请求的协议。protocolStrategy 的有效值为 "TCP" 并省略。省略时,这意味着没有建议,平台会被保留选择合理的默认值,这可能会随时间变化。当前的默认值是使用原始客户端请求的协议。"TCP"指定平台应对所有上游 DNS 请求使用 TCP,即使客户端请求使用了 UDP。"TCP"对于特定于 UDP 的问题(如由不合规的上游解析器创建)非常有用,但可能会消耗更多带宽或增加 DNS 响应时间。请注意,protocolStrategy 只会影响 CoreDNS 向上游解析器进行的 DNS 请求的协议。它不会影响客户端和 CoreDNS 之间的 DNS 请求的协议。 |
|
| transportConfig 用于配置传输类型、服务器名称和可选的自定义 CA 或 CA 捆绑包,以便在将 DNS 请求转发到上游解析器时使用。默认值为 "" (空),这会导致在将 DNS 请求转发到上游解析器时使用的标准明文连接。 |
|
| upstreams 是向 "." 域转发名称查询的解析器列表。CoreDNS 的每个实例都执行 Upstreams 的健康检查。当一个健康的上游在交换过程中返回错误时,会从 Upstreams 试图另一个解析器。Upstreams 按照 Policy 中指定的顺序选择。每个 ForwardPlugin 最多允许 15 个 upstreams。如果没有指定 Upstreams,则默认使用 /etc/resolv.conf |
|
| 上游可以类型为 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 包含将 Transport 设置为 "TLS" 时使用的附加配置选项。 |
|
| 通过传输,集群管理员可以选择在集群 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 引用必须包含单个 CA 证书或 CA 捆绑包的 ConfigMap。这允许集群管理员提供自己的 CA 或 CA 捆绑包来验证上游解析器的证书。1.configmap 必须包含 |
|
| 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 是引用的配置映射的 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
-
属性 | 类型 | 描述 |
---|---|---|
|
| 当 Type 设为 Network 时,必须定义地址。否则它将会被忽略。它必须是有效的 ipv4 或 ipv6 地址。 |
|
| 当 Type 设为 Network 时,可以定义端口。否则它将会被忽略。端口必须在 65535 之间 |
|
| 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 是 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 是提供此 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 |
|
| 条件提供有关集群中 DNS 状态的信息。这些是支持的 DNS 条件:在满足以下条件时为 Available - True :如果有任何条件不满意,则为 False。 |
|
| OperatorCondition 只是标准条件字段。 |
10.1.19. .status.conditions
- 描述
- 条件提供有关集群中 DNS 状态的信息。这些是支持的 DNS 条件:在满足以下条件时为 Available - True :如果有任何条件不满意,则为 False。
- 类型
-
array
10.1.20. .status.conditions[]
- 描述
- OperatorCondition 只是标准条件字段。
- 类型
-
object
- 必填
-
type
-
属性 | 类型 | 描述 |
---|---|---|
|
| |
|
| |
|
| |
|
| |
|
|