3.5. 分发托管集群工作负载
在开始使用 OpenShift Container Platform 托管 control plane 之前,您必须正确标记节点,以便托管集群的 pod 可以调度到基础架构节点。节点标签也因以下原因非常重要:
-
确保高可用性和正确的工作负载部署。例如,为了避免将 control plane 工作负载计数放在 OpenShift Container Platform 订阅中,您可以设置
node-role.kubernetes.io/infra
标签。 - 确保 control plane 工作负载与管理集群中的其他工作负载分开。
确保 control plane 工作负载在正确的多租户分布级别进行配置。发布级别如下:
- 共享所有:托管集群的 Control plane 可以在为 control plane 指定的任何节点上运行。
- 请求服务隔离: Serving pod 在自己的专用节点上请求。
- 不共享:每个 control plane 都有自己的专用节点。
有关将节点专用于单个托管集群的更多信息,请参阅"标签管理集群节点"。
不要将管理集群用于工作负载。工作负载不能在运行 control plane 的节点上运行。
3.5.1. 标记管理集群节点 复制链接链接已复制到粘贴板!
正确的节点标签是部署托管 control plane 的先决条件。
作为管理集群管理员,您可以在管理集群节点中使用以下标签和污点来调度 control plane 工作负载:
-
HyperShift.openshift.io/control-plane: true
:使用此标签和污点将节点专用于运行托管的 control plane 工作负载。通过设置true
值,您可以避免与其他组件共享 control plane 节点,例如管理集群的基础架构组件或任何其他错误部署的工作负载。 -
HyperShift.openshift.io/cluster: ${HostedControlPlane Namespace}
: 当您要将节点专用于单个托管集群时,请使用此标签和污点。
在托管 control-plane pod 的节点上应用以下标签:
-
node-role.kubernetes.io/infra
: 使用该标签避免将 control-plane 工作负载计数设置为您的订阅。 topology.kubernetes.io/zone
:在管理集群节点上使用此标签在故障域中部署高可用性集群。区域可能是设置区的节点的位置、机架名称或主机名。例如,管理集群具有以下节点:worker-1a
、worker-1b
、worker-2a、worker-2a
和worker-2b
。worker-1a
和worker-1b
节点位于rack1
中,worker-2a
和 worker-2b 节点位于rack2
中。要将每个机架用作可用区,请输入以下命令:oc label node/worker-1a node/worker-1b topology.kubernetes.io/zone=rack1
$ oc label node/worker-1a node/worker-1b topology.kubernetes.io/zone=rack1
Copy to Clipboard Copied! Toggle word wrap Toggle overflow oc label node/worker-2a node/worker-2b topology.kubernetes.io/zone=rack2
$ oc label node/worker-2a node/worker-2b topology.kubernetes.io/zone=rack2
Copy to Clipboard Copied! Toggle word wrap Toggle overflow
托管集群的 Pod 具有容限,调度程序使用关联性规则来调度它们。Pod 容限污点用于 control-plane
和 cluster
用于 pod。调度程序将 pod 调度到标记为 hypershift.openshift.io/control-plane
和 hypershift.openshift.io/cluster: ${HostedControlPlane Namespace}
的节点。
对于 ControllerAvailabilityPolicy
选项,请使用 HighlyAvailable
,这是托管 control plane 命令行界面 hcp
部署的默认值。使用该选项时,您可以通过将 topology.kubernetes.io/zone
设置为拓扑键,将托管集群中每个部署的 pod 调度到不同的故障域中。在跨不同故障域的托管集群中为部署调度 pod,仅适用于高可用性 control plane。
流程
要让托管集群要求其 pod 调度到基础架构节点,请设置 HostedCluster.spec.nodeSelector
,如下例所示:
spec: nodeSelector: node-role.kubernetes.io/infra: ""
spec:
nodeSelector:
node-role.kubernetes.io/infra: ""
这样,每个托管的集群的托管 control plane 都是符合基础架构节点工作负载,您不需要授权底层 OpenShift Container Platform 节点。
3.5.2. 优先级类 复制链接链接已复制到粘贴板!
四个内置优先级类会影响托管集群 pod 的优先级与抢占。您可以根据从高到低的顺序在管理集群中创建 pod:
-
hypershift-operator
: HyperShift Operator pod. -
hypershift-etcd
: etcd 的 Pod -
HyperShift-api-critical
: API 调用和资源准入所需的 Pod 才能成功。这些 pod 包括kube-apiserver
、聚合的 API 服务器和 web hook 等 pod。 -
HyperShift-control-plane
: control plane 中不是 API-critical 但仍然需要升级的优先级的 Pod,如集群版本 Operator。
3.5.3. 自定义污点和容限 复制链接链接已复制到粘贴板!
默认情况下,托管集群的 pod 可以容忍 control-plane
和 cluster
污点。但是,您还可以在节点上使用自定义污点,以便托管集群可以通过设置 HostedCluster.spec.tolerations
来容许每个托管的集群的污点。
为托管集群传递容限只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议(SLA)支持,且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能,并有机会在开发阶段提供反馈意见。
有关红帽技术预览功能支持范围的更多信息,请参阅技术预览功能支持范围。
配置示例
spec: tolerations: - effect: NoSchedule key: kubernetes.io/custom operator: Exists
spec:
tolerations:
- effect: NoSchedule
key: kubernetes.io/custom
operator: Exists
您还可以使用 --tolerations
hcp CLI 参数,在创建集群时在托管集群上设置容限。
CLI 参数示例
--toleration="key=kubernetes.io/custom,operator=Exists,effect=NoSchedule"
--toleration="key=kubernetes.io/custom,operator=Exists,effect=NoSchedule"
要基于每个集群对托管集群 pod 放置进行精细控制,请使用 nodeSelectors
的自定义容限。您可以并置托管集群的组,并将它们与其他托管集群隔离。您还可以将托管集群放在 infra 和 control plane 节点上。
托管的集群中的容限只适用于 control plane 的 pod。要配置在管理集群和基础架构相关的 pod (如运行虚拟机的 pod)上运行的其他 pod,您需要使用不同的进程。
3.5.4. control plane 隔离 复制链接链接已复制到粘贴板!
您可以配置托管的 control plane 来隔离网络流量或 control plane pod。
3.5.4.1. 网络策略隔离 复制链接链接已复制到粘贴板!
每个托管的 control plane 都分配到一个专用的 Kubernetes 命名空间中运行。默认情况下,Kubernetes 命名空间拒绝所有网络流量。
以下网络流量可以通过 Kubernetes Container Network Interface (CNI) 强制的网络策略进行:
- 同一命名空间中的 Ingress pod 到 pod 通信(Ttra-tenant)
-
对租户托管的
kube-apiserver
pod 的端口 6443 的入站流量 -
允许使用
network.openshift.io/policy-group: monitoring
标签从管理集群 Kubernetes 命名空间提取指标
3.5.4.2. control plane pod 隔离 复制链接链接已复制到粘贴板!
除了网络策略外,每个托管的 control plane pod 都使用 restricted
安全上下文约束运行。此策略拒绝访问所有主机功能,并要求 pod 使用 UID 运行,并且 SELinux 上下文分配给托管客户 control plane 的每个命名空间。
策略确保以下限制:
- Pod 不能以特权方式运行。
- Pod 不能挂载主机目录卷。
- Pod 必须以预先分配的 UID 范围内的用户身份运行。
- Pod 必须使用预先分配的 MCS 标签运行。
- Pod 不能访问主机网络命名空间。
- Pod 不能公开主机网络端口。
- Pod 不能访问主机 PID 命名空间。
-
默认情况下,pod 丢弃以下 Linux 功能:
KILL
、MKNOD
、SETUID
和SETGID
。
每个管理集群 worker 节点上的管理组件(如 kubelet
和 crio
)都由支持托管 control plane 的 pod 的 SELinux 上下文无法访问。
以下 SELinux 标签用于密钥进程和套接字:
-
kubelet:
system_u:system_r:unconfined_service_t:s0
-
crio:
system_u:system_r:container_runtime_t:s0
-
crio.sock:
system_u:object_r:container_var_run_t:s0
-
<example user container processes>:
system_u:system_r:container_t:s0:c14,c24