OpenShift 文档正在迁移，很快将只能在 docs.redhat.com（所有 Red Hat 产品文档的中心）访问。立即体验 新的文档体验。
  1. 文档
    2. history bug_report picture_as_pdf
×

托管控制平面大小指导

许多因素都会影响在特定数量的工作节点中可以容纳多少个托管控制平面，包括托管集群工作负载和工作节点数量。使用本大小调整指南来帮助进行托管集群容量规划。本指南假设高可用性托管控制平面拓扑。基于负载的大小调整示例是在裸机集群上测量的。基于云的实例可能具有不同的限制因素，例如内存大小。

您可以覆盖以下资源利用率大小调整测量值并禁用指标服务监控。

请参阅以下高可用性托管控制平面要求，这些要求已使用 OpenShift Container Platform 4.12.9 及更高版本进行测试

  • 78 个 Pod

  • 三个 8 GiB 的 etcd PV

  • 最小 vCPU：大约 5.5 个核心

  • 最小内存：大约 19 GiB

其他资源

Pod 限制

每个节点的maxPods设置会影响可以在控制平面节点中容纳多少个托管集群。重要的是要注意所有控制平面节点上的maxPods值。为每个高可用性托管控制平面规划大约 75 个 Pod。

对于裸机节点，默认的maxPods设置为 250，这很可能是一个限制因素，因为考虑到 Pod 需求，每个节点大约可以容纳三个托管控制平面，即使机器还有很多资源剩余。通过配置KubeletConfig值将maxPods值设置为 500，可以提高托管控制平面的密度，这可以帮助您利用额外的计算资源。

其他资源

基于请求的资源限制

集群可以托管的托管控制平面的最大数量是根据 Pod 的托管控制平面 CPU 和内存请求计算的。

高可用性托管控制平面由 78 个 Pod 组成，这些 Pod 请求 5 个 vCPU 和 18 GB 内存。这些基线数字与集群工作节点的资源容量进行比较，以估算托管控制平面的最大数量。

基于负载的限制

集群可以托管的主控平面最大数量是根据在托管控制平面 Kubernetes API 服务器上部署一些工作负载时，托管控制平面 Pod 的 CPU 和内存利用率计算得出的。

随着工作负载的增加，使用以下方法来测量托管控制平面资源利用率：

  • 一个包含 9 个工作节点的托管集群，每个工作节点使用 8 个 vCPU 和 32 GiB 内存，同时使用 KubeVirt 平台。

  • 基于以下定义配置的工作负载测试配置文件，重点关注 API 控制平面压力测试：

    • 为每个命名空间创建对象，最多扩展到 100 个命名空间。

    • 使用持续的对象删除和创建来增加 API 压力。

    • 将每秒查询数 (QPS) 和突发设置设置为高值，以消除任何客户端端的限流。

随着负载每增加 1000 QPS，托管控制平面资源利用率会增加 9 个 vCPU 和 2.5 GB 内存。

出于一般规模规划的目的，将 1000 QPS API 速率视为中等托管集群负载，将 2000 QPS API 速率视为高托管集群负载。

此测试提供了一个估算因子，用于根据预期的 API 负载来增加计算资源利用率。确切的利用率可能会因集群工作负载的类型和速度而异。
表 1. 负载表
托管控制平面资源利用率扩展 vCPU 内存 (GiB)

无负载时的资源利用率

2.9

11.1

1000 QPS 时的资源利用率

9.0

2.5

随着负载每增加 1000 QPS，托管控制平面资源利用率会增加 9 个 vCPU 和 2.5 GB 内存。

出于一般规模规划的目的，将 1000 QPS API 速率视为中等托管集群负载，将 2000 QPS API 速率视为高托管集群负载。

以下示例显示了根据工作负载和 API 速率定义的托管控制平面资源扩展情况。

表 2. API 速率表
QPS (API 速率) vCPU 使用率 内存使用率 (GiB)

低负载 (低于 50 QPS)

2.9

11.1

中等负载 (1000 QPS)

11.9

13.6

高负载 (2000 QPS)

20.9

16.1

托管控制平面的规模规划主要取决于控制平面负载和导致大量 API 活动、etcd 活动或两者兼有的工作负载。专注于数据平面负载（例如运行数据库）的托管 Pod 工作负载可能不会导致高 API 速率。

规模规划计算示例

此示例提供以下场景的规模规划指导：

  • 三个标记为hypershift.openshift.io/control-plane节点的裸机工作节点。

  • maxPods 值设置为 500。

  • 根据基于负载的限制，预期的 API 速率为中等，约为 1000。

表 3. 限制输入
限制描述 服务器 1 服务器 2

工作节点上的 vCPU 数量

64

128

工作节点上的内存 (GiB)

128

256

每个工作节点的最大 Pod 数

500

500

用于托管控制平面的工作节点数量

3

3

最大 QPS 目标速率（每秒 API 请求数）

1000

1000
表 4. 规模规划计算示例

基于工作节点大小和 API 速率的计算值

服务器 1

服务器 2

计算说明

基于 vCPU 请求的每个工作节点上的最大托管控制平面数量

12.8

25.6

工作节点 vCPU 数量 ÷ 每个托管控制平面 5 个 vCPU 总请求

基于 vCPU 使用率的每个工作节点上的最大托管控制平面数量

5.4

10.7

vCPU 数量 ÷ (2.9 个测量的空闲 vCPU 使用率 + (QPS 目标速率 ÷ 1000) × 9.0 个测量的每增加 1000 QPS 的 vCPU 使用率)

基于内存请求的每个工作节点上的最大托管控制平面数量

7.1

14.2

工作节点内存 GiB ÷ 每个托管控制平面 18 GiB 总内存请求

基于内存使用率的每个工作节点上的最大托管控制平面数量

9.4

18.8

工作节点内存 GiB ÷ (11.1 个测量的空闲内存使用率 + (QPS 目标速率 ÷ 1000) × 2.5 个测量的每增加 1000 QPS 的内存使用率)

基于每个节点 Pod 限制的每个工作节点上的最大托管控制平面数量

6.7

6.7

500 个maxPods ÷ 每个托管控制平面 75 个 Pod

前面提到的最大值的最小值

5.4

6.7

vCPU 限制因素

maxPods 限制因素

管理集群中托管控制平面的最大数量

16

20

前面提到的最大值的最小值 × 3 个控制平面工作节点
表 5. 托管控制平面容量指标

名称

描述

mce_hs_addon_request_based_hcp_capacity_gauge

基于高可用托管控制平面资源请求，集群可以托管的托管控制平面的最大估计数量。

mce_hs_addon_low_qps_based_hcp_capacity_gauge

如果所有托管控制平面对集群的 Kube API 服务器发出大约 50 QPS 的请求，则集群可以托管的托管控制平面的最大估计数量。

mce_hs_addon_medium_qps_based_hcp_capacity_gauge

如果所有托管控制平面对集群的 Kube API 服务器发出大约 1000 QPS 的请求，则集群可以托管的托管控制平面的最大估计数量。

mce_hs_addon_high_qps_based_hcp_capacity_gauge

如果所有托管控制平面对集群的 Kube API 服务器发出大约 2000 QPS 的请求，则集群可以托管的托管控制平面的最大估计数量。

mce_hs_addon_average_qps_based_hcp_capacity_gauge

基于现有托管控制平面的平均 QPS，集群可以托管的托管控制平面的最大估计数量。如果您没有活动的托管控制平面，则可以预期 QPS 较低。

托管控制平面和独立控制平面之间的共享基础设施

作为服务提供商，您可以通过在独立 OpenShift Container Platform 控制平面和托管控制平面之间共享基础设施来更有效地利用资源。一个 3 节点的 OpenShift Container Platform 集群可以作为托管集群的管理集群。

在受限环境（例如在需要资源效率的小规模部署中）共享基础设施可能是有益的。

在共享基础设施之前，请确保您的基础设施拥有足够的资源来支持托管控制平面。在 OpenShift Container Platform 管理集群上，除了托管控制平面外，不能部署其他任何内容。确保管理集群拥有足够的 CPU、内存、存储和网络资源来处理托管集群的组合负载。有关更多信息，请参阅“托管控制平面的规模规划指南”。

工作负载不能要求过高，并且必须属于低每秒查询数 (QPS) 配置文件。为了保持合理的风险状况，您可以共享最多 3 个托管集群。

其他资源