8.9. 高级任务
8.9.1. 更改 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
以应用临时解决方案。
流程
在 DNS Operator 中将
managementState
更改为Unmanaged
:oc patch dns.operator.openshift.io default --type merge --patch '{"spec":{"managementState":"Unmanaged"}}'
使用
jsonpath
命令行 JSON 解析器查看 DNS Operator 的managementState
:$ oc get dns.operator.openshift.io default -ojsonpath='{.spec.managementState}'
输出示例
"Unmanaged"
当 managementState
设置为 Unmanaged
时,您无法升级。
8.9.2. 控制 DNS pod 放置
DNS Operator 有两个守护进程集:一个用于 CoreDNS,名为 dns-default
,另一个用于管理 名为 node-resolver
的 /etc/hosts
文件。
您可能会发现,需要控制哪些节点已分配并运行了 CoreDNS pod,尽管这不是一个常见操作。例如,如果集群管理员配置了可以禁止节点对节点间通信的安全策略,这需要限制 CoreDNS 运行 daemonset 的节点集合。如果 DNS pod 在集群中的某些节点上运行,且没有运行 DNS pod 的节点与运行 DNS pod 的节点具有网络连接,则 DNS 服务将适用于所有 pod。
node-resolver
守护进程集必须在每个节点主机上运行,因为它为集群镜像 registry 添加一个条目来支持拉取镜像。node-resolver
pod 只有一个作业:查找 image-registry.openshift-image-registry.svc
服务的集群 IP 地址,并将其添加到节点主机上的 /etc/hosts
中,以便容器运行时可以解析服务名称。
作为集群管理员,您可以使用自定义节点选择器将 CoreDNS 的守护进程集配置为在某些节点上运行或不运行。
先决条件
-
已安装
oc
CLI。 -
以具有
cluster-admin
权限的用户身份登录集群。 -
您的 DNS Operator
managementState
设置为Managed
。
流程
要允许 CoreDNS 的守护进程集在特定节点上运行,请配置污点和容限:
修改名为
default
的 DNS Operator 对象:$ oc edit dns.operator/default
为污点指定污点键和一个容忍度:
spec: nodePlacement: tolerations: - effect: NoExecute key: "dns-only" operators: Equal value: abc tolerationSeconds: 3600 1
- 1
- 如果污点是
dns-only
,它可以无限期地被容许。您可以省略tolerationSeconds
。
8.9.3. 使用 TLS 配置 DNS 转发
在高度监管的环境中工作时,您可能需要在将请求转发到上游解析器时保护 DNS 流量,以便您可以确保额外的 DNS 流量和数据隐私。
请注意,CoreDNS 缓存在 10 秒内转发连接。如果没有请求,CoreDNS 将为该 10 秒打开 TCP 连接。对于大型集群,请确保您的 DNS 服务器知道可能有多个新的连接来保存打开,因为您可以在每个节点上启动连接。相应地设置 DNS 层次结构以避免性能问题。
流程
修改名为
default
的 DNS Operator 对象:$ oc edit dns.operator/default
集群管理员可以配置传输层安全(TLS)来转发 DNS 查询。
使用 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 时,只允许
网络
类型,且您必须提供 IP 地址。网络
类型表示,该上游解析器应该独立于/etc/resolv.conf
中列出的上游解析器单独处理转发请求。 - 9
address
字段必须是有效的 IPv4 或 IPv6 地址。- 10
- 您可以选择提供端口。
port
必须是1
到65535
之间的值。如果您没有为上游指定端口,则默认端口为 853。
注意如果
servers
未定义或无效,则配置映射只包括默认服务器。
验证
查看配置映射:
$ 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 守护进程集的滚动更新。
其他资源
- 有关 DNS 转发的详情,请查看 CoreDNS 转发文档。