1.7. 性能和可扩展性
Red Hat Advanced Cluster Management for Kubernetes 已经过测试来决定特定的可扩展性和性能数据。测试的主要领域包括集群可扩展性和搜索性能。在规划环境时,您可以使用此信息。
备注:数据基于测试时实验室环境的结果。
Red Hat Advanced Cluster Management 使用裸机上的三个节点 hub 集群进行测试。在测试时,有足够的资源容量(CPU、内存和磁盘)来查找软件组件限制。您的具体结果可能会根据您的环境、网络速度和产品更改而有所不同。
1.7.1. 受管集群的总数 复制链接链接已复制到粘贴板!
Red Hat Advanced Cluster Management 可管理的最大集群数量因以下几个因素而有所不同:
- 集群中的资源数量,它取决于部署的策略和应用程序数量等因素。
- hub 集群配置,如使用了多少个 pod 进行扩展。
受管集群是托管在 Red Hat Enterprise Linux hypervisor 上的单节点 OpenShift 虚拟机。虚拟机用于在测试过程中为每个裸机获得高密度的集群数量。sushy-emulator 与 libvirt 用于虚拟机,以便可以使用 Redfish API 访问的裸机集群。以下 Operator 是测试安装、Topology Aware Lifecycle Manager、Local Storage Operator 和 Red Hat OpenShift GitOps 的一部分。下表显示了实验室环境扩展信息:
| 节点 | 数量 | 操作系统 | 硬件 | CPU 内核 | 内存 | 磁盘 |
|---|---|---|---|---|---|---|
| hub 集群 control plane | 3 | OpenShift Container Platform | 裸机 | 112 | 512 GiB | 446 GB SSD, 2.9 TB NVMe, 2 x 1.8 TB SSD |
| 受管集群(managed cluster) | 3500 | single-node OpenShift | 虚拟机器 | 8 | 18 GiB | 120 GB |
1.7.2. 搜索可扩展性 复制链接链接已复制到粘贴板!
Search 组件的可扩展性取决于数据存储的性能。在分析搜索性能时,查询运行时间是一个重要的变量。
1.7.2.1. 查询运行时注意事项 复制链接链接已复制到粘贴板!
有些事情可能会影响查询运行时间以及返回的结果。在计划和配置环境时请考虑以下方面:
搜索关键字效率不高。
如果您搜索
RedHat且管理大量集群,可能需要更长的时间来接收搜索结果。- 第一次搜索需要更长的时间,因为收集基于用户的访问控制规则需要额外的时间。
完成请求的时间长度与用户有权访问的命名空间和资源数量成比例。
注:如果您与另一个用户保存并共享搜索查询,返回的结果会根据用户的访问级别而不同。如需有关角色访问权限的更多信息,请参阅 OpenShift Container Platform 文档中的使用 RBAC 定义和应用权限。
- 经过观察,当一个有访问所有命名空间或所有受管集群权限的、非管理员用户发出的请求性能最差。
1.7.3. Observability 可扩展性 复制链接链接已复制到粘贴板!
如果要启用和使用可观察性(observability)服务,则需要规划您的环境。之后的资源消耗是用于安装可观察性组件的 OpenShift Container Platform 项目。您计划使用的值为所有可观察性组件的总和。
备注:数据基于测试时实验室环境的结果。您的具体结果可能会根据您的环境、网络速度和产品更改而有所不同。
1.7.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.7.3.2. 写入吞吐量 复制链接链接已复制到粘贴板!
| pods | 间隔(分钟) | 每分钟的时间系列 |
|---|---|---|
| 400 | 1 | 83000 |
1.7.3.3. CPU 用量(millicores) 复制链接链接已复制到粘贴板!
在测试过程中,CPU 用量是稳定的:
| Size | CPU 用量 |
|---|---|
| 10 个集群 | 400 |
| 20 个集群 | 800 |
1.7.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.7.3.5. 用于 thanos-receive 组件的持久性卷 复制链接链接已复制到粘贴板!
重要:指标数据存储在 thanos-receive 中,直到达到了保留时间(四天)为止。其他组件不需要与 thanos-receive 组件一样多的卷。
磁盘用量随着测试会增加。数据代表一天后的磁盘用量,因此最终的磁盘用量要乘以 4。
请查看以下磁盘用法:
| Size | 磁盘用量(GiB) |
|---|---|
| 10 个集群 | 2 |
| 20 个集群 | 3 |
1.7.3.6. 网络传输 复制链接链接已复制到粘贴板!
在测试过程中,网络传输提供了稳定性。查看大小和网络传输值:
| Size | 入站网络传输 | 出站网络传输 |
|---|---|---|
| 10 个集群 | 每秒 6.55 MBs | 每秒 5.80 MBs |
| 20 个集群 | 每秒 13.08 MBs | 每秒 10.9 MBs |
1.7.3.7. Amazon Simple Storage Service(S3) 复制链接链接已复制到粘贴板!
Amazon Simple Storage Service(S3)中的总使用量会增加。指标数据会存储在 S3 中,直到达到默认的保留时间(5 天)。请查看以下磁盘用法:
| Size | 磁盘用量(GiB) |
|---|---|
| 10 个集群 | 16.2 |
| 20 个集群 | 23.8 |
1.7.4. 备份和恢复可扩展性 复制链接链接已复制到粘贴板!
在大型扩展环境中执行的测试会显示以下用于备份和恢复的数据:
| Backups | Duration | 资源数量 | 备份内存 |
|---|---|---|---|
| credentials | 2m5s | 18272 资源 | 55MiB 备份大小 |
| 受管集群 | 3m22s | 58655 资源 | 38MiB 备份大小 |
| resources | 1m34s | 1190 资源 | 1.7MiB 备份大小 |
| generic/user | 2m56s | 0 个资源 | 16.5KiB 备份大小 |
备份总时间为 10m。
| Backups | Duration | 资源数量 |
|---|---|---|
| redentials | 47m8s | 18272 资源 |
| resources | 3m10s | 1190 资源 |
| 通用/用户备份 | 0m | 0 个资源 |
总恢复时间为 50m18s。
使用创建 BackupSchedule 时设置的 veleroTtl 参数选项修剪备份文件数量。任何创建时间超过指定 TTL (生存时间)的备份已过期,并由 Velero 从存储位置自动删除。
apiVersion: cluster.open-cluster-management.io/v1beta1
kind: BackupSchedule
metadata:
name:schedule-acm
namespace:open-cluster-management-backup
spec:
veleroSchedule:0 */1 * * *
veleroTtl:120h