1.2. 性能和可扩展性
Red Hat Advanced Cluster Management for Kubernetes 已经过测试来决定特定的可扩展性和性能数据。测试的主要领域包括集群可扩展性和搜索性能。
您可以使用这些信息来帮助规划您的环境。
备注:数据基于测试时实验室环境的结果。您的具体结果可能会根据您的环境、网络速度和产品更改而有所不同。
1.2.1. 受管集群的总数
Red Hat Advanced Cluster Management 可管理的最大集群数量因以下几个因素而有所不同:
- 集群中的资源数量,它取决于部署的策略和应用程序数量等因素。
- hub 集群配置,如使用了多少个 pod 进行扩展。
下表显示了在测试过程中使用的 Amazon Web Services 云平台上集群的配置信息:
节点 | Flavor | vCPU | RAM(GiB) | 磁盘类型 | 磁盘大小(GiB) | 数量 | 区域 |
---|---|---|---|---|---|---|---|
Master | m5.2xlarge | 8 | 32 | gp2 | 100 | 3 | us-east-1 |
worker 或基础架构 | m5.2xlarge | 8 | 32 | gp2 | 100 | 3 个或 5 个节点 | us-east-1 |
如需有关基础架构节点的更多信息,请参阅 在基础架构节点上安装 Red Hat Advanced Cluster Management hub 集群。另请参阅创建基础架构机器集。
1.2.2. 搜索可扩展性
Search 组件的可扩展性取决于数据存储的性能。在分析搜索性能时,以下变量非常重要:
- 物理内存
- 写入吞吐量(缓存恢复时间)
- 查询执行时间
1.2.2.1. 物理内存
搜索会将数据保留在内存中从而达到快速响应时间。所需内存与 Kubernetes 资源的数量及其在集群中的关系有比例关系。
Clusters | Kubernetes 资源 | 关系 | 观察的大小(使用模拟数据) |
---|---|---|---|
1 个中型 | 5000 | 9500 | 50 Mi |
5 个中型 | 25,000 | 75,000 | 120 Mi |
15 个中型 | 75,000 | 20,0000 | 492 Mi |
30 个中型 | 150,000 | 450,000 | 1 Gi |
50 个中型 | 250,000 | 750,000 | 2 Gi |
有关如何更改搜索组件使用的内存量的更多信息,请参阅 Options 以增加 redisgraph 内存。
1.2.2.2. 写入吞吐量(缓存恢复时间)
大多数处于 steady 状态的集群会生成少量资源更新。当 RedisGraph 中的数据被清除时,更新率最高,这会导致远程收集器同时同步其完整状态。当数据存储被清除后,会为不同数量的受管集群测量恢复时间。
Clusters | Kubernetes 资源 | 关系 | 模拟的平均恢复时间 |
---|---|---|---|
1 个中型 | 5000 | 9500 | 少于 2 秒 |
5 个中型 | 25,000 | 75,000 | 少于 15 秒 |
15 个中型 | 75,000 | 200,000 | 2 分钟和 40 秒 |
30 个中型 | 150,000 | 450,000 | 5-8 分钟 |
请记住: 如果集群到 hub 的网络连接速度较慢,时间可能会增加。之前声明的写入吞吐量信息仅适用于 persistence
被禁用的情况。
1.2.2.3. 查询执行注意事项
有些事情可能会影响查询运行时间以及返回的结果。在计划和配置环境时请考虑以下方面:
搜索关键字效率不高。
如果您搜索
RedHat
且管理大量集群,可能需要更长的时间来接收搜索结果。- 第一次搜索需要更长的时间,因为收集基于用户的访问控制规则需要额外的时间。
完成请求的时间长度与用户有权访问的命名空间和资源数量成比例。
注:如果您与另一个用户保存并共享搜索查询,返回的结果会根据用户的访问级别而不同。如需有关角色访问权限的更多信息,请参阅 OpenShift Container Platform 文档中的使用 RBAC 定义和应用权限。
- 经过观察,当一个有访问所有命名空间或所有受管集群权限的、非管理员用户发出的请求性能最差。
1.2.3. 可观察性功能扩展
如果要启用和使用可观察性(observability)服务,则需要规划您的环境。之后的资源消耗是用于安装可观察性组件的 OpenShift Container Platform 项目。您计划使用的值为所有可观察性组件的总和。
备注:数据基于测试时实验室环境的结果。您的具体结果可能会根据您的环境、网络速度和产品更改而有所不同。
1.2.3.1. 可观察性环境示例
在示例环境中,hub 集群和受管集群位于 Amazon Web Services 云平台中,并具有以下拓扑和配置:
节点 | Flavor | vCPU | RAM(GiB) | 磁盘类型 | 磁盘大小(GiB) | 数量 | 区域 |
---|---|---|---|---|---|---|---|
Master 节点 | m5.4xlarge | 16 | 64 | gp2 | 100 | 3 | sa-east-1 |
Worker节点 | m5.4xlarge | 16 | 64 | gp2 | 100 | 3 | sa-east-1 |
可观察性部署是为高可用性环境配置的。使用高可用性环境,每个 Kubernetes 部署都有两个实例,每个有状态集(StatefulSet)都有三个实例。
在示例测试过程中,会模拟不同的受管集群来推送指标,每次测试会持续 24 小时。请参见以下吞吐量:
1.2.3.2. 写入吞吐量
pods | 间隔(分钟) | 每分钟的时间系列 |
---|---|---|
400 | 1 | 83000 |
1.2.3.3. CPU 用量(millicores)
在测试过程中,CPU 用量是稳定的:
Size | CPU 用量 |
---|---|
10 个集群 | 400 |
20 个集群 | 800 |
1.2.3.4. RSS 和工作集合内存
查看以下 RSS 和工作集合内存描述:
-
内存用量 RSS: 来自 metrics
container_memory_rss
,在测试过程中保持稳定状态。 -
内存用量工作集:来自 metrics
container_memory_working_set_bytes
,随着测试会增加。
以下来自于一个 24 小时测试的结果:
Size | 内存用量 RSS | 内存用量工作集 |
---|---|---|
10 个集群 | 9.84 | 4.93 |
20 个集群 | 13.10 | 8.76 |
1.2.3.5. 用于 thanos-receive
组件的持久性卷
重要:指标数据存储在 thanos-receive
中,直到达到了保留时间(四天)为止。其他组件不需要与 thanos-receive
组件一样多的卷。
磁盘用量随着测试会增加。数据代表一天后的磁盘用量,因此最终的磁盘用量要乘以 4。
请查看以下磁盘用法:
Size | 磁盘用量(GiB) |
---|---|
10 个集群 | 2 |
20 个集群 | 3 |
1.2.3.6. 网络传输
在测试过程中,网络传输提供了稳定性。查看大小和网络传输值:
Size | 入站网络传输 | 出站网络传输 |
---|---|---|
10 个集群 | 每秒 6.55 MBs | 每秒 5.80 MBs |
20 个集群 | 每秒 13.08 MBs | 每秒 10.9 MBs |
1.2.3.7. Amazon Simple Storage Service(S3)
Amazon Simple Storage Service(S3)中的总使用量会增加。指标数据会存储在 S3 中,直到达到默认的保留时间(5 天)。请查看以下磁盘用法:
Size | 磁盘用量(GiB) |
---|---|
10 个集群 | 16.2 |
20 个集群 | 23.8 |
1.2.4. 计划 hub 集群的规模。
每个 Red Hat Advanced Cluster Management for Kubernetes 集群都是唯一的,以下指南为您提供了部署大小示例。根据大小和目的对推荐进行分类。Red Hat Had Advanced Cluster Management 应用以下部分来调整支持服务的大小和位置:
- 可用域(Availability Zone)用来在集群中分离潜在的故障域。典型的集群应该在三个或多个可用域中具有几乎等同的 worker 节点容量。
- vCPU 保留(reservation)和限制(limit)在 worker 节点上建立 vCPU 容量以分配给一个容器。一个 vCPU 等同于一个 Kubernetes 计算单元。如需更多信息,请参阅 Kubernetes 中 CPU 的意义。
- 内存保留和限制会在 worker 节点上建立内存容量,以便分配给容器。
- 持久性数据,这些数据由产品管理,并存储在 Kubernetes 使用的 etcd 集群中。
重要:对于 OpenShift Container Platform,在 3 个可用区间分配集群的主节点。
1.2.4.1. 产品环境
注:以下要求不是最低要求。
节点类型 | 可用区 | etcd | 保留内存总量 | 保留 CPU 总量 |
Master | 3 | 3 | OpenShift Container Platform 大小指南 | OpenShift Container Platform 大小指南 |
worker 或基础架构 | 3 | 1 | 12 GB | 6 |
除了 Red Hat Advanced Cluster Management,OpenShift Container Platform 集群还运行其他服务来支持集群功能。详情请参阅在基础架构节点上安装 Red Hat Advanced Cluster Management hub 集群部分。
1.2.4.1.1. Amazon Web Services 上的 OpenShift Container Platform
如需更多信息,请参阅 OpenShift Container Platform 产品文档中的 Amazon Web Services 信息。
同时还可以参阅与机器类型相关的详细信息。
- 节点数: 3 个
- 可用区: 3 个
实例大小: m5.xlarge
- vCPU:4 个
- 内存:16 GB
- 存储大小: 120 GB
1.2.4.1.2. Google Cloud Platform 上的 OpenShift 集群
有关配额的更多信息,请参阅 Google Cloud Platform 产品文档。
同时还可以参阅与机器类型相关的详细信息。
- 节点数: 3 个
- 可用区: 3 个
实例大小:N1-standard-4(0.95-6.5 GB)
- vCPU:4 个
- 内存:15 GB
- 存储大小: 120 GB
1.2.4.1.3. Microsoft Azure 上的 OpenShift 集群
详情请查看以下产品文档。
- 节点数: 3 个
- 可用区: 3 个
实例大小: Standard_D4_v3
- vCPU:4 个
- 内存:16 GB
- 存储大小: 120 GB
1.2.4.1.4. VMware vSphere 上的 OpenShift 集群
详情请查看以下产品文档。
- 节点数: 3 个
- 可用区: 3 个
实例大小:
- 内存:16 GB
- 存储大小: 120 GB
- VCPU:4
- 每个插槽的内核数: 2
1.2.4.1.5. IBM Z 系统的 OpenShift Container Platform
如需更多信息,请参阅 OpenShift Container Platform 文档中的在 IBM Z 系统上安装集群。
- 节点数: 3 个
- 可用区: 3 个
实例大小:
- 内存:16 GB
- 存储大小:100 GB
vCPU:10
IBM Z 系统提供配置并发多线程(SMT)的功能,可扩展每个内核上运行的 vCPU 数量。如果您配置了 SMT,则一个物理内核 (IFL) 提供两个逻辑内核(线程)。管理程序可以提供两个或多个 vCPU。
当未启用并发多线程(SMT)或超线程时,一个 vCPU 相当于一个物理内核。启用后,使用以下公式来计算对应的比例:(每个内核数的线程)× sockets = vCPU。
有关 SMT 的更多信息,请参阅 Simultaneous 多线程。
1.2.4.1.6. IBM Power 系统上的 OpenShift Container Platform
如需更多信息,请参阅 OpenShift Container Platform 文档中的在 Power 系统上安装集群。
- 节点数: 3 个
- 可用区: 3 个
实例大小:
- 内存:16 GB
- 存储大小: 120 GB
vCPU: 16
IBM Power 系统提供配置并发多线程 (SMT) 的功能,可扩展每个内核上运行的 vCPU 数量。如果您配置了 SMT,则您的 SMT 级别决定如何满足 16 个 vCPU 的要求。最常见的配置有:
- 在 SMT-8 上运行的两个内核(运行 IBM PowerVM 的系统默认配置)提供所需的 16 个 vCPU。
在 SMT-4 上运行的四个内核提供所需的 16 个 vCPU。
有关 SMT 的更多信息,请参阅 Simultaneous 多线程。
1.2.4.1.7. 裸机资产上的 OpenShift Container Platform 集群
详情请查看以下产品文档。
OpenShift Container Platform 裸机上可安装并支持 Red Hat Advanced Cluster Management for Kubernetes hub 集群。hub 集群可以在紧凑的裸机拓扑上运行,其中有 3 个可调度的 control plane 节点,以及 0 个额外的 worker。
- 节点数: 3 个
- 可用区: 3 个
实例大小:
- 内存:16 GB
- 存储大小: 120 GB
- VCPU:4
1.2.4.1.8. 创建和管理单一节点 OpenShift Container Platform 集群
请参阅创建和管理 2200 个单一节点 OpenShift Container Platform 集群的示例要求。请参阅 Red Hat Advanced Cluster Management 创建单个节点 OpenShift(SNO)集群(230 和更多置备)集群,以及使用 hub 集群的 SNO 集群管理那些 SNO 集群的要求:
Master (可调度)
- 节点数: 3 个
- 内存:289 GB(集群最大)
- 内存:110 GB(单一节点最大)
- CPU 集群最大:90
- CPU 单个节点最大:44
注:当同时创建多个集群时,CPU 使用率最值最高。