第 1 章 安装和升级


通过 Operator Lifecycle Manager 安装 Red Hat Advanced Cluster Management for Kubernetes,它管理安装、升级和删除包含 Red Hat Advanced Cluster Management hub 集群的组件。因为 Red Hat Advanced Cluster Management 依赖于并使用 multicluster engine operator,所以在安装过程中创建 MultiClusterHub 资源后,Red Hat Advanced Cluster Management Operator 会自动安装 multicluster engine operator operator 并创建 MultiClusterEngine 资源。

您必须有一个受支持的 OpenShift Container Platform 版本才能安装 Red Hat Advanced Cluster Management。

在安装前,请查看每个产品所需的硬件和系统配置。您可以使用受支持的 Red Hat OpenShift Container Platform 版本在 Linux 上在线安装。

有关完全支持信息,请参阅 Red Hat Advanced Cluster Management Support Matrix 以及 Red Hat Advanced Cluster Management for Kubernetes 的生命周期和更新策略

弃用: Red Hat Advanced Cluster Management 2.7 及更早的版本不再被支持。文档可能仍然可用,但没有任何勘误或其他更新。

最佳实践: 升级到最新版本。

FIPS 注意: 如果您没有在 spec.ingress.sslCiphers 中指定自己的密码,则 multiclusterhub-operator 提供了默认密码列表。如果您升级和需要 FIPS 合规性,请从 MultiClusterHub 资源中删除以下两个密码: ECDHE-ECDSA-CHACHA20-POLY1305ECDHE-RSA-CHACHA20-POLY1305

除非仅在最新版本的 OpenShift Container Platform 上引入并测试特定组件或功能,否则文档会参考最早支持的 OpenShift Container Platform 版本。

安装 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 的一部分。下表显示了实验室环境扩展信息:

表 1.1. 环境扩展表
节点数量操作系统硬件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.1.2. 搜索可扩展性

Search 组件的可扩展性取决于数据存储的性能。在分析搜索性能时,查询运行时间是一个重要的变量。

1.1.2.1. 查询运行时注意事项

有些事情可能会影响查询运行时间以及返回的结果。在计划和配置环境时请考虑以下方面:

  • 搜索关键字效率不高。

    如果您搜索 RedHat 且管理大量集群,可能需要更长的时间来接收搜索结果。

  • 第一次搜索需要更长的时间,因为收集基于用户的访问控制规则需要额外的时间。
  • 完成请求的时间长度与用户有权访问的命名空间和资源数量成比例。

    注:如果您与另一个用户保存并共享搜索查询,返回的结果会根据用户的访问级别而不同。如需有关角色访问权限的更多信息,请参阅 OpenShift Container Platform 文档中的使用 RBAC 定义和应用权限

  • 经过观察,当一个有访问所有命名空间或所有受管集群权限的、非管理员用户发出的请求性能最差。

1.1.3. Observability 可扩展性

如果要启用和使用可观察性(observability)服务,则需要规划您的环境。之后的资源消耗是用于安装可观察性组件的 OpenShift Container Platform 项目。您计划使用的值为所有可观察性组件的总和。

备注:数据基于测试时实验室环境的结果。您的具体结果可能会根据您的环境、网络速度和产品更改而有所不同。

1.1.3.1. 可观察性环境示例

在示例环境中,hub 集群和受管集群位于 Amazon Web Services 云平台中,并具有以下拓扑和配置:

节点FlavorvCPURAM(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.1.3.2. 写入吞吐量

pods间隔(分钟)每分钟的时间系列

400

1

83000

1.1.3.3. CPU 用量(millicores)

在测试过程中,CPU 用量是稳定的:

SizeCPU 用量

10 个集群

400

20 个集群

800

1.1.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.1.3.5. 用于 thanos-receive 组件的持久性卷

重要:指标数据存储在 thanos-receive 中,直到达到了保留时间(四天)为止。其他组件不需要与 thanos-receive 组件一样多的卷。

磁盘用量随着测试会增加。数据代表一天后的磁盘用量,因此最终的磁盘用量要乘以 4。

请查看以下磁盘用法:

Size磁盘用量(GiB)

10 个集群

2

20 个集群

3

1.1.3.6. 网络传输

在测试过程中,网络传输提供了稳定性。查看大小和网络传输值:

Size入站网络传输出站网络传输

10 个集群

每秒 6.55 MBs

每秒 5.80 MBs

20 个集群

每秒 13.08 MBs

每秒 10.9 MBs

1.1.3.7. Amazon Simple Storage Service(S3)

Amazon Simple Storage Service(S3)中的总使用量会增加。指标数据会存储在 S3 中,直到达到默认的保留时间(5 天)。请查看以下磁盘用法:

Size磁盘用量(GiB)

10 个集群

16.2

20 个集群

23.8

1.1.4. 备份和恢复可扩展性

在大型扩展环境中执行的测试会显示以下用于备份和恢复的数据:

表 1.2. 受管集群备份的运行时间表
BackupsDuration资源数量备份内存

credentials

2m5s

18272 资源

55MiB 备份大小

受管集群

3m22s

58655 资源

38MiB 备份大小

resources

1m34s

1190 资源

1.7MiB 备份大小

generic/user

2m56s

0 个资源

16.5KiB 备份大小

备份总时间为 10m

表 1.3. 恢复被动 hub 集群的运行时间表
BackupsDuration资源数量

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

1.1.5. 计划集群大小

每个 Red Hat Advanced Cluster Management for Kubernetes 集群都是唯一的,以下指南为您提供了部署大小示例。根据大小和目的对推荐进行分类。Red Hat Had Advanced Cluster Management 应用以下部分来调整支持服务的大小和位置:

可用区
可用区在集群中分离潜在的故障域。典型的集群在三个或更多可用区中有接近的 worker 节点容量。
vCPU 保留和限制
vCPU 保留(reservation)和限制(limit)在 worker 节点上建立 vCPU 容量以分配给一个容器。vCPU 等于 Kubernetes 计算单元。有关 Kubernetes 计算单元 的信息,请参阅 Kubernetes 主题。
内存保留和限制
内存保留和限制会在 worker 节点上建立内存容量,以便分配给容器。
持久性数据
持久性数据由产品管理,并存储在 Kubernetes 使用的 etcd 集群中。

重要: 对于 OpenShift Container Platform,在三个可用区间分发集群的主节点。

1.1.5.1. 产品环境

以下要求 不是 环境的最低要求:

表 1.4. 产品环境
节点类型可用区etcd保留内存总量保留 CPU 总量

Master

3

3

OpenShift Container Platform 大小指南

OpenShift Container Platform 大小指南

worker 或基础架构

3

1

12 GB

6

另外,OpenShift Container Platform 集群运行更多服务来支持集群功能。

1.1.5.1.1. OpenShift Container Platform on additional services

可用域(Availability Zone)用来在集群中分离潜在的故障域。

表 1.5. Additional services
服务节点数可用区实例大小vCPUmemory存储大小Resources

Amazon Web Services 上的 OpenShift Container Platform

3

3

m5.xlarge

4

16 GB

120 GB

如需更多信息 ,请参阅 OpenShift Container Platform 产品文档中的使用自定义在 AWS 上安装集群

同时还可以参阅与机器类型相关的详细信息。

Google Cloud Platform 上的 OpenShift Container Platform

3

3

N1-standard-4 (0.95–6.5 GB)

4

15 GB

120 GB

有关 配额的更多信息,请参阅查看和管理 配额。

了解有关 Google 计算机系列资源和比较 的更多信息。

OpenShift Container Platform on Microsoft Azure

3

3

Standard_D4_v3

4

16 GB

120 GB

如需了解更多详细信息 ,请参阅 OpenShift Container Platform 文档中的配置 Azure 帐户

OpenShift Container Platform on VMware vSphere

3

3

 

4 (每个插槽 2 个内核)

16 GB

120 GB

如需了解更多详细信息,请参阅 OpenShift Container Platform 文档中的在 vSphere 上安装

IBM Z 系统的 OpenShift Container Platform

3

3

 

10

16 GB

100 GB

如需更多信息 ,请参阅 OpenShift Container Platform 文档中的在 IBM Z 系统上安装集群。

IBM Z 系统提供配置并发多线程(SMT)的功能,可扩展每个内核上运行的 vCPU 数量。如果您配置了 SMT,则一个物理内核 (IFL) 提供两个逻辑内核(线程)。管理程序可以提供两个或多个 vCPU。

当未启用并发多线程(SMT)或超线程时,一个 vCPU 等于一个物理内核。启用后,使用以下公式来计算对应的比例:(每个内核数的线程)× sockets = vCPU。

有关 SMT 的更多信息,请参阅 Simultaneous 多线程

IBM Power 系统上的 OpenShift Container Platform

3

3

 

16

16 GB

120 GB

如需更多信息 ,请参阅 OpenShift Container Platform 文档中的在 Power 系统上安装集群。

IBM Power 系统提供配置并发多线程 (SMT) 的功能,可扩展每个内核上运行的 vCPU 数量。如果您配置了 SMT,则您的 SMT 级别决定如何满足 16 个 vCPU 的要求。最常见的配置有:

在 SMT-8 上运行的两个内核(运行 IBM Power 虚拟机的系统的默认配置)提供所需的 16 个 vCPU。

在 SMT-4 上运行的四个内核提供所需的 16 个 vCPU。

有关 SMT 的更多信息,请参阅 Simultaneous 多线程

OpenShift Container Platform 内部

3

  

4

16 GB

120 GB

如需了解更多详细信息 ,请参阅 OpenShift Container Platform 文档中的配置三节点集群

OpenShift Container Platform 裸机上可安装并支持 Red Hat Advanced Cluster Management for Kubernetes hub 集群。hub 集群可以在紧凑的裸机拓扑上运行,其中有 3 个可调度的 control plane 节点,以及 0 个额外的 worker。

1.1.5.1.2. 创建和管理单一节点 OpenShift Container Platform 集群

查看 在单个节点上安装 以了解具体要求。由于每个集群都是唯一的,因此以下准则只提供了按大小和目的分类的部署要求示例。

可用域(Availability Zone)用来在集群中分离潜在的故障域。典型的集群在三个或更多可用区中具有相等的 worker 节点容量。不支持高可用性。

重要: 对于 OpenShift Container Platform,在三个可用区间分发集群的主节点。

请参阅创建和管理 3500 个单节点 OpenShift Container Platform 集群的示例要求。请参阅 Red Hat Advanced Cluster Management 创建单节点 OpenShift 集群(同时置备230 及更多置备)的最低要求,以及使用 hub 集群管理那些单节点 OpenShift 集群:

表 1.6. Master (可调度)
节点数内存(集群使用情况)内存(单一节点 min-max)CPU 集群CPU 单一节点

3

289 GB

64 GB - 110 GB

90

44

Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

© 2024 Red Hat, Inc.