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-1aworker-1b、worker-2a、worker-2aworker-2bworker-1aworker-1b 节点位于 rack1 中,worker-2a 和 worker-2b 节点位于 rack2 中。要将每个机架用作可用区,请输入以下命令:

    $ oc label node/worker-1a node/worker-1b topology.kubernetes.io/zone=rack1
    Copy to Clipboard Toggle word wrap
    $ oc label node/worker-2a node/worker-2b topology.kubernetes.io/zone=rack2
    Copy to Clipboard Toggle word wrap

托管集群的 Pod 具有容限,调度程序使用关联性规则来调度它们。Pod 容限污点用于 control-planecluster 用于 pod。调度程序将 pod 调度到标记为 hypershift.openshift.io/control-planehypershift.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: ""
Copy to Clipboard Toggle word wrap

这样,每个托管的集群的托管 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-planecluster 污点。但是,您还可以在节点上使用自定义污点,以便托管集群可以通过设置 HostedCluster.spec.tolerations 来容许每个托管的集群的污点。

重要

为托管集群传递容限只是一个技术预览功能。技术预览功能不受红帽产品服务等级协议(SLA)支持,且功能可能并不完整。红帽不推荐在生产环境中使用它们。这些技术预览功能可以使用户提早试用新的功能,并有机会在开发阶段提供反馈意见。

有关红帽技术预览功能支持范围的更多信息,请参阅技术预览功能支持范围

配置示例

  spec:
    tolerations:
    - effect: NoSchedule
      key: kubernetes.io/custom
      operator: Exists
Copy to Clipboard Toggle word wrap

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

CLI 参数示例

--toleration="key=kubernetes.io/custom,operator=Exists,effect=NoSchedule"
Copy to Clipboard Toggle word wrap

要基于每个集群对托管集群 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 功能: KILLMKNODSETUIDSETGID

每个管理集群 worker 节点上的管理组件(如 kubeletcrio )都由支持托管 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
返回顶部
Red Hat logoGithubredditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

Theme

© 2025 Red Hat