OpenShift 文档正在迁移，不久后将只在 docs.redhat.com（所有 Red Hat 产品文档的中心）提供。立即体验 新的文档体验。
  1. 文档
    2. history bug_report picture_as_pdf
×

推荐的控制平面实践

本主题提供了 OpenShift Container Platform 中控制平面的推荐性能和可扩展性实践。

本节中的指导原则仅适用于具有云提供商集成的安装。

应用以下最佳实践来扩展 OpenShift Container Platform 集群中的工作机器数量。通过增加或减少工作机器集中定义的副本数量来扩展工作机器。

当将集群扩展到更高的节点数量时

  • 将节点分布到所有可用区域以实现更高的可用性。

  • 一次最多扩展 25 到 50 台机器。

  • 考虑在每个可用区域中创建新的计算机器集，并使用大小相似的替代实例类型，以帮助减轻任何周期性的提供商容量限制。例如，在 AWS 上，使用 m5.large 和 m5d.large。

云提供商可能会对 API 服务实施配额。因此，请逐步扩展集群。

如果计算机器集中的副本一次全部设置为更高的数字，则控制器可能无法创建机器。OpenShift Container Platform 部署在其之上的云平台能够处理的请求数量会影响此过程。控制器在尝试创建、检查和更新机器状态时将开始查询更多信息。OpenShift Container Platform 部署在其之上的云平台具有 API 请求限制；过多的查询可能会由于云平台限制而导致机器创建失败。

在扩展到大量节点时启用机器健康检查。如果发生故障，健康检查会监控状况并自动修复不健康的机器。

当将大型密集集群缩放到较低的节点数量时，可能需要很长时间，因为此过程涉及并行地清空或逐出正在终止的节点上运行的对象。此外，如果要逐出的对象过多，客户端可能会开始限制请求。默认的客户端每秒查询数 (QPS) 和突发速率分别设置为50 和100。这些值无法在 OpenShift Container Platform 中修改。

控制平面节点的资源需求取决于集群中节点和对象的数量和类型。以下控制平面节点大小建议基于控制平面密度集中测试的结果，或称集群密度。此测试在给定数量的命名空间中创建以下对象：

  • 1 个镜像流

  • 1 个构建

  • 5 个部署，每个部署包含 2 个处于sleep状态的 Pod 副本，每个副本都挂载了 4 个密钥、4 个配置映射和 1 个向下 API 卷

  • 5 个服务，每个服务都指向前面部署之一的 TCP/8080 和 TCP/8443 端口

  • 1 个指向前面服务中的第一个服务的路由

  • 10 个密钥，每个密钥包含 2048 个随机字符串字符

  • 10 个配置映射，每个配置映射包含 2048 个随机字符串字符

工作节点数量 集群密度（命名空间） CPU 核心数 内存 (GB)

24

500

4

16

120

1000

8

32

252

4000

16，但如果使用 OVN-Kubernetes 网络插件，则为 24

64，但如果使用 OVN-Kubernetes 网络插件，则为 128

501，但未在 OVN-Kubernetes 网络插件中测试

4000

16

96

上表中的数据基于在 AWS 上运行的 OpenShift Container Platform，使用 r5.4xlarge 实例作为控制平面节点，使用 m5.2xlarge 实例作为工作节点。

在一个大型密集集群中，如果三个控制平面节点中的一个节点停止、重新启动或发生故障，CPU 和内存使用率将会飙升。故障可能是由于电源、网络、底层基础设施出现意外问题，也可能是由于在关闭集群以节省成本后重新启动集群的故意操作造成的。剩余的两个控制平面节点必须处理负载才能保持高可用性，这会导致资源使用率增加。在升级过程中也会出现这种情况，因为控制平面节点会被依次隔离、清空和重新启动，以应用操作系统更新以及控制平面 Operator 更新。为了避免级联故障，请将控制平面节点上的整体 CPU 和内存资源使用率保持在其所有可用容量的 60% 以内，以应对资源使用率的峰值。相应地增加控制平面节点上的 CPU 和内存，以避免由于资源不足而导致的潜在停机。

节点大小会根据集群中节点和对象的数量而变化。它还取决于对象是否正在集群中被主动创建。在对象创建期间，与对象处于running阶段相比，控制平面在资源使用方面更加活跃。

Operator Lifecycle Manager (OLM) 运行在控制平面节点上，其内存占用取决于 OLM 需要在集群中管理的命名空间和用户安装的 Operator 的数量。需要相应地调整控制平面节点的大小，以避免出现 OOM 终止的情况。以下数据点基于集群最大值测试的结果。

命名空间数量 OLM 空闲状态下的内存 (GB) 安装了 5 个用户 Operator 后 OLM 的内存 (GB)

500

0.823

1.7

1000

1.2

2.5

1500

1.7

3.2

2000

2

4.4

3000

2.7

5.6

4000

3.8

7.6

5000

4.2

9.02

6000

5.8

11.3

7000

6.6

12.9

8000

6.9

14.8

9000

8

17.7

10,000

9.9

21.6

您只能在以下配置中修改正在运行的 OpenShift Container Platform 4.17 集群的控制平面节点大小：

  • 使用用户预配安装方法安装的集群。

  • 使用安装程序预配基础设施安装方法安装的 AWS 集群。

  • 使用控制平面机器集来管理控制平面机器的集群。

对于所有其他配置，您必须估计您的总节点数量，并在安装过程中使用建议的控制平面节点大小。

在 OpenShift Container Platform 4.17 中，与 OpenShift Container Platform 3.11 和之前的版本相比，系统现在默认保留了半个 CPU 核心（500 毫核心）。在确定大小的时候已经考虑到了这一点。

如果 Amazon Web Services (AWS) 集群中的控制平面机器需要更多资源，您可以为控制平面机器选择更大的 AWS 实例类型。

使用控制平面机器集的集群与不使用控制平面机器集的集群的过程不同。

如果您不确定集群中ControlPlaneMachineSet CR 的状态，您可以验证 CR 状态。

您可以通过更新控制平面机器集自定义资源 (CR) 中的规范来更改控制平面机器使用的 Amazon Web Services (AWS) 实例类型。

先决条件

  • 您的 AWS 集群使用控制平面机器集。

步骤

  1. 通过运行以下命令编辑您的控制平面机器集 CR：

    $ oc --namespace openshift-machine-api edit controlplanemachineset.machine.openshift.io cluster

  2. 编辑providerSpec字段下的以下行：

    providerSpec:
  value:
    ...
    instanceType: <compatible_aws_instance_type> (1)
    1 指定一个与之前的选择具有相同基础的更大的 AWS 实例类型。例如，您可以将m6i.xlarge更改为m6i.2xlarge或m6i.4xlarge。

  3. 保存更改。

    • 对于使用默认RollingUpdate更新策略的集群，Operator 会自动将更改传播到您的控制平面配置。

    • 对于配置为使用OnDelete更新策略的集群，您必须手动替换控制平面机器。

其他资源

您可以通过更新 AWS 控制台中的实例类型来更改控制平面机器使用的 Amazon Web Services (AWS) 实例类型。

先决条件

  • 您可以访问 AWS 控制台，并拥有修改集群 EC2 实例所需的权限。

  • 您可以作为具有cluster-admin角色的用户访问 OpenShift Container Platform 集群。

步骤

  1. 打开 AWS 控制台并获取控制平面机器的实例。

  2. 选择一个控制平面机器实例。

    1. 对于选定的控制平面机器，通过创建 etcd 快照来备份 etcd 数据。有关更多信息，请参阅“备份 etcd”。

    2. 在 AWS 控制台中，停止控制平面机器实例。

    3. 选择已停止的实例，然后单击**操作**→**实例设置**→**更改实例类型**。

    4. 将实例更改为更大类型的实例，确保类型与之前的选择属于同一基础类型，然后应用更改。例如，您可以将m6i.xlarge更改为m6i.2xlarge或m6i.4xlarge。

    5. 启动实例。

    6. 如果您的 OpenShift Container Platform 集群具有与该实例对应的Machine对象，请将该对象的实例类型更新为与 AWS 控制台中设置的实例类型匹配。

  3. 对每个控制平面机器重复此过程。

其他资源