分发托管集群工作负载 - 托管控制平面部署准备 | 托管控制平面 | OpenShift Container Platform 4.17

标记管理集群节点
优先级类
自定义污点和容忍度

在开始使用OpenShift Container Platform的托管控制平面之前，必须正确标记节点，以便托管集群的Pod可以调度到基础设施节点。节点标记也很重要，原因如下：

确保高可用性和正确的负载部署。例如，您可以设置node-role.kubernetes.io/infra标签以避免将控制平面工作负载计入您的OpenShift Container Platform订阅。
确保控制平面工作负载与管理集群中的其他工作负载分开。

不要将管理集群用于您的工作负载。工作负载不得在运行控制平面的节点上运行。

标记管理集群节点

正确的节点标记是部署托管控制平面的前提条件。

作为管理集群管理员，您在管理集群节点中使用以下标签和污点来调度控制平面工作负载：

hypershift.openshift.io/control-plane: true：使用此标签和污点将节点专用于运行托管控制平面工作负载。通过设置值为true，您可以避免与其他组件共享控制平面节点，例如管理集群的基础设施组件或任何其他错误部署的工作负载。
hypershift.openshift.io/cluster: ${HostedControlPlane Namespace}：当您想将节点专用于单个托管集群时，使用此标签和污点。

在托管控制平面Pod的节点上应用以下标签：

node-role.kubernetes.io/infra：使用此标签以避免将控制平面工作负载计入您的订阅。
topology.kubernetes.io/zone：在管理集群节点上使用此标签，以便跨故障域部署高可用性集群。区域可能是位置、机架名称或设置区域的节点的主机名。例如，管理集群具有以下节点：worker-1a、worker-1b、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-2a node/worker-2b topology.kubernetes.io/zone=rack2
```

托管集群的Pod具有容忍度，调度程序使用亲和性规则来调度它们。Pod 容忍control-plane和Pod 的cluster的污点。调度程序优先将Pod 调度到标有hypershift.openshift.io/control-plane和hypershift.openshift.io/cluster: ${HostedControlPlane Namespace}的节点。

对于ControllerAvailabilityPolicy选项，请使用HighlyAvailable，这是托管控制平面命令行界面hcp部署的默认值。当您使用该选项时，您可以通过将topology.kubernetes.io/zone设置为拓扑键，跨不同故障域调度托管集群中每个部署的Pod。仅对于高可用性控制平面，才可以在不同故障域中调度托管集群中部署的Pod。

步骤

要启用托管集群要求其Pod调度到基础设施节点，请设置HostedCluster.spec.nodeSelector，如下例所示：

  spec:
    nodeSelector:
      role.kubernetes.io/infra: ""

这样，每个托管集群的托管控制平面都是合格的基础设施节点工作负载，您无需授权底层的 OpenShift Container Platform 节点。

优先级类

四个内置的优先级类会影响托管集群 Pod 的优先级和抢占。您可以按照从高到低的顺序在管理集群中创建 Pod：

hypershift-operator：HyperShift Operator Pod。
hypershift-etcd：etcd 的 Pod。
hypershift-api-critical：API 调用和资源准入成功所需的 Pod。这些 Pod 包括诸如kube-apiserver、聚合 API 服务器和 Webhook 等 Pod。
hypershift-control-plane：控制平面中并非 API 关键但仍需要较高优先级的 Pod，例如集群版本 Operator。

自定义污点和容忍

对于 OpenShift Virtualization 上的托管控制平面，默认情况下，托管集群的 Pod 会容忍control-plane和cluster污点。但是，您也可以在节点上使用自定义污点，以便托管集群可以通过设置HostedCluster.spec.tolerations来容忍这些污点（基于每个托管集群）。

为托管集群传递容忍度仅是技术预览功能。技术预览功能不受 Red Hat 生产服务等级协议 (SLA) 的支持，并且可能功能不完整。Red Hat 不建议在生产环境中使用它们。这些功能提供对即将推出的产品功能的早期访问，使客户能够在开发过程中测试功能并提供反馈。

有关 Red Hat 技术预览功能的支持范围的更多信息，请参阅技术预览功能支持范围。

示例配置

  spec:
    tolerations:
    - effect: NoSchedule
      key: kubernetes.io/custom
      operator: Exists

您也可以在创建集群时使用--tolerations hcp CLI 参数在托管集群上设置容忍度。

示例 CLI 参数

--toleration="key=kubernetes.io/custom,operator=Exists,effect=NoSchedule"

为了对托管集群 Pod 在每个托管集群的基础上进行更细粒度的控制，请将自定义容忍度与nodeSelectors一起使用。您可以将托管集群组共置并将其与其他托管集群隔离开。您还可以将托管集群放置在基础设施和控制平面节点中。

托管集群上的容忍度仅传播到控制平面的 Pod。要配置在管理集群上运行的其他 Pod 和与基础设施相关的 Pod（例如运行虚拟机的 Pod），您需要使用不同的流程。