第 18 章 单节点 OpenShift 上的工作负载分区


在资源有限制的环境中,如单节点 OpenShift 部署,最好为您自己的工作负载保留大多数 CPU 资源,并将 OpenShift Container Platform 配置为在主机中的固定 CPU 数量上运行。在这些环境中,管理工作负载(包括 control plane)需要配置为使用少于普通集群中可能默认的资源使用的资源。您可以隔离 OpenShift Container Platform 服务、集群管理工作负载和基础架构 pod 在保留的一组 CPU 上运行。

使用工作负载分区时,OpenShift Container Platform 用于集群管理的 CPU 资源被隔离为单一节点集群中的一组分区 CPU 资源。此分区将集群管理功能隔离到定义的 CPU 数量。所有集群管理功能都仅在该 cpuset 配置上运行。

单一节点集群的管理分区所需的最小保留 CPU 数量是四个 CPU Hyper 线程(HT)。组成基准 OpenShift Container Platform 安装和一组典型的附加 Operator 的 pod 集合会被注解,以包含在管理工作负载分区中。这些 pod 通常在最小大小 cpuset 配置内运行。包含一组接受管理 pod 之外的 Operator 或工作负载需要在那个分区中添加额外的 CPU HT。

工作负载分区使用 Kubernetes 的常规调度功能将用户工作负载与平台工作负载隔离开来,以管理可放入这些内核的 pod 数量,并避免混合了集群管理工作负载和用户工作负载。

在使用工作负载分区时,您必须安装 Performance Addon Operator 并应用性能配置集:

  • 工作负载分区将 OpenShift Container Platform 基础架构 pod 固定到定义的 cpuset 配置。
  • Performance Addon Operator 性能配置集将 systemd 服务固定到定义的 cpuset 配置中。
  • cpuset 配置必须匹配。

工作负载分区为每个定义的 CPU 池或 workload-type 增加了 <workload-type>.workload.openshift.io/cores 的新扩展资源。kubelet 在对应的资源而不是典型的 cpu 资源中的帐户由分配给池的 pod 公告这些新资源和 CPU 请求。启用工作负载分区时,<workload-type>.workload.openshift.io/cores 资源允许访问主机的 CPU 容量,而不仅仅是默认的 CPU 池。

18.1. 使用工作负载分区最大化 CPU 分配

在单节点 OpenShift 集群安装过程中,您必须启用工作负载分区。这限制了运行平台服务的内核数,从而最大程度提高应用程序有效负载的 CPU 内核。

注意

您只能在集群安装过程中启用工作负载分区。您不能在安装后禁用工作负载分区。但是,您可以通过更新您在性能配置集中定义的 cpu 值以及 MachineConfig 自定义资源 (CR) 中的相关 cpuset 值来重新配置工作负载分区。

  • 启用工作负载分区的 base64 编码的 CR,它包含管理工作负载受限制的 CPU 集。为 base64 中的 crio.confkubelet.conf 对特定于主机的值进行编码。必须调整此内容,以匹配集群性能配置集中指定的 CPU 集,且对于集群主机中的内核数必须准确。

    apiVersion: machineconfiguration.openshift.io/v1
    kind: MachineConfig
    metadata:
      labels:
        machineconfiguration.openshift.io/role: master
      name: 02-master-workload-partitioning
    spec:
      config:
        ignition:
          version: 3.2.0
        storage:
          files:
          - contents:
              source: data:text/plain;charset=utf-8;base64,W2NyaW8ucnVudGltZS53b3JrbG9hZHMubWFuYWdlbWVudF0KYWN0aXZhdGlvbl9hbm5vdGF0aW9uID0gInRhcmdldC53b3JrbG9hZC5vcGVuc2hpZnQuaW8vbWFuYWdlbWVudCIKYW5ub3RhdGlvbl9wcmVmaXggPSAicmVzb3VyY2VzLndvcmtsb2FkLm9wZW5zaGlmdC5pbyIKcmVzb3VyY2VzID0geyAiY3B1c2hhcmVzIiA9IDAsICJjcHVzZXQiID0gIjAtMSw1Mi01MyIgfQo=
            mode: 420
            overwrite: true
            path: /etc/crio/crio.conf.d/01-workload-partitioning
            user:
              name: root
          - contents:
              source: data:text/plain;charset=utf-8;base64,ewogICJtYW5hZ2VtZW50IjogewogICAgImNwdXNldCI6ICIwLTEsNTItNTMiCiAgfQp9Cg==
            mode: 420
            overwrite: true
            path: /etc/kubernetes/openshift-workload-pinning
            user:
              name: root
  • 在集群主机上配置时,/etc/crio/crio.conf.d/01-workload-partitioning 的内容应该类似如下:

    [crio.runtime.workloads.management]
    activation_annotation = "target.workload.openshift.io/management"
    annotation_prefix = "resources.workload.openshift.io"
    [crio.runtime.workloads.management.resources]
    cpushares = 0
    cpuset = "0-1, 52-53" 1
    1
    cpuset 值因安装而异。

    如果启用了超线程,请为每个内核指定两个线程。cpuset 值必须与您在性能配置集中的 spec.cpu.reserved 字段中定义的保留 CPU 匹配。

  • 在集群中配置时,/etc/kubernetes/openshift-workload-pinning 的内容应如下所示:

    {
      "management": {
        "cpuset": "0-1,52-53" 1
      }
    }
    1
    cpuset 必须与 /etc/crio/crio.conf.d/01-workload-partitioning 中的 cpuset 值匹配。
Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

© 2024 Red Hat, Inc.