3.2. 托管 control plane 的大小指导
许多因素（包括托管集群工作负载和 worker 节点数）都会影响到在特定数量的 control-plane 节点中可以包括多少托管集群。使用此大小指南来帮助托管集群容量规划。这个指南假设一个高可用的托管 control plane 拓扑。基于负载的大小示例是在裸机集群中测量的。基于云的实例可能具有不同的限制因素，如内存大小。
您可以覆盖以下资源使用率大小测量，并禁用指标服务监控。
请参阅以下高度可用的托管 control plane 要求，该要求已使用 OpenShift Container Platform 版本 4.12.9 及更新版本进行测试：
- 78 个 pod
- etcd：三个 8 GiB PV
- 最小 vCPU：大约 5.5 个内核
- 最小内存：大约 19 GiB
其他资源
3.2.1. Pod 限值
每个节点的 maxPods 设置会影响 control-plane 节点可以包括多少个托管集群。记录所有 control-plane 节点上的 maxPods 值非常重要。为每个高可用性托管的 control plane 计划大约 75 个 pod。
对于裸机节点，默认的 maxPods 设置为 250，这可能会成为一个限制因素，因为根据 pod 的要求，每个节点大约可以包括三个托管 control plane，即使机器中存在大量可用资源。通过配置 KubeletConfig 值将 maxPods 设置为 500，允许更大的托管的 control plane 密度，这有助于利用额外的计算资源。
其他资源
3.2.2. 基于请求的资源限值
集群可以托管的 control plane 的最大数量是根据来自 pod 的托管 control plane CPU 和内存请求进行计算的。
高可用托管 control plane 由 78 个 pod 组成，请求 5 个 vCPU 和 18 GB 内存。这些基线数据与集群 worker 节点资源容量进行比较，以估算托管 control plane 的最大数量。
3.2.3. 基于负载的限制
当某些工作负载放在托管的 control plane Kubernetes API 服务器上时，集群可以托管的 control plane pod CPU 和内存使用率计算的最大托管 control plane 数量。
在工作负载增加时，以下方法用于测量托管的 control plane 资源利用率：
- 在使用 KubeVirt 平台时，具有 9 个 worker 的、使用 8 个 vCPU 和 32 GiB 的托管集群
根据以下定义，配置为专注于 API control-plane 压力的工作负载测试配置集：
- 为每个命名空间创建对象，最多扩展 100 个命名空间
- 持续的对象删除和创建会造成额外的 API 压力
- 工作负载查询每秒(QPS)和 Burst 设置设置为高，以删除任何客户端节流
当负载增加 1000 QPS 时，托管的 control plane 资源使用率会增加 9 个 vCPU 和 2.5 GB 内存。
对于常规的大小设置，请考虑 1000 QPS API 的比率，它是一个 中型 托管集群负载；以及 2000 QPS API，它是一个 大型 托管的集群负载。
此测试提供了一个估算因素，用于根据预期的 API 负载增加计算资源利用率。确切的利用率可能会因集群工作负载的类型和节奏而有所不同。
| 托管 control plane 资源使用率扩展 | VCPU | 内存(GiB) |
|---|---|---|
| 没有负载的资源使用率 | 2.9 | 11.1 |
| 带有 1000 QPS 的资源利用率 | 9.0 | 2.5 |
当负载增加 1000 QPS 时，托管的 control plane 资源使用率会增加 9 个 vCPU 和 2.5 GB 内存。
对于常规的大小设置，请考虑 1000 QPS API 的比率，它是一个中型托管集群负载；以及 2000 QPS API，它是一个大型托管的集群负载。
以下示例显示了工作负载和 API 比率定义的托管 control plane 资源扩展：
| QPS (API rate) | vCPU 使用量 | 内存用量 (GiB) |
|---|---|---|
| 低负载 (小于 50 QPS) | 2.9 | 11.1 |
| 中型负载 (1000 QPS) | 11.9 | 13.6 |
| 高负载 (2000 QPS) | 20.9 | 16.1 |
托管 control plane 的大小针对于会导致大量 API 活动、etcd 活动或这两者的 control-plane 负载和工作负载。专注于 data-plane 负载的托管 pod 工作负载（如运行数据库）可能无法产生高 API 速率。
3.2.4. 大小计算示例
这个示例为以下场景提供大小指导：
-
三个裸机 worker，标记为
hypershift.openshift.io/control-plane节点 -
maxPods值设为 500 - 预期的 API 速率是中型或大约 1000，具体取决于基于负载的限制
| 限制描述 | Server 1 | Server 2 |
|---|---|---|
| worker 节点上的 vCPU 数量 | 64 | 128 |
| worker 节点上的内存 (GiB) | 128 | 256 |
| 每个 worker 的最大 pod 数量 | 500 | 500 |
| 用于托管 control plane 的 worker 数量 | 3 | 3 |
| 最大 QPS 目标比率（每秒的 API 请求） | 1000 | 1000 |
| 根据 worker 节点大小和 API 速率计算的值 | Server 1 | Server 2 | 计算备注 |
| 基于 vCPU 请求的每个 worker 的最大托管 control plane | 12.8 | 25.6 | worker vCPUs 数量 ÷ 5 总 vCPU 请求每个托管的 control plane |
| 基于 vCPU 使用的每个 worker 的最大托管 control plane | 5.4 | 10.7 | vCPUS 数量 ÷ (2.9 测量的空闲 vCPU 使用量 + (QPS 目标率 ÷ 1000) × 9.0 测量的 vCPU 使用量每 1000 QPS 增长) |
| 基于内存请求的每个 worker 的最大托管 control plane | 7.1 | 14.2 | Worker 内存 GiB ÷ 18 GiB 总内存请求每个托管 control plane |
| 根据内存用量，每个 worker 的最大托管 control plane | 9.4 | 18.8 | Worker 内存 GiB ÷ (11.1 测量的空闲内存使用量 + (QPS 目标率 ÷ 1000) × 2.5 测量的内存使用量每 1000 QPS 增加) |
| 每个 worker 的最大托管 control plane 基于每个节点 pod 限制 | 6.7 | 6.7 |
500 |
| 前面提到的最大值 | 5.4 | 6.7 | |
| vCPU 限制因素 |
| ||
| 一个管理集群中的托管 control plane 的最大数量 | 16 | 20 | 前面提到的最大的最小值 × 3 control-plane workers |
| Name | 描述 |
|
| 根据高可用性托管的 control plane 资源请求，集群可以托管的最大托管 control plane 数量。 |
|
| 如果所有托管的 control plane 都针对集群 Kube API 服务器有大约 50 个 QPS，则集群可以托管的最大托管 control plane 数量。 |
|
| 如果所有托管的 control plane 都针对集群 Kube API 服务器大约为 1000 QPS，则估计集群可以托管的最大 control plane 数量。 |
|
| 如果所有托管的 control plane 都针对集群 Kube API 服务器有大约 2000 个 QPS，则集群可以托管的最大托管 control plane 数量。 |
|
| 根据现有托管 control plane 的平均 QPS，估计集群可以托管的最大托管 control plane 数量。如果您没有活跃的托管 control plane，您可以预期低的 QPS。 |
