第 1 章 安装和升级
在安装前,请查看每个产品所需的硬件和系统配置。您可以使用受支持的 Red Hat OpenShift Container Platform 版本在 Linux 上在线安装。
您必须有受支持的 OpenShift Container Platform 版本。例如,您可以在 AWS 或 Red Hat OpenShift Dedicated 上使用 Red Hat OpenShift Service。
弃用: Red Hat Advanced Cluster Management 2.8 及更早的版本不再被支持。文档可能仍然可用,但没有任何勘误或其他更新。
最佳实践: 升级到最新版本。
FIPS 注意: 如果您没有在 spec.ingress.sslCiphers
中指定自己的密码,则 multiclusterhub-operator
提供了默认密码列表。如果您升级和需要 FIPS 合规性,请从 multiclusterhub
资源中删除以下两个密码: ECDHE-ECDSA-CHACHA20-POLY1305
和 ECDHE-RSA-CHACHA20-POLY1305
。
除非仅在最新版本的 OpenShift Container Platform 上引入并测试特定组件或功能,否则文档会参考最早支持的 OpenShift Container Platform 版本。
有关完全支持信息,请参阅 Red Hat Advanced Cluster Management 2.11 Support Matrix 以及 Red Hat Advanced Cluster Management for Kubernetes 的生命周期和更新策略。
安装 Red Hat Advanced Cluster Management for Kubernetes 来设置一个多节点集群生产环境。您可以使用标准配置或高可用性配置安装 Red Hat Advanced Cluster Management for Kubernetes。有关安装过程的更多信息,请参阅以下文档:
1.1. 性能和可扩展性 复制链接链接已复制到粘贴板!
Red Hat Advanced Cluster Management for Kubernetes 已经过测试来决定特定的可扩展性和性能数据。测试的主要领域包括集群可扩展性和搜索性能。在规划环境时,您可以使用此信息。
备注:数据基于测试时实验室环境的结果。
Red Hat Advanced Cluster Management 使用裸机上的三个节点 hub 集群进行测试。在测试时,有足够的资源容量(CPU、内存和磁盘)来查找软件组件限制。您的具体结果可能会根据您的环境、网络速度和产品更改而有所不同。
1.1.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 | 单节点 OpenShift | 虚拟机器 | 8 | 18 GiB | 120 GB |
1.1.2. 搜索可扩展性 复制链接链接已复制到粘贴板!
Search 组件的可扩展性取决于数据存储的性能。在分析搜索性能时,查询运行时间是一个重要的变量。
1.1.2.1. 查询运行时注意事项 复制链接链接已复制到粘贴板!
有些事情可能会影响查询运行时间以及返回的结果。在计划和配置环境时请考虑以下方面:
搜索关键字效率不高。
如果您搜索
RedHat
且管理大量集群,可能需要更长的时间来接收搜索结果。- 第一次搜索需要更长的时间,因为收集基于用户的访问控制规则需要额外的时间。
完成请求的时间长度与用户有权访问的命名空间和资源数量成比例。
注:如果您与另一个用户保存并共享搜索查询,返回的结果会根据用户的访问级别而不同。如需有关角色访问权限的更多信息,请参阅 OpenShift Container Platform 文档中的使用 RBAC 定义和应用权限。
- 经过观察,当一个有访问所有命名空间或所有受管集群权限的、非管理员用户发出的请求性能最差。
1.1.3. Observability 可扩展性 复制链接链接已复制到粘贴板!
如果要启用和使用可观察性(observability)服务,则需要规划您的环境。之后的资源消耗是用于安装可观察性组件的 OpenShift Container Platform 项目。您计划使用的值为所有可观察性组件的总和。
备注:数据基于测试时实验室环境的结果。您的具体结果可能会根据您的环境、网络速度和产品更改而有所不同。
可观察性环境示例
在示例环境中,hub 集群和受管集群位于 Amazon Web Services 云平台中,并具有以下拓扑和配置:
Expand 表 1.2. 可观察性环境示例表 节点 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 小时。请参见以下吞吐量:
Expand 表 1.3. 写入吞吐量表 Pods 间隔(分钟) 每分钟的时间系列 400
1
83000
CPU 用量(millicores)
在测试过程中请查看以下 CPU 使用量:
Expand 表 1.4. CPU 用量表(millicores) Size CPU 用量 10 个集群
400
20 个集群
800
RSS 和工作集合内存
-
内存用量 RSS: 来自 metrics
container_memory_rss
,在测试过程中保持稳定状态。 内存用量工作集:来自 metrics
container_memory_working_set_bytes
,随着测试会增加。以下来自于一个 24 小时测试的结果:
Expand 表 1.5. RSS 和工作集合内存表 Size 内存用量 RSS 内存用量工作集 10 个集群
9.84
4.93
20 个集群
13.10
8.76
-
内存用量 RSS: 来自 metrics
thanos-receive
组件的持久性卷重要:指标数据存储在
thanos-receive
中,直到达到了保留时间(四天)为止。其他组件不需要与thanos-receive
组件一样多的卷。磁盘用量随着测试会增加。数据代表一天后的磁盘用量,因此最终的磁盘用量要乘以 4。
Expand 表 1.6. 磁盘用量表 Size 磁盘用量(GiB) 10 个集群
2
20 个集群
3
网络传输
在测试过程中,网络传输提供了稳定性。查看大小和网络传输值:
Expand 表 1.7. 表网络传输 Size 入站网络传输 出站网络传输 10 个集群
每秒 6.55 MBs
每秒 5.80 MBs
20 个集群
每秒 13.08 MBs
每秒 10.9 MBs
Amazon Simple Storage Service(S3)
Amazon Simple Storage Service(S3)中的总使用量会增加。指标数据会存储在 S3 中,直到达到默认的保留时间(5 天)。请查看以下磁盘用法:
Expand 表 1.8. Amazon Simple Storage Service (S3)表 Size 磁盘用量(GiB) 10 个集群
16.2
20 个集群
23.8
1.1.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 从存储位置自动删除。