1.6. 在断开连接的环境中升级
在断开连接的环境中,请参阅升级 Red Hat Advanced Cluster Management for Kubernetes 的步骤和信息。
注: 此信息遵循 升级中的步骤。查看该流程,然后查看以下信息:
在安装过程中,或升级过程中可能会遇到与 Red Hat Advanced Cluster Management 和 multicluster engine operator 之间相互独立相关的重要信息。请参阅在断开连接的环境中安装,以便在安装或升级过程中考虑考虑。
与在连接的网络环境中升级一样,升级过程通过更改 Red Hat Advanced Cluster Management for Kubernetes 的 Operator Lifecycle Manager 订阅中的升级频道来启动到新版本升级频道。
但是,由于断开连接的环境特殊特性,您需要在更改更新频道以启动升级过程前解决以下镜像要求:
确保在镜像目录中更新所需的软件包。
在安装过程中,或在以前的更新过程中,您创建了一个镜像目录和一个 registry,其中包含在断开连接的环境中安装 Red Hat Advanced Cluster Management for Kubernetes 的 operator 软件包和镜像。要升级,您需要更新镜像目录和 registry 来获取 Operator 软件包的更新版本。
与安装操作类似,您需要确保您的镜像目录和 registry 在要包含或更新的 Operator 列表中包含以下 Operator 软件包:
-
advanced-cluster-manager
-
multicluster-engine
-
验证
MutliclusterHub
资源实例。在安装或升级过程中,您创建了
MulticlusterHub
资源的实例,并因为断开连接的环境,您要为该资源添加了一个mce-subscription-spec
注解。如果您更新您的镜像目录和 registry 的步骤会导致 OpenShift Container Platform 集群上可用的名为
CatalogSource
的 CatalogSource 与之前使用的名称相同,则不需要更新MulticlusterHub
资源来更新mce-subscriptino-spec
注解。但是,如果更新您的镜像目录和 registry 的步骤会导致新创建的名为
CatalogSource
,请更新MulticlusterHub
资源中的mce-subscription-spec
注解以反映新的目录源名称。
1.6.1. 使用目录镜像升级
Red Hat Advanced Cluster Management 使用相关的多集群引擎 operator 功能来提供作为该产品的一部分提供的基础服务。作为 hub 集群安装和升级的一部分,Red Hat Advanced Cluster Management 会自动安装和管理所需的多集群引擎 operator 和 MulticlusterEngine
资源实例。
在连接的网络环境中,集群管理员可以在没有特殊镜像目录和目录源的情况下安装或升级 Red Hat Advanced Cluster Management。但是,因为在断开连接的环境中安装任何 Operator Lifecycle Manager Operator 涉及使用特殊镜像目录和目录源(如前面几节所述),所以在安装后需要一些额外的步骤。
更新用于填充镜像目录的步骤。
如果在安装 Red Hat Advanced Cluster Management 镜像步骤创建了 Red Hat Operator 目录的完整副本,则不需要特殊的镜像更新。刷新目录以为新 Operator 版本获取更新的内容。
但是,如果您的步骤填充了 filtered 的目录,您需要更新您的镜像流程,以确保在镜像目录中包括
multcluster-engine
Operator 软件包(除了advanced-cluster-management
软件包外)。有关填充镜像 目录时要使用的选项示例,请参阅在断开连接的环境中的 Install。更新您流程中使用的 operator-package 列表,以匹配这些新要求。
更新
MutliclusterHub
资源实例。当在断开连接的环境中安装或升级 hub 集群时,在MulticlusterHub
资源中需要一个新的注解。最佳实践: 更新
MulticlusterHub
资源实例,在将 Operator Lifecycle Manager 订阅中的 Operator Lifecycle Manager 更新频道改为advanced-cluster-management
operator 软件包前包括所需的注解,以开始升级。在这个版本中,升级可以在没有延迟的情况下进行。运行
oc edit
命令以更新Multiclusterub
资源,以添加mce-subscription-spec
注解,如下例所示:metadata: annotations: installer.open-cluster-management.io/mce-subscription-spec: '{"source": "<my-mirror-catalog-source>"}'
将示例中的
<my-mirror-catalog-source>
替换为位于 mirror 目录的openshift-marketplace
命名空间中的CatalogSource
资源的名称。
重要: 如果您在添加注解前开始升级,则升级将开始,但在 Operator 尝试在后台将订阅安装到 multicluster-engine
时停滞。MulticlusterHub
资源的状态在此期间继续显示 upgrading
。
要解决这个问题,请运行 oc edit
来添加 mce-subscription-spec
注解,如前面所示。
1.6.2. 其他资源
1.6.3. 计划集群大小
每个 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.6.3.1. 产品环境
以下要求 不是 环境的最低要求:
节点类型 | 可用区 | etcd | 保留内存总量 | 保留 CPU 总量 |
---|---|---|---|---|
Master | 3 | 3 | OpenShift Container Platform 大小指南 | OpenShift Container Platform 大小指南 |
worker 或基础架构 | 3 | 1 | 12 GB | 6 |
另外,OpenShift Container Platform 集群运行更多服务来支持集群功能。
1.6.3.1.1. OpenShift Container Platform on additional services
可用域(Availability Zone)用来在集群中分离潜在的故障域。
服务 | 节点数 | 可用区 | 实例大小 | vCPU | memory | 存储大小 | 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.6.3.1.2. 创建和管理单一节点 OpenShift Container Platform 集群
查看 在单个节点上安装 以了解具体要求。由于每个集群都是唯一的,因此以下准则只提供了按大小和目的分类的部署要求示例。
可用域(Availability Zone)用来在集群中分离潜在的故障域。典型的集群在三个或更多可用区中具有相等的 worker 节点容量。不支持高可用性。
重要: 对于 OpenShift Container Platform,在三个可用区间分发集群的主节点。
请参阅创建和管理 3500 个单节点 OpenShift Container Platform 集群的示例要求。请参阅 Red Hat Advanced Cluster Management 创建单节点 OpenShift 集群(同时置备230 及更多置备)的最低要求,以及使用 hub 集群管理那些单节点 OpenShift 集群:
节点数 | 内存(集群使用情况) | 内存(单一节点 min-max) | CPU 集群 | CPU 单一节点 |
---|---|---|---|---|
3 | 289 GB | 64 GB - 110 GB | 90 | 44 |