Openshift Container Platform 4.10 Updating Clusters ZH CN

OpenShift Container Platform 4.
10
更新集群
更新 OpenShift Container Platform 集群
Last Updated: 2023-04-21

OpenShift Container Platform 4.10 更新集群
更新 OpenShift Container Platform 集群
法律通告
Copyright © 2023 Red Hat, Inc.
The text of and illustrations in this document are licensed by Red Hat under a Creative Commons
Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is
available at
http://creativecommons.org/licenses/by-sa/3.0/
. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must
provide the URL for the original version.
Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert,
Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.
Red Hat, Red Hat Enterprise Linux, the Shadowman logo, the Red Hat logo, JBoss, OpenShift,
Fedora, the Infinity logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States
and other countries.
Linux ® is the registered trademark of Linus Torvalds in the United States and other countries.
Java ® is a registered trademark of Oracle and/or its affiliates.
XFS ® is a trademark of Silicon Graphics International Corp. or its subsidiaries in the United States
and/or other countries.
MySQL ® is a registered trademark of MySQL AB in the United States, the European Union and
other countries.
Node.js ® is an official trademark of Joyent. Red Hat is not formally related to or endorsed by the
official Joyent Node.js open source or commercial project.
The OpenStack ® Word Mark and OpenStack logo are either registered trademarks/service marks
or trademarks/service marks of the OpenStack Foundation, in the United States and other
countries and are used with the OpenStack Foundation's permission. We are not affiliated with,
endorsed or sponsored by the OpenStack Foundation, or the OpenStack community.
All other trademarks are the property of their respective owners.
摘要
本文档提供了有关更新和升级 OpenShift Container Platform 集群的信息。更新集群的过程较简单，
可以在不需要使集群离线的情况下进行。
目录
目录
. . . 1. 章
第 . . .更新集群概述
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .4. . . . . . . . . . . . .
1.1. 了解 OPENSHIFT CONTAINER PLATFORM 更新 4
1.2. 了解升级频道和发行版本 4
1.3. 了解集群 OPERATOR 条件类型 4
. . . 2. .章
第 . . 了解集群版本状况
.................类
. . .型
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6. . . . . . . . . . . . .
2.1. 准备执行 EUS 更新 6
2.2. 使用 WEB 控制台更新集群 6
2.3. 使用命令行界面(CLI)将集群更新为一个新的次版本 6
2.4. 执行 CANARY ROLLOUT 更新 7
2.5. 更新包含使用 RHEL 的计算（COMPUTE）系统的集群 7
2.6. 在断开连接的环境中更新集群 7
2.7. 更新在 VSPHERE 上运行的节点上运行的硬件 8
. . . 3. .章
第 . . 了解
. . . . . OPENSHIFT
. . . . . . . . . . . . . CONTAINER
. . . . . . . . . . . . . PLATFORM
. . . . . . . . . . . . .更新
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9. . . . . . . . . . . . .
3.1. 关于 OPENSHIFT UPDATE 服务 9
3.2. 常见术语 10
. . . 4. .章
第 . . .了解更新
. . . . . . . .频
. . 道和
. . . . .发
. .行版本
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .11. . . . . . . . . . . . .
4.1. 更新频道 11
. . . 5. .章
第 . . 了解
. . . . . OPENSHIFT
. . . . . . . . . . . . . CONTAINER
. . . . . . . . . . . . . PLATFORM
. . . . . . . . . . . . .更新持
. . . . . . 续时间
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
..............
5.1. 先决条件 15
5.2. 影响更新持续时间的因素 15
5.3. 集群更新阶段 15
5.4. 估算集群更新时间 17
5.5. RED HAT ENTERPRISE LINUX (RHEL) 计算节点 17
. . . 6. .章
第 . . .准
. .备执
. . . .行
. . .EUS
. . . . 更新
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
..............
6.1. EUS 到 EUS 更新 18
. . . 7. .章
第 . . 使用
. . . . . WEB
. . . . . .控制台更新集群
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .22
..............
7.1. 先决条件 22
7.2. 执行 CANARY ROLLOUT 更新 23
7.3. 使用手动维护的凭证升级集群 23
7.4. 使用 WEB 控制台暂停 MACHINEHEALTHCHECK 资源 24
7.5. 关于更新单个节点 OPENSHIFT CONTAINER PLATFORM 25
7.6. 使用WEB控制台更新集群 26
7.7. 使用 WEB 控制台更改更新服务器 27
. . . 8. .章
第 . . .使用
. . . . CLI
. . . . 更新集群
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .28
..............
8.1. 先决条件 28
8.2. 使用手动维护的凭证升级集群 28
8.3. 暂停 MACHINEHEALTHCHECK 资源 30
8.4. 关于更新单个节点 OPENSHIFT CONTAINER PLATFORM 31
8.5. 使用 CLI 更新集群 31
8.6. 根据一个有条件的升级路径进行升级 34
8.7. 使用 CLI 更改更新服务器 35
. . . 9. .章
第 . . .执
. .行
. . CANARY
. . . . . . . . . .ROLLOUT
. . . . . . . . . . .更新
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .36
..............
9.1. 关于 CANARY ROLLOUT 更新过程和 MCP 36
9.2. 关于执行 CANARY ROLLOUT 更新 37
9.3. 创建机器配置池来执行 CANARY ROLLOUT 更新 38
1
9.4. 暂停机器配置池 39
9.5. 执行集群更新 40
9.6. 取消暂停机器配置池 40
9.7. 将节点移到原始机器配置池中 41
. . . 10
第 . . .章
. . 更新包含使用
. . . . . . . . . . . . . .RHEL
. . . . . .的
. .计
. . 算（
. . . . COMPUTE）系
. . . . . . . . . . . . . . . .统
. .的集群
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .42
..............
10.1. 先决条件 42
10.2. 使用WEB控制台更新集群 42
10.3. 可选：添加 HOOK 以在RHEL系统上执行ANSIBLE任务 43
10.4. 更新集群中的RHEL COMPUTE 系统 45
. . . 11. .章
第 . . .在断开
. . . . . .连
. . 接的
....环
. . .境中更新集群
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .49
..............
11.1. 关于在断开连接的环境中的集群更新 49
11.2. 镜像 OPENSHIFT CONTAINER PLATFORM 镜像存储库 49
11.3. 使用 OPENSHIFT UPDATE SERVICE 在断开连接的环境中更新集群 56
11.4. 在没有 OPENSHIFT UPDATE SERVICE 的断开连接的环境中更新集群 65
11.5. 从集群中删除 OPENSHIFT UPDATE SERVICE 73
. . . 12
第 . . .章
. . 更新在
. . . . . . .VSPHERE
. . . . . . . . . . .上
. .运
. .行的
. . . .节
. . 点上
....运
. . .行的硬件
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .77
..............
12.1. 更新 VSPHERE 上的虚拟硬件 77
12.2. 在 VSPHERE 上调度虚拟硬件的更新 79
2
目录
3
第 1 章更新集群概述
您可以使用 Web 控制台或 OpenShift CLI (oc) 使用单一操作来更新 OpenShift Container Platform 4 集
群。
1.1. 了解 OPENSHIFT CONTAINER PLATFORM 更新

关于 OpenShift Update Service ：对于可访问互联网的集群，红帽通过 OpenShift Container Platform 更
新服务提供更新，它作为公共 API 后面的一个托管服务运行。
1.2. 了解升级频道和发行版本
升级频道和发行版本: 使用升级频道，您可以选择一个升级策略。升级频道特定于 OpenShift Container
Platform 的次版本。升级频道仅控制发行版本选择，不会影响您安装的集群版本。OpenShift Container
Platform 的一个特定版本的 openshift-install 二进制文件总会安装该次版本。如需更多信息，请参阅以
下：
升级版本路径
fast 和 stable 频道的使用和策略
了解受限网络集群
在频道间切换
了解条件更新
1.3. 了解集群 OPERATOR 条件类型

集群 Operator 的状态包括它们的 condition 类型，告知您 Operator 的健康状况的当前状态。以下定义涵
盖了一些常见 ClusterOperator 条件类型的列表。省略了具有额外条件类型和特定 Operator 语言的
Operator。
Cluster Version Operator (CVO) 负责从集群 Operator 收集状态条件，以便集群管理员可以更好地了解

OpenShift Container Platform 集群的状态。
available: 条件类型 Available 表示 Operator 功能且在集群中可用。如果状态是 False，则操作

对象中的至少一个部分无法正常工作，并且条件要求管理员干预。
progressing: 条件类型 Progressing 表示 Operator 正在主动推出新的代码、传播配置更改，或

者从一个稳定状态移到另一个状态。
当 Operator 协调之前已知状态时，Operator 不会报告条件类型 Progressing 为 True。如果观
察到的集群状态已更改，且 Operator 会响应它，则状态将报告为 True，因为它从一个 steady 状
态移到另一个状态。
Degraded：条件类型 Degraded 表示 Operator 具有在一段时间内不匹配其所需状态的当前状

态。周期可能会因组件而异，但 Degraded 状态代表 Operator 条件的持久性观察。因
此，Operator 不会波动处于 Degraded 状态和没有处于 Degraded 状态。
如果从一个状态转换到另一个状态的过渡在长时间内没有保留，则可能会有一个不同的条件类型
来报告 Degraded。Operator 在正常升级过程中不会报告 Degraded。Operator 可能会报告
Degraded，以响应需要最终管理员干预的持久性基础架构失败。
注意
4
第 1 章更新集群概述
注意
此条件类型仅表示可能需要调查和调整某项。只要 Operator 可用，Degraded 条

件就不会造成用户工作负载失败或应用程序停机。
Upgradeable: 条件类型 Upgradeable 表示 Operator 是否根据当前的集群状态安全升级。

message 字段包含管理员对集群成功更新需要执行的操作的人类可读描述。当此条件为
True、Unknown 或缺失时，CVO 允许更新。
当 Upgradeable 状态为 False 时，只有次版本更新会受到影响，CVO 会阻止集群执行受影响的
更新，除非强制（强制）更新。
5
第 2 章了解集群版本状况类型
Cluster Version Operator (CVO) 监控集群 Operator 和其他组件，并负责收集集群版本及其 Operator 的
状态。此状态包括条件类型，它告知您 OpenShift Container Platform 集群的健康状态和当前状态。
除了 Available,Progressing, 和 Upgradeable 外，还有影响集群版本和 Operator 的条件类型。
Failing：集群版本状况类型 Failing 表示集群无法访问其所需状态，不健康，需要管理员干预。
Invalid: 集群版本条件类型 Invalid 表示集群版本具有阻止服务器执行操作的错误。只要设置了此

条件，CVO 仅协调当前状态。
RetrievedUpdates ：集群版本条件类型 RetrievedUpdates 表示已从上游更新服务器检索可用更

新。在检索前条件为 Unknown，如果更新最近失败或无法检索，则为 False；如果
availableUpdates 字段是最新且准确的，则为 True。
ReleaseAccepted ：集群版本状况类型 ReleaseAccepted，并带有 True 状态表示请求的发行版

本有效负载在镜像验证和预条件检查过程中没有失败。
2.1. 准备执行 EUS 更新

准备执行 EUS 到 EUS 更新：由于 Kubernetes 的设计，次版本之间的所有 OpenShift Container
Platform 升级都必须按顺序进行。您必须从 OpenShift Container Platform 4.8 更新至 4.9，然后更新至
4.10。您无法直接从 OpenShift Container Platform 4.8 更新至 4.10。但是，如果您想要在两个延长更新
支持(EUS)版本之间更新，您可以只发生一次重启非控制平面主机。如需更多信息，请参阅以下：
更新 EUS 到 EUS
2.2. 使用 WEB 控制台更新集群

使用 Web 控制台将集群更新为一个新的次版本：您可以使用 Web 控制台更新 OpenShift Container
Platform 集群。以下步骤在次版本中更新集群。您可以使用相同的说明在次版本之间更新集群。
执行 canary rollout 更新
暂停 MachineHealthCheck 资源
关于在单节点集群中更新 OpenShift Container Platform
使用Web控制台更新集群
使用 Web 控制台更改更新服务器
2.3. 使用命令行界面(CLI)将集群更新为一个新的次版本
使用 CLI 更新集群的次版本：您可以使用 OpenShift CLI (oc) 更新 OpenShift Container Platform 集
群。以下步骤在次版本中更新集群。您可以使用相同的说明在次版本之间更新集群。
暂停 MachineHealthCheck 资源
关于在单节点集群中更新 OpenShift Container Platform
使用 CLI 更新集群
使用 CLI 更改更新服务器
6
第 2 章了解集群版本状况类型
2.4. 执行 CANARY ROLLOUT 更新

执行 Canary 推出部署更新：通过控制对 worker 节点的更新，您可以确保关键任务应用程序在整个更新
过程中仍然可用，即使更新过程会导致应用程序失败。根据您的机构需求，您可能需要更新一小部分
worker 节点，在一个时间段内评估集群和工作负载健康状况，然后更新剩余的节点。这称为 Canary 更
新。或者，您可能还希望将通常需要主机重新引导的 worker 节点更新放入较小的定义的维护窗口（不可
能一次使用大型维护窗口来更新整个集群）。您可以执行以下步骤：
创建机器配置池来执行 Canary rollout 更新
暂停机器配置池
执行集群更新
取消暂停机器配置池
将节点移动到原始机器配置池
2.5. 更新包含使用 RHEL 的计算（COMPUTE）系统的集群

更新包含 RHEL 计算机器的集群：您可以更新 OpenShift Container Platform 集群。如果您的集群包含
Red Hat Enterprise Linux（RHEL）系统，则必须执行额外的步骤来更新这些系统。您可以执行以下步
骤：
可选：添加 hook 以在RHEL系统上执行Ansible任务
更新集群中的RHEL compute 系统
2.6. 在断开连接的环境中更新集群
在断开连接的环境中的集群更新：如果镜像主机无法同时访问互联网和集群，您可以将镜像镜像到与环境
断开连接的文件系统中。然后您可以使用那个主机或可移动介质来实现安装。如果本地容器 registry 和集
群连接到镜像 registry 的主机，您可以直接将发行镜像推送到本地 registry。
准备您的镜像主机
配置允许对容器镜像进行镜像的凭证
镜像 OpenShift Container Platform 镜像存储库
更新断开连接的集群
配置镜像 registry 存储库镜像
镜像镜像目录的范围，以减少集群节点重启的频率
安装 OpenShift Update Service Operator
创建 OpenShift Update Service 应用程序
删除 OpenShift Update Service 应用程序
卸载 OpenShift Update Service Operator
7
2.7. 更新在 VSPHERE 上运行的节点上运行的硬件

更新 vSphere 上的硬件：您必须确保在 OpenShift Container Platform 支持的硬件版本中运行 vSphere
中运行的节点。目前，硬件版本 13 或更高版本都支持集群中的 vSphere 虚拟机。如需更多信息，请参阅
以下：
更新 vSphere 上的虚拟硬件
在 vSphere 上调度虚拟硬件的更新
重要
在 vSphere 上运行的集群节点使用硬件版本 13 现已弃用。这个版本仍然被完全支持，但在

以后的 OpenShift Container Platform 版本中将会删除支持。现在，硬件版本 15 是
OpenShift Container Platform 中 vSphere 虚拟机的默认版本。
8
第 3 章了解 OPENSHIFT CONTAINER PLATFORM 更新
第 3 章了解 OPENSHIFT CONTAINER PLATFORM 更新

在 OpenShift Container Platform 4 中，您可以使用 Web 控制台或 OpenShift CLI(oc)使用单一操作来更
新 OpenShift Container Platform 集群。当一个更新可用于其集群时，平台管理员会自动获得通知。
OpenShift Update Service(OSUS)根据 registry 中的发行镜像构建了一个更新可能性图。该图基于特定版

本的推荐、经过测试的更新路径。OpenShift Container Platform 集群连接到红帽混合云服务器，并确定
用户正在运行的集群以及版本信息。OSUS 使用已知更新目标的信息做出响应。集群管理员或自动更新控
制器都会编辑 Cluster Version Operator(CVO)的自定义资源(CR)，以及要升级到的新版本。在 CVO 从
registry 接收更新镜像后，CVO 会应用更改。
注意
之前通过 Operator Lifecycle Manager (OLM) 安装的 Operator 会遵循不同的更新过程。

如需更多信息，请参阅更新安装的 Operator。
3.1. 关于 OPENSHIFT UPDATE 服务

OpenShift Update Service (OSUS) 为 OpenShift Container Platform 提供推荐的更新，包括 Red Hat
Enterprise Linux CoreOS (RHCOS)。它提供了一个图表，其中包含组件 Operator 的顶点（vertices）和
连接它们的边（edges）。图中的边代表了您可以安全更新到的版本。顶点是更新的有效负载，用于指定
受管集群组件的预期状态。
集群中的 Cluster Version Operator (CVO) 会检查 OpenShift Container Platform 更新服务，并根据当前
组件版本和图中的信息决定有效的更新和更新路径。当您请求更新时，CVO 使用该更新的发行镜像来升
级您的集群。发行工件 (artifact) 作为容器镜像托管在 Quay 中。
为了让 OpenShift Update Service 仅提供兼容的更新，可以使用一个版本验证管道来驱动自动化过程。每

个发行工件都会被验证是否与支持的云平台和系统架构以及其他组件包兼容。在管道确认有适用的版本
后，OpenShift Update Service 会通知您它可用。
重要
OpenShift Update Service 显示当前集群的所有推荐更新。如果 OpenShift Update

Service 不建议升级路径，这可能是因为更新或目标发行版本存在已知问题。
两个控制器在持续更新模式下运行。第一个控制器持续更新有效负载清单，将清单应用到集群，并输出
Operator 的受控推出的状态，以指示它们是否处于可用、升级或失败状态。第二个控制器轮询 OpenShift
Update Service，以确定更新是否可用。
重要
仅支持升级到较新版本。不支持将集群还原或回滚到以前的版本。如果您的更新失败，请
联系红帽支持。
在更新过程中，Machine Config Operator(MCO)将新配置应用到集群机器。MCO 会处理由

maxUnavailable 字段指定的、协调机器配置池中的节点数量，并将它们标记为不可用。在默认情况下，
这个值被设置为 1。然后，MCO 会应用新配置并重启机器。
如果您将 Red Hat Enterprise Linux (RHEL) 机器用作 worker，MCO 不会在这些机器上更新 kubelet，因
为您必须首先在这些机器上更新 OpenShift API。
当新版本规格应用到旧的 kubelet 时，RHEL 机器无法返回 Ready 状态。在机器可用前，您无法完成更

9
当新版本规格应用到旧的 kubelet 时，RHEL 机器无法返回 Ready 状态。在机器可用前，您无法完成更

新。但是，因为已设置了最大不可用节点数，所以可以在一定机器无法使用的情况下，确保正常的集群操
作。
OpenShift Update Service 由 Operator 和一个或多个应用程序实例组成。
3.2. 常见术语
Control plane（控制平面）
control plane 由 control plane 机器组成，负责管理 OpenShift Container Platform 集群。control
plane 机器管理计算机器（也被称为 worker）上的工作负载。
Cluster Version Operator
Cluster Version Operator (CVO)启动集群的更新过程。它根据当前的集群版本检查 OSUS，并检索包
含可用或可能的更新路径的图形。
Machine Config Operator
Machine Config Operator (MCO)是一个集群级别的 Operator，用于管理操作系统和机器配置。通过
MCO，平台管理员可以配置和更新 worker 节点上的 systemd、CRI-O 和 Kubelet、内核、
NetworkManager 和其他系统功能。
OpenShift 更新服务
OpenShift Update Service (OSUS)为 OpenShift Container Platform 提供无线更新，包括 Red Hat
Enterprise Linux CoreOS(RHCOS)。它提供了一个图形或图表，其中包含组件 Operator 的顶点和连
接它们的边。
Channels
Channels 声明了一个与 OpenShift Container Platform 次版本相关的更新策略。OSUS 使用这个配置
的策略来推荐与该策略一致更新边缘。
推荐的更新边缘
推荐的更新边缘是 OpenShift Container Platform 发行版本之间的建议更新。建议使用给定的更新，
具体取决于集群配置的频道、当前版本、已知的错误和其他信息。OSUS 将建议的边缘与 CVO 通信，
后者在每个集群中运行。
延长更新支持
所有 post-4.7 甚至编号的次版本都标记为延长更新支持 (EUS)版本。这些版本包括了在 EUS 版本之
间更轻松地更新路径，可以简化 worker 节点的更新，并可以通过规划 EUS-to-EUS OpenShift
Container Platform 版本的更新策略来减少重启 worker 节点的更新。
如需更多信息，请参阅 Red Hat OpenShift Extended Update Support(EUS)概述。
其他资源
机器配置概述
更新频道和发行版本
10
第 4 章了解更新频道和发行版本
更新频道是一个升级机制，用户可以声明他们要更新集群的 OpenShift Container Platform 次版本。它们
还允许用户选择更新更新的时间和级别，并通过 fast、stable、candidate 和 eus 频道选项。Cluster
Version Operator 使用基于频道声明的更新图以及其他条件信息，以提供集群可用的推荐和条件更新列
表。
升级频道与 OpenShift Container Platform 的次版本关联。频道中的版本号代表集群最终要升级到的目标

次版本，即使它高于集群的当前次版本。
例如，OpenShift Container Platform 4.10 更新频道提供以下建议：
在 4.10 内更新。
4.9 中的更新。
从 4.9 升级到 4.10，允许所有 4.9 集群最终更新至 4.10，即使它们没有立即满足最小 z-stream 版

本要求。
仅限 eus-4.10：在 4.8 中更新。
仅限 eus-4.10: 从 4.8 升级到 4.9 再到 4.10,，允许所有 4.8 集群最终更新至 4.10。
4.10 更新频道不推荐对 4.11 或更高版本的更新。这可确保管理员明确决定升级到下一个 OpenShift

Container Platform 次版本。
更新频道只控制发行版本选择，不会影响您安装的集群版本。特定版本的 OpenShift Container Platform

的 openshift-install 二进制文件始终会安装该版本。
OpenShift Container Platform 4.10 提供了以下更新频道：
stable-4.10
eus-4.y （只提供 EUS 版本，有助于在 EUS 版本之间进行升级）
fast-4.10
candidate-4.10
如果您不希望 Cluster Version Operator 从升级建议服务获取可用的更新，您可以使用 OpenShift CLI 中

的 oc adm upgrade channel 命令配置空频道。例如，当集群有受限网络访问且没有本地可访问的升级
建议服务时，这个配置很有用。

警告
红帽建议升级到 OpenShift Update Service 建议的版本。对于次版本更新，版本必须

相邻。红帽没有测试在非连续地版本间的升级，无法保证与之前版本的兼容性。
4.1. 更新频道
4.1.1. fast-4.10 频道
11
当红帽声明版本成为正式发行 (GA) 版本时，fast-4.10 频道被更新为 OpenShift Container Platform 4.10

的新版本。因此，这些版本被完全支持，用于生产环境。
4.1.2. stable-4.10 频道
虽然当它们的勘误被发布后马上就会出现在 fast-4.10 频道中，但这些内容可能需要一段延迟时间会被添
加到 stable-4.10 频道中。在这个延迟过程中，会从多个源收集数据并分析用于指示产品回归。收集大量
数据点并且缺少负信号后，这些版本将添加到 stable 频道中。
注意
由于获得大量的数据点所需的时间因很多因素而异，因此在快速频道和稳定频道之间的延
迟期间不会提供 Service LeveL Objective (SLO)。如需更多信息，请参阅"选择集群的正确
频道"
新安装的集群默认为使用 stable 频道。
4.1.3. eus-4.y 频道
除了 stable 频道外，所有以数字相等的 OpenShift Container Platform 次版本都提供延长更新支持
(EUS)。提升到 stable 频道的版本也同时提升到 EUS 频道。EUS 频道的主要目的是，为了方便执行 EUS
到 EUS 更新的集群。
注意
标准和非 EUS 订阅者都可以访问所有 EUS 软件仓库和所需的 RPM(rhel-*-eus-rpms)，它

们都能够支持关键目的，如调试和构建驱动程序。
4.1.4. candidate-4.10 频道
candidate-4.10 频道在构建后马上提供对这个版本的早期访问。只有候选频道中出现的版本可能不包含在
GA 之前删除最终 GA 版本或功能的完整功能集。另外，这些版本没有受到红帽质量保证的约束，可能不
会为以后的 GA 版本提供更新路径。鉴于这些注意事项，候选通道仅适用于销毁和重新创建集群可接受的
目的。
4.1.5. 更新频道中的建议
OpenShift Container Platform 维护一个更新建议服务，它知道已安装的 OpenShift Container Platform
版本以及频道中要获取的路径，以便您获得下一版本。更新路径还仅限于与当前所选频道及其提升特征相
关的版本。
您可在频道中看到以下发行版本：
4.10.0
4.10.1
4.10.3
4.10.4
该服务只建议经过测试且没有已知的严重回归更新。例如，如果您的集群为 4.10.1，OpenShift Container

Platform 推荐 4.10.4，建议从 4.10.1 升级到 4.10.4。
重要
12
重要
您不需要一定在连续的补丁号间进行升级。在这个示例中，该频道并没有（且重来没有包
括 4.10.2），因此不建议或不支持对 4.10.2 的更新。
4.1.6. 更新建议删除和升级
红帽会监控新发布的版本，以及把这些版本添加到支持的频道前后与那些版本关联的更新路径。如果识别
了严重的回归问题，红帽可能会删除受影响的更新建议。当红帽选择删除更新建议时，会在所有相关频道
中同时采取该操作。删除推荐的更新可能会在更新被提升为支持的频道前或之后发生。
如果红帽从任何支持的发行版本中删除更新建议，则会为更正回归的未来版本提供取代的更新建议。但
是，当缺陷被修正、测试并提升到您选择的频道时，可能会有一些延迟。
从 OpenShift Container Platform 4.10 开始，当从支持的频道中删除更新建议时，它们会被替换为声明一

个或多个已知风险的 Conditional Updates。每个已知风险都可能适用于所有集群，或者只应用到与特定
条件匹配的集群。有些示例包括将 Platform 设置为 None，或将 CNI 供应商设置为 OpenShiftSDN。
Cluster Version Operator (CVO) 持续评估当前集群状态的已知风险。如果没有风险匹配，则建议更新。
如果风险匹配，则这些更新被列为受支持但不推荐的更新，并提供了一个参考链接。参考链接可帮助集群
管理员决定是否接受风险和更新。
4.1.7. 为集群选择正确的频道
选择适当的频道涉及两个决策。
首先，选择您要进行集群升级的次要版本。选择与当前版本匹配的频道可确保您只应用 z-stream 更新，

且不会接收功能更新。选择一个大于您当前版本的可用频道，以确保在一个或多个更新后，集群将更新至
该版本。您的集群只提供与当前版本、下一个版本或下一个 EUS 版本匹配的频道。
注意
由于计划在很多次版本间升级的复杂性，频道有助于计划在 EUS 到 EUS 更新之外进行升

级。
其次，您应该选择您需要的 rollout 策略。当红帽声明了一个 GA 版本后，您可以选择从 fast 频道中选择

更新，或者您可能要等待红帽将版本提升到 stable 频道。fast-4.10 和 stable-4.10 中提供的更新建议被完
全支持，并从持续数据分析中同样获益。将发行版本提升到 stable 频道前的提升延迟会重新设置两个频道
之间的唯一区别。对最新 z-streams 的更新通常会在一周或两个时间内提升到 stable 频道，但最初向最新
次版本进行更新的时间更长时的延迟（通常为 45-90 天）。在选择所需频道时请考虑提升延迟，以等待
到 stable 频道的提升可能会影响您的调度计划。
另外，有几个因素可能会导致机构永久或临时将集群移至 fast 频道，包括：
想要应用特定的修复，以便在不延迟的情况下影响您的环境。
在没有延迟的情况下修复 CVE 的应用程序。CVE 修复可能会引入回归问题，因此提升延迟仍然

适用于带有 CVE 修复的 z-streams。
内部测试流程。如果您的组织需要数周时间来证明，则最好与我们提升流程同时测试，而不是等
待。这也保证，红帽提供的任何遥测信号均是我们的推出中因素，因此可以更快地修复与您的问
题相关的问题。
4.1.8. 受限网络集群
如果您自己为 OpenShift Container Platform 集群管理容器镜像，您必须考虑与产品关联的红帽勘误中的
13
如果您自己为 OpenShift Container Platform 集群管理容器镜像，您必须考虑与产品关联的红帽勘误中的

升级信息。在升级过程中，用户界面可能会提醒您在这些版本间进行切换，因此您必须在跳过这些警告前
确定选择了正确的版本。
4.1.9. 在频道间切换
可以从 Web 控制台或通过 adm upgrade channel 命令来切换频道：
$ oc adm upgrade channel <channel>
如果您切换到没有包括当前版本的频道，web 控制台将显示警报。在没有当前发行版本的频道中，web 控
制台不推荐任何更新。但是，您可以在任何时候返回原始频道。
更改您的频道可能会影响集群的可支持性。可能适用以下条件：
如果您从 stable-4.10 频道改到 fast-4.10 频道，您的集群仍然被支持。
您可以随时切换到 candidate-4.10 频道，但该频道中的一些发行版本可能不被支持。
如果您当前的发行本是正式发布版本，则可以从 candidate-4.10 频道切换到 fast-4.10 频道。
您始终可以从 fast-4.10 频道切换到 stable-4.10 频道。如果当前版本最近升级，则可能会有最多

一天的延迟后该发行版本才会出现在 stable-4.10 中。
其他资源
根据一个有条件的升级路径进行升级
为集群选择正确的频道
14
第 5 章了解 OPENSHIFT CONTAINER PLATFORM 更新持续时间

OpenShift Container Platform 更新持续时间因部署拓扑而异。这个页可帮助您了解影响更新持续时间的
因素，并估算集群更新在环境中所需的时间。
5.1. 先决条件
熟悉 OpenShift Container Platform 架构和 OpenShift Container Platform 更新。
5.2. 影响更新持续时间的因素
以下因素可能会影响您的集群更新持续时间：
通过 Machine Config Operator (MCO) 将计算节点重启到新机器配置
机器配置池中的 MaxUnavailable 的值
pod 中断预算 (PDB) 中设定的最小副本数或百分比
集群中的节点数
集群节点的健康状况
5.3. 集群更新阶段
在 OpenShift Container Platform 中，集群更新分为两个阶段：
Cluster Version Operator (CVO) 目标更新有效负载部署
Machine Config Operator (MCO) 节点更新
5.3.1. Cluster Version Operator 目标更新有效负载部署

Cluster Version Operator (CVO) 检索目标更新发行镜像并应用到集群。作为 pod 运行的所有组件都会在
这个阶段更新，主机组件则由 Machine Config Operator (MCO) 更新。这个过程可能需要 60 到 120 分
钟。
注意
更新的 CVO 阶段不会重启节点。
其他资源
Cluster Version Operator (CVO) 概述
5.3.2. Machine Config Operator 节点更新

Machine Config Operator (MCO) 将新机器配置应用到每个 control plane 和计算节点。在此过程
中，MCO 在集群的每个节点中执行以下操作：
1. cordon 和 drain 所有节点
2. 更新操作系统 (OS)
15
3. 重新引导节点
4. 取消协调所有节点并在节点上调度工作负载
注意
当节点被封锁时，工作负载无法调度到其中。
完成此过程的时间取决于多个因素，包括节点和基础架构配置。此过程可能需要 5 分钟或更长时间来完成
每个节点。
除了 MCO 外，您应该考虑以下参数的影响：
control plane 节点更新持续时间是可预测的，通常比计算节点更短，因为 control plane 工作负载

出于安全更新和快速排空进行了调优。
您可以通过将 maxUnavailable 字段设置为在 Machine Config Pool (MCP) 中大于 1 来并行更新

计算节点。MCO 会处理 maxUnavailable 中指定的节点数量，并标记它们无法进行更新。
当您在 MCP 上增加 maxUnavailable 时，它可以帮助池更快地更新。但是，如果

maxUnavailable 太高，且同时处理几个节点，pod 中断预算 (PDB) 保护工作负载可能无法排
空，因为无法找到调度的节点来运行副本。如果您为 MCP 增加 maxUnavailable，请确保仍然有
足够的可调度节点来允许 PDB 保护的工作负载排空。
在开始更新前，您必须确保所有节点都可用。任何不可用的节点都可能会影响更新持续时间，因
为节点不可用会影响 maxUnavailable 和 pod 中断预算。
要从终端中检查节点状态，请运行以下命令：
$ oc get node
输出示例
NAME STATUS ROLES AGE VERSION

ip-10-0-137-31.us-east-2.compute.internal Ready,SchedulingDisabled worker 12d
v1.23.5+3afdacb
ip-10-0-151-208.us-east-2.compute.internal Ready master 12d
v1.23.5+3afdacb
v1.23.5+3afdacb
ip-10-0-183-194.us-east-2.compute.internal Ready worker 12d
v1.23.5+3afdacb
v1.23.5+3afdacb
ip-10-0-207-224.us-east-2.compute.internal Ready worker 12d
v1.23.5+3afdacb
如果节点的状态为 NotReady 或 SchedulingDisabled，则该节点不可用，且这会影响更新持续

时间。
您可以通过展开 Compute → Node 从 web 控制台中的 Administrator 视角检查节点的状态。
其他资源
机器配置概述
16
Pod 中断预算
5.4. 估算集群更新时间
类似集群的历史更新持续时间为您提供了未来集群更新的最佳估算。但是，如果历史数据不可用，您可以
使用以下约定来估算集群更新时间：
Cluster update time = CVO target update payload deployment time + (# node update iterations x
MCO node update time)
节点更新迭代由并行更新的一个或多个节点组成。control plane 节点总会与计算节点并行更新。另外，根

据 maxUnavailable 值可以并行更新一个或多个计算节点。
例如，要估算更新时间，请考虑一个具有三个 control plane 节点的 OpenShift Container Platform 集群，

以及每个主机需要大约 5 分钟才能重启。
注意
重启特定节点所需的时间有很大不同。在云实例中，重新启动可能需要大约 1 到 2 分钟，
而在物理主机中，重新引导可能需要超过 15 分钟。
场景 1
当您将 control plane 和计算节点机器配置池 (MCP) 的 maxUnavailable 设置为 1 时，所有 6 个计算节点
会在每个迭代中逐一进行更新。
Cluster update time = 60 + (6 x 5) = 90 minutes
场景 2
当您为计算节点 MCP 将 maxUnavailable 设置为 2 时，两个计算节点会在每个迭代中并行更新。因此，
它需要三个迭代来更新所有节点。
Cluster update time = 60 + (3 x 5) = 75 minutes
重要
对于 OpenShift Container Platform 中的所有 MCP，maxUnavailable 的默认设置为 1。

建议您不要更改 control plane MCP 中的 maxUnavailable。
5.5. RED HAT ENTERPRISE LINUX (RHEL) 计算节点

Red Hat Enterprise Linux (RHEL) 计算节点需要额外使用 openshift-ansible 来更新节点二进制组件。更
新 RHEL 计算节点的实际时间不应与 Red Hat Enterprise Linux CoreOS (RHCOS) 计算节点有很大不同。
其他资源
更新 RHEL 计算机器
17
第 6 章准备执行 EUS 更新
由于 Kubernetes 的设计，次版本之间的所有 OpenShift Container Platform 升级都必须按顺序进行。您
必须从 OpenShift Container Platform <4.y> 更新至 <4.y+1>，然后更新至 <4.y+2>。您无法直接从
OpenShift Container Platform <4.y> 更新至 <4.y+2>。但是，希望在两个延长更新支持 (EUS) 版本间更新
的管理员可以这样做，而只需要重启一个非 control plane 主机。
重要
EUS 到 EUS 的更新只能在偶数的 OpenShift Container Platform 次版本之间有效。
当尝试进行 EUS 到 EUS 更新时需要考虑很多注意事项。
EUS 到 EUS 更新仅在所有涉及的版本在 stable 频道中提供。
如果您在升级到一个奇数次版本后但在升级到下一个偶数次版本前遇到了问题，则需要在继续进
行前，把非控制平面主机完成升级到奇数次版本。
您可以通过更新 worker 或自定义池节点来对部分更新进行部分更新，以适应维护所需的时间。
您可以在多个维护窗口期间通过暂停中间步骤完成升级过程。但是，计划在 60 天内完成整个更
新。确保完成正常的集群自动化过程非常重要，包括与证书轮转关联的操作。
在机器配置池被取消暂停且更新完成前，OpenShift Container Platform 的 <4.y+1> 和 <4.y+2> 中

的一些功能和程序错误修复不可用。
所有集群可能会在不需要暂停池的情况下，对常规更新使用 EUS 频道进行更新，但只有具有非控

制平面 MachineConfigPools 对象的集群可以进行 EUS 到 EUS 的更新，且需要暂停池。
6.1. EUS 到 EUS 更新

以下流程暂停所有非 master 机器配置池，并从 OpenShift Container Platform 4.8 升级到 4.9 再到
4.10，然后取消暂停之前暂停的机器配置池。以下过程减少了升级持续时间，以及重启 worker 节点的次
数。
先决条件
查看 OpenShift Container Platform 4.9 和 4.10 发行注记
查看任何层次产品和 Operator Lifecycle Manager (OLM) Operator 的发行注记和产品生命周

期。有些操作可能需要在 EUS 到 EUS 更新之前或进行中进行。
6.1.1. 使用 Web 控制台进行 EUS 到 EUS 更新
先决条件
验证机器配置池是否已取消暂停。
使用具有 admin 权限的用户登陆到 web 控制台。
流程
1. 使用 Web 控制台中的 Administrator 视角，将任何 Operator Lifecycle Manager (OLM) Operator
18

更新至与您的预期更新版本兼容的版本。您可以在"更新安装的 Operator"中找到有关如何执行此
操作的更多信息；请参阅"添加资源"。
2. 验证所有机器配置池的状态是否为 Up to date，并且没有机器配置池显示 UPDATING 的状态。

要查看所有机器配置池的状态，请点 Compute → MachineConfigPools 并查看 Update status
列的内容。
注意
如果您的机器配置池具有 Updating 状态，请等待此状态更改为 Up to date。这个

过程可能需要几分钟时间。
3. 将频道设置为 eus-<4.y+2>。
要设置您的频道，请点 Administration → Cluster Settings → Channel。您可以点当前的超链接
频道来编辑频道。
4. 暂停除 master 池外的所有 worker 机器池。您可以在 Compute 页面的 MachineConfigPools 标

签页中执行此操作。选择您要暂停的机器配置池旁边的垂直图标，然后点暂停更新。
5. 更新至 <4.y+1> 版本并完成到 Save 步骤。您可以在"使用 Web 控制台更新集群"中找到有关如何

执行这些操作的更多信息；请参阅"添加资源"。
6. 通过查看集群的最新完成的版本，确保 <4.y+1> 更新已完成。您可以在 Details 选项卡下的

Cluster Settings 页面中找到此信息。
7. 如有必要，使用 web 控制台中的 Administrator 视角更新 OLM Operator。您可以在"更新安装的

Operator"中找到有关如何执行此操作的更多信息；请参阅"添加资源"。
8. 更新至 <4.y+2> 版本并完成到 Save 步骤。您可以在"使用 Web 控制台更新集群"中找到有关如何

执行这些操作的更多信息；请参阅"添加资源"。
9. 通过查看集群的最新完成的版本，确保 <4.y+2> 更新已完成。您可以在 Details 选项卡下的

10. 取消暂停所有之前暂停的机器配置池。您可以在 Compute 页面的 MachineConfigPools 标签页

中执行此操作。选择您要暂停的机器配置池旁边的垂直图标，然后点 Unpause updates。
重要
如果没有取消暂停池，集群就无法升级到将来的任何次要版本，而维护任务（如证
书轮转）会被禁止。这会使集群面临未来降级的风险。
11. 验证之前暂停的池是否已更新，并且集群是否完成了更新到版本 <4.y+2>。

您可以通过 Compute 页中的 MachineConfigPools 标签页来验证您的池已更新。其 Update
status 应用带有一个 Up to date 值。
您可以通过查看集群的最新完成版本来验证集群是否已完成更新。您可以在 Details 选项卡下的

其他资源
准备 Operator 更新
19
更新安装的 Operator
6.1.2. 使用 CLI 进行 EUS 到 EUS 更新
先决条件
验证机器配置池是否已取消暂停。
每次更新前，将 OpenShift CLI (oc) 更新至目标版本。
重要
强烈建议您跳过此先决条件。如果在更新前没有将 OpenShift CLI (oc) 更新至目标版本，

则可能会出现意外的问题。
流程

更新至与您的预期更新版本兼容的版本。您可以在"更新安装的 Operator"中找到有关如何执行此
操作的更多信息；请参阅"添加资源"。
2. 验证所有机器配置池的状态是否为 UPDATED，并且没有机器配置池显示 UPDATING 的状态。

要查看所有机器配置池的状态，请运行以下命令：
$ oc get mcp
输出示例
NAME CONFIG UPDATED UPDATING

master rendered-master-ecbb9582781c1091e1c9f19d50cf836c True False
worker rendered-worker-00a3f0c68ae94e747193156b491553d5 True False
3. 您当前版本为 <4.y>，您想要更新的预期版本为 <4.y+2>。运行以下命令，进入 eus-<4.y+2> 频

道：
$ oc adm upgrade channel eus-<4.y+2>
注意
如果您收到一条错误消息，表示 eus-<4.y+2> 不是可用频道之一，这表示红帽对

EUS 版本更新的推出仍在进行中。本推出过程通常在 GA 日期开始 45-90 天。
4. 运行以下命令，暂停除 master 池之外的所有 worker 机器池：
$ oc patch mcp/worker --type merge --patch '{"spec":{"paused":true}}'
注意
您无法暂停 master 池。
5. 运行以下命令来更新到最新版本：
20
$ oc adm upgrade --to-latest
输出示例
Updating to latest version <4.y+1.z>
6. 运行以下命令，查看集群版本以确保更新已完成：
$ oc adm upgrade
输出示例
Cluster version is <4.y+1.z>

...
7. 运行以下命令，更新至 <4.y+2> 版本：
$ oc adm upgrade --to-latest
8. 运行以下命令，检索集群版本以确保 <4.y+2> 更新已完成：
$ oc adm upgrade
输出示例
Cluster version is <4.y+1.z>

...
9. 要将 worker 节点更新至 <4.y+2>，请运行以下命令取消暂停所有之前暂停的机器配置池：
$ oc patch mcp/worker --type merge --patch '{"spec":{"paused":false}}'
重要
如果没有取消暂停池，集群就无法升级到将来的任何次要版本，而维护任务（如证
书轮转）会被禁止。这会使集群面临未来降级的风险。
10. 运行以下命令，验证之前暂停的池是否已更新，并升级到 <4.y+2> 版本：
$ oc get mcp
输出示例

master rendered-master-52da4d2760807cb2b96a3402179a9a4c True False
worker rendered-worker-4756f60eccae96fb9dcb4c392c69d497 True False
其他资源
更新安装的 Operator
21
第 7 章使用 WEB 控制台更新集群
您可以使用 web 控制台对 OpenShift Container Platform 集群进行更新或升级。以下步骤在次版本中更
新集群。您可以使用相同的说明在次版本之间更新集群。
注意
使用 Web 控制台或 oc adm upgrade channel <channel> 更改更新频道。在改到一个

4.10 频道后，按照使用 CLI 更新集群中介绍的步骤进行操作。
7.1. 先决条件
使用具有 admin 权限的用户访问集群。请参阅使用 RBAC 定义和应用权限。
具有最新的 etcd 备份，以防因为升级失败需要将集群恢复到以前的状态。
OpenShift Container Platform 4.10 中删除了对 RHEL7 worker 的支持。在升级到 OpenShift

Container Platform 4.10 前，您必须将 RHEL7 worker 替换为 RHEL8 或 RHCOS worker。红帽不
支持对 RHEL worker 的从 RHEL7 到 RHEL8 的原位升级 ; 这些主机必须使用干净的操作系统安
装替换。
确保之前通过 Operator Lifecycle Manager（OLM）安装的所有 Operator 均更新至其最新频道

中的最新版本。更新 Operator 可确保当默认 OperatorHub 目录在集群升级过程中从当前次要版
本切换到下一个次版本时，它们有有效的升级路径。如需更多信息，请参阅更新安装的
Operator。
确保所有机器配置池 (MCP) 都正在运行且未暂停。在更新过程中跳过与暂停 MCP 关联的节点。

如果要执行 canary rollout 更新策略，可以暂停 MCP。
要容纳更新所需的时间，您可以通过更新 worker 或自定义池节点来进行部分更新。您可以在每个

池的进度栏中暂停并恢复。
如果您的集群使用手动维护的凭证，请确保 Cloud Credential Operator（CCO）处于可升级状

态。如需更多信息，请参阅使用手动维护的凭证升级集群。
如果您的集群通过 AWS Secure Token Service (STS) 使用手动维护的凭证，请从要升级到的发行

镜像获取 ccoctl 实用程序的副本，并使用它来处理任何更新的凭证。如需更多信息，请参阅使用
STS 升级为手动模式配置的 OpenShift Container Platform 集群。
如果您运行 Operator 或您已配置了 pod 中断预算，您可能会在升级过程中遇到中断。如果在

PodDisruptionBudget 中将 minAvailable 设置为 1，则节点会排空以应用可能会阻止驱除过程
的待处理机器配置。如果重启了几个节点，则所有 pod 只能有一个节点上运
行，PodDisruptionBudget 字段可能会阻止节点排空。
重要
当更新无法完成时，Cluster Version Operator(CVO)会在尝试协调更新时报告任

何阻塞组件的状态。当前还不支持将集群还原到以前的版本。如果您的更新无法完
成，请联系红帽支持。
使用 unsupportedConfigOverrides 部分修改 Operator 配置不受支持，并可能会

阻止集群更新。您必须在更新集群前删除此设置。
其他资源
22
非受管 Operator 的支持策略
7.2. 执行 CANARY ROLLOUT 更新

在某些情况下，您可能需要一个受控的更新过程，如您不希望特定节点与集群的其余部分同时更新。这些
用例包括但不限于：
您有任务关键型应用程序，您希望在更新过程中仍然可以使用这些应用程序。在更新后，您可以
慢慢地以小批的形式对应用进行测试。
您有一个短的维护窗口，在此期间不允许更新所有节点；或者您有多个维护窗口。
滚动更新过程不是典型的更新工作流。对于较大的集群，这可能是一个耗时的过程，需要您执行多个命
令。这种复杂性可能会导致出现可能会影响整个集群的错误。建议您仔细考虑您的机构是否希望使用滚动
更新，并在开始前仔细规划流程的实施。
本主题中描述的滚动更新过程涉及：
创建一个或多个自定义机器配置池 (MCP)。
标记您不想立即更新的每个节点，以将这些节点移至自定义 MCP。
暂停这些自定义 MCP，这会阻止对这些节点的更新。
执行集群更新。
取消暂停一个自定义 MCP，它会在这些节点上触发更新。
测试这些节点上的应用程序，以确保应用程序在这些新更新的节点上可以正常工作。
（可选）从小批处理中的其余节点移除自定义标签，并在这些节点上测试应用。
注意
暂停 MCP 可防止 Machine Config Operator 在关联的节点上应用任何配置更改。暂停

MCP 还可以防止任何自动轮转的证书被推送到关联的节点，包括自动轮转 kube-
apiserver-to-kubelet-signer CA 证书。如果 kube-apiserver-to-kubelet-signer CA 证书
过期且 MCO 尝试自动更新证书时，MCP 会暂停，但不会在相应机器配置池中的节点中应
用新证书。这会导致多个 oc 命令失败，包括但不限于 oc debug、oc logs、oc exec 和
oc attach。在暂停 MCP 时应该非常小心，需要仔细考虑 kube-apiserver-to-kubelet-
signer CA 证书过期的问题，且仅在短时间内暂停。
如果要使用 Canary rollout 更新过程，请参阅执行 Canary 推出部署更新。
7.3. 使用手动维护的凭证升级集群
默认情况下，带有手动维护凭证的集群的 Cloud Credential Operator(CCO)U gradable 状态为 False。
对于次发行版本（例如从 4.9 升级到 4.10），这个状态会阻止升级，直到您解决了任何更新的权

限并添加了 CloudCredential 资源，以指示下一版本根据需要更新权限。此注解将 Upgradable
状态更改为 True。
对于 z-stream 版本（例如从 4.10.0 到 4.10.1），没有添加或更改任何权限，因此不会阻止升级。
在使用手动维护凭证升级集群前，您必须为要升级到的发行镜像创建新凭证。另外，您必须检查现有凭证
23
所需的权限，并满足新版本中这些组件的任何新权限要求。
流程
1. 提取并检查新版本的 CredentialsRequest 自定义资源。

详情请参阅您的云供应商的“手动创建 IAM”部分来了解如何获取和使用您的云所需的凭证。
2. 更新集群中手动维护的凭证：
为新发行镜像添加的任何 CredentialsRequest 自定义资源创建新 secret。
如果存储在 secret 中的任何现有凭证的 CredentialsRequest 自定义资源更改了其权限要

求，请根据需要更新权限。
3. 当所有 secret 都对新发行版本正确时，表示集群已准备好升级：
a. 以具有 cluster-admin 角色的用户身份登录 OpenShift Container Platform CLI。
b. 编辑 CloudCredential 资源，以在 metadata 字段中添加可升级至注解：
$ oc edit cloudcredential cluster
要添加的文本
...
metadata:
annotations:
cloudcredential.openshift.io/upgradeable-to: <version_number>
...
其中 <version_number> 是您要升级到的版本，格式为 x.y.z。例如，OpenShift Container

Platform 4.8.2 代表 OpenShift Container Platform 4.8.2。
添加可升级状态进行更改的注解后，可能需要几分钟时间。
验证
1. 在 Web 控制台的 Administrator 视角中，导航到 Administration → Cluster Settings。
2. 要查看 CCO 状态详情，请点击 Cluster Operators 列表中的 cloud-credential。
a. 如果 Conditions 部分中的 Upgradeable 状态为 False，请验证 upgradeable-to 注解没有拼

写错误。当 Conditions 部分中的 Upgradeable 状态为 True 时，您可以开始 OpenShift
Container Platform 升级。
其他资源
为 AWS 手动创建 IAM
为 Azure 手动创建 IAM
为 GCP 手动创建 IAM
7.4. 使用 WEB 控制台暂停 MACHINEHEALTHCHECK 资源
24
在升级过程中，集群中的节点可能会临时不可用。对于 worker 节点，机器健康检查可能会认为这样的节

点不健康，并重新引导它们。为避免重新引导这样的节点，请在更新集群前暂停所有
MachineHealthCheck 资源。
先决条件
您可以使用 cluster-admin 权限访问集群。
访问 OpenShift Container Platform web 控制台。
流程
1. 登陆到 OpenShift Container Platform Web 控制台。
2. 进入到 Compute → MachineHealthChecks。
3. 要暂停机器健康检查，请在每个 MachineHealthCheck 资源中添加 cluster.x-k8s.io/paused=""

注解。例如，要将注解添加到 machine-api-termination-handler 资源，请完成以下步骤：
a. 点 machine-api-termination-handler 旁边的 Options 菜单并点 Edit annotations。
b. 在 Edit annotations 对话框中，点 Add more。
c. 在 Key 和 Value 字段中，分别添加 cluster.x-k8s.io/paused 和 "" 值，然后点 Save。
7.5. 关于更新单个节点 OPENSHIFT CONTAINER PLATFORM

您可以使用控制台或 CLI 更新或升级单节点 OpenShift Container Platform 集群。
但请注意以下限制：
不需要暂停 MachineHealthCheck 资源，因为没有其他节点可以执行健康检查。
不支持使用 etcd 备份来恢复单节点 OpenShift Container Platform 集群。但是，最好在升级失败

时执行 etcd 备份。如果 control plane 健康，您可以使用备份将集群恢复到以前的状态。
更新单节点 OpenShift Container Platform 集群需要停机，并可包括自动重启。停机时间取决于

更新有效负载，如下例所示：
如果更新有效负载包含操作系统更新（需要重启），则停机时间会非常显著，并影响集群管
理和用户工作负载。
如果更新包含不需要重启的机器配置更改，则停机时间会减少，并且对集群管理和用户工作
负载的影响会减少。在这种情况下，节点排空步骤会通过单节点 OpenShift Container
Platform 跳过，因为集群中没有其他节点可以重新调度工作负载。
如果更新有效负载不包含操作系统更新或机器配置更改，则会出现简短的 API 中断并快速解

决。
重要
某些条件（如更新的软件包中的错误）可能会导致单个节点在重启后无法重启。在这种情
况下，更新不会自动回滚。
25
其他资源
有关机器配置更改需要重启的详情，请参考了解 Machine Config Operator 的备注。
7.6. 使用WEB控制台更新集群
如果有可用更新，您可以从Web控制台更新集群。
您可以在客户门户网站的勘误部分找到有关可用 OpenShift Container Platform 公告和更新的信息。
先决条件
暂停所有 MachineHealthCheck 资源。
流程
1. 在 web 控制台中点击 Administration → Cluster Settings 并查看 Details 选项卡中的内容。
2. 对于生产环境中的集群，请确保将 Channel 设置为您要升级到的版本的正确频道，如 stable-

4.10。
重要
对于生产环境中的集群，您必须订阅一个 stable-*, eus-* 或 fast-* 频道。
注意
当您准备好升级到下一个次版本时，请选择与该次版本对应的频道。声明更新频道
后，集群可以更方便地为您的目标版本更新路径。集群可能需要一些时间来评估所
有可用的更新，并提供最佳更新建议。更新建议可能会随时间变化，因为它们基于
哪些更新选项。
如果您无法看到到目标次版本的更新路径，请保持将集群更新至当前版本的最新补
丁版本，直到下一个次版本在路径中可用。
如果 Update 状态不是 Updates available，则无法升级集群。
Select channel 表示集群正在运行或正在更新的集群版本。
3. 选择要更新到的版本，然后单击 Save。
输入频道 Update Status 变为Update to <product-version> in progress，您可以通过监视
Operator 和节点的进度条来查看集群更新的进度。
注意
如果您要将集群升级到下一个次版本，如从 4.y 升级到 4.(y+1)，建议在部署依赖新

功能的工作负载前确认您的节点已升级：任何尚未更新的 worker 节点池都会显示
在 Cluster Settings 页面。
4. 更新完成后，Cluster Version Operator 会刷新可用更新，检查当前频道中是否有更多可用更新。
如果有可用更新，请继续在当前频道中执行更新，直到您无法再更新为止。
如果没有可用的更新，请将 Channel 改为下一个次版本的 stable-*, eus-* 或 fast-* 频道，并
26

更新至您在该频道中想要的版本。
您可能需要执行一些过渡的更新，直到您到达您想要的版本。
7.7. 使用 WEB 控制台更改更新服务器

更改更新服务器是可选的。如果您在本地安装和配置了 OpenShift Update Service (OSUS)，您必须将服
务器的 URL 设置为 upstream，以便在更新期间使用本地服务器。
流程
1. 导航到 Administration → Cluster Settings，点 version。
2. 点击 YAML 选项卡，然后编辑 upstream 参数值：
输出示例
...
spec:
clusterID: db93436d-7b05-42cc-b856-43e11ad2d31a
upstream: '<update-server-url>' 1
...
1 <update-server-url> 变量指定更新服务器的 URL。
默认 upstream 是 https://api.openshift.com/api/upgrades_info/v1/graph。
3. 点 Save。
其他资源
了解升级频道和发行版本
27
第 8 章使用 CLI 更新集群
您可以使用 OpenShift CLI (oc) 将 OpenShift Container Platform 集群更新或升级到一个次版本。您还可
以按照相同的说明在次版本间更新集群。
8.1. 先决条件

装替换。
确保之前通过 Operator Lifecycle Manager（OLM）安装的所有 Operator 均更新至其最新频道

中的最新版本。更新 Operator 可确保当默认 OperatorHub 目录在集群升级过程中从当前次要版
本切换到下一个次版本时，它们有有效的升级路径。如需更多信息，请参阅更新安装的
Operator。


态。如需更多信息，请参阅使用手动维护的凭证升级集群。

STS 升级为手动模式配置的 OpenShift Container Platform 集群。
确保您解决了所有 Upgradeable=False 条件，以便集群允许升级到下一个次版本。您可以运行

oc adm upgrade 命令以了解所有 Upgradeable=False 条件的输出，以及帮助您为次版本更新
做准备的条件。

重要
当更新无法完成时，Cluster Version Operator(CVO)会在尝试协调更新时报告任

何阻塞组件的状态。当前还不支持将集群还原到以前的版本。如果您的更新无法完
成，请联系红帽支持。
使用 unsupportedConfigOverrides 部分修改 Operator 配置不受支持，并可能会

阻止集群更新。您必须在更新集群前删除此设置。
其他资源
8.2. 使用手动维护的凭证升级集群
28
默认情况下，带有手动维护凭证的集群的 Cloud Credential Operator(CCO)U gradable 状态为 False。
对于次发行版本（例如从 4.9 升级到 4.10），这个状态会阻止升级，直到您解决了任何更新的权

限并添加了 CloudCredential 资源，以指示下一版本根据需要更新权限。此注解将 Upgradable
状态更改为 True。
对于 z-stream 版本（例如从 4.10.0 到 4.10.1），没有添加或更改任何权限，因此不会阻止升级。
所需的权限，并满足新版本中这些组件的任何新权限要求。
流程
1. 提取并检查新版本的 CredentialsRequest 自定义资源。

详情请参阅您的云供应商的“手动创建 IAM”部分来了解如何获取和使用您的云所需的凭证。
2. 更新集群中手动维护的凭证：
为新发行镜像添加的任何 CredentialsRequest 自定义资源创建新 secret。
如果存储在 secret 中的任何现有凭证的 CredentialsRequest 自定义资源更改了其权限要

求，请根据需要更新权限。
3. 当所有 secret 都对新发行版本正确时，表示集群已准备好升级：
a. 以具有 cluster-admin 角色的用户身份登录 OpenShift Container Platform CLI。
b. 编辑 CloudCredential 资源，以在 metadata 字段中添加可升级至注解：
$ oc edit cloudcredential cluster
要添加的文本
...
metadata:
annotations:
cloudcredential.openshift.io/upgradeable-to: <version_number>
...
其中 <version_number> 是您要升级到的版本，格式为 x.y.z。例如，OpenShift Container

Platform 4.8.2 代表 OpenShift Container Platform 4.8.2。
添加可升级状态进行更改的注解后，可能需要几分钟时间。
验证
1. 在 Web 控制台的 Administrator 视角中，导航到 Administration → Cluster Settings。
2. 要查看 CCO 状态详情，请点击 Cluster Operators 列表中的 cloud-credential。
a. 如果 Conditions 部分中的 Upgradeable 状态为 False，请验证 upgradeable-to 注解没有拼

写错误。当 Conditions 部分中的 Upgradeable 状态为 True 时，您可以开始 OpenShift
Container Platform 升级。
其他资源
29
为 AWS 手动创建 IAM
为 Azure 手动创建 IAM
为 GCP 手动创建 IAM
8.3. 暂停 MACHINEHEALTHCHECK 资源
先决条件
安装 OpenShift CLI (oc) 。
流程
1. 要列出您要暂停的所有可用 MachineHealthCheck 资源，请运行以下命令：
$ oc get machinehealthcheck -n openshift-machine-api
2. 要暂停机器健康检查，请将 cluster.x-k8s.io/paused="" 注解添加到 MachineHealthCheck 资

源。运行以下命令:
$ oc -n openshift-machine-api annotate mhc <mhc-name> cluster.x-k8s.io/paused=""
注解的 MachineHealthCheck 资源类似以下 YAML 文件：
apiVersion: machine.openshift.io/v1beta1
kind: MachineHealthCheck
metadata:
name: example
namespace: openshift-machine-api
annotations:
cluster.x-k8s.io/paused: ""
spec:
selector:
matchLabels:
role: worker
unhealthyConditions:
- type: "Ready"
status: "Unknown"
timeout: "300s"
- type: "Ready"
status: "False"
timeout: "300s"
maxUnhealthy: "40%"
status:
currentHealthy: 5
expectedMachines: 5
重要
30
重要
更新集群后恢复机器健康检查。要恢复检查，请运行以下命令从
MachineHealthCheck 资源中删除暂停注解：
$ oc -n openshift-machine-api annotate mhc <mhc-name> cluster.x-

k8s.io/paused-
8.4. 关于更新单个节点 OPENSHIFT CONTAINER PLATFORM

您可以使用控制台或 CLI 更新或升级单节点 OpenShift Container Platform 集群。
但请注意以下限制：
不需要暂停 MachineHealthCheck 资源，因为没有其他节点可以执行健康检查。
不支持使用 etcd 备份来恢复单节点 OpenShift Container Platform 集群。但是，最好在升级失败

时执行 etcd 备份。如果 control plane 健康，您可以使用备份将集群恢复到以前的状态。
更新单节点 OpenShift Container Platform 集群需要停机，并可包括自动重启。停机时间取决于

更新有效负载，如下例所示：
如果更新有效负载包含操作系统更新（需要重启），则停机时间会非常显著，并影响集群管
理和用户工作负载。
如果更新包含不需要重启的机器配置更改，则停机时间会减少，并且对集群管理和用户工作
负载的影响会减少。在这种情况下，节点排空步骤会通过单节点 OpenShift Container
Platform 跳过，因为集群中没有其他节点可以重新调度工作负载。
如果更新有效负载不包含操作系统更新或机器配置更改，则会出现简短的 API 中断并快速解

决。
重要
某些条件（如更新的软件包中的错误）可能会导致单个节点在重启后无法重启。在这种情
况下，更新不会自动回滚。
其他资源
有关机器配置更改需要重启的详情，请参考了解 Machine Config Operator 的备注。
8.5. 使用 CLI 更新集群

如果有可用更新，您可以使用OpenShift CLI (oc)更新集群。
先决条件
安装与更新版本的版本匹配的 OpenShift CLI(oc)。
使用具有 cluster-admin 权限的用户登陆到集群。
31
流程
1. 查看可用更新，记录下要应用的更新的版本号：
$ oc adm upgrade
输出示例
Cluster version is 4.9.23
Upstream is unset, so the cluster will use an appropriate default.

Channel: stable-4.9 (available channels: candidate-4.10, candidate-4.9, fast-4.10, fast-4.9,
stable-4.10, stable-4.9, eus-4.10)
Recommended updates:
VERSION IMAGE
4.9.24 quay.io/openshift-release-dev/ocp-
release@sha256:6a899c54dda6b844bb12a247e324a0f6cde367e880b73ba110c056df6d01803
2
release@sha256:2eafde815e543b92f70839972f585cc52aa7c37aa72d5f3c8bc886b0fd45707a
release@sha256:3ccd09dd08c303f27a543351f787d09b83979cd31cf0b4c6ff56cd68814ef6c8
release@sha256:1c7db78eec0cf05df2cead44f69c0e4b2c3234d5635c88a41e1b922c3bedae16
release@sha256:4084d94969b186e20189649b5affba7da59f7d1943e4e5bc7ef78b981eafb7a8
release@sha256:b04ca01d116f0134a102a57f86c67e5b1a3b5da1c4a580af91d521b8fa0aa6ec
release@sha256:2a28b8ebb53d67dd80594421c39e36d9896b1e65cb54af81fbb86ea9ac3bf2d
7
release@sha256:ecdb6d0df547b857eaf0edb5574ddd64ca6d9aff1fa61fd1ac6fb641203bedfa
注意
有关如何执行 EUS 到 EUS 频道升级的详情，请参阅附加资源部分中列出的准备

执行 EUS 升级页面。
2. 根据您的机构要求，设置适当的升级频道。例如，您可以将频道设置为 stable-4.10、fast-4.10 或
eus-4.10。有关频道的更多信息，请参阅在额外资源项中的了解更新频道和发行版本。
$ oc adm upgrade channel <channel>
例如，要将频道设置为 stable-4.10 ：
$ oc adm upgrade channel stable-4.10
32
重要
对于生产环境中的集群，您必须订阅一个 stable-*、eus-* 或 fast-* 频道。
注意
3. 应用更新：
要更新到最新版本：
$ oc adm upgrade --to-latest=true 1
要更新到一个特定版本：
$ oc adm upgrade --to=<version> 1
1 1 <version> 是从 oc adm upgrade 命令的输出中获取的更新版本。
4. 查看 Cluster Version Operator 的状态：
$ oc adm upgrade
5. 更新完成后，可以通过以下方法确认集群已更新为新版本：
$ oc get clusterversion
输出示例
Cluster version is <version>
Upstream is unset, so the cluster will use an appropriate default.

Channel: stable-4.10 (available channels: candidate-4.10, candidate-4.11, eus-4.10, fast-4.10,
fast-4.11, stable-4.10)
No updates available. You may force an upgrade to a specific release image, but doing so
might not be supported and might result in downtime or data loss.
注意
33
注意
如果 oc get clusterversion 命令在 PROGRESSING 状态为 True 时显示以下错

误，您可以忽略这个错误。
NAME VERSION AVAILABLE PROGRESSING SINCE STATUS

version 4.10.26 True True 24m Unable to apply 4.11.0-rc.7: an
unknown error has occurred: MultipleErrors
6. 如果您要将集群升级到下一个次版本，如 X.y 升级到 X. (y+1)，建议在部署依赖新功能的工作负载

前确认您的节点已升级：
$ oc get nodes
输出示例

ip-10-0-168-251.ec2.internal Ready master 82m v1.23.12+8a6bfe4
ip-10-0-179-95.ec2.internal Ready worker 70m v1.23.12+8a6bfe4
其他资源
准备执行 EUS 更新
8.6. 根据一个有条件的升级路径进行升级
您可以使用 Web 控制台或 OpenShift CLI(oc)根据一个有条件的升级路径进行升级。当一个有条件更新对
于您的集群不推荐进行时，您可以使用 OpenShift CLI(oc)4.10 或更高版本来根据一个有条件的路径进行
升级。
流程
1. 因为存在风险而不推荐的更新，您可以使用以下命令查看它的描述信息：
$ oc adm upgrade --include-not-recommended
2. 如果集群管理员已评估了潜在的已知风险，并确定这些风险对于当前集群是可接受的，管理员可
以执行以下命令来忽略这些安全保护并继续更新：
$ oc adm upgrade --allow-not-recommended --to <version> <.>
<.> <version>是从上一个命令输出中获取的被支持但不推荐的更新版本。
其他资源
升级频道和发行路径
34
8.7. 使用 CLI 更改更新服务器

更改更新服务器是可选的。如果您在本地安装和配置了 OpenShift Update Service (OSUS)，您必须将服
务器的 URL 设置为 upstream，以便在更新期间使用本地服务器。upstream 的默认值是
https://api.openshift.com/api/upgrades_info/v1/graph。
流程
更改集群版本中的 upstream 参数值：
$ oc patch clusterversion/version --patch '{"spec":{"upstream":"<update-server-url>"}}' --

type=merge
<update-server-url> 变量指定更新服务器的 URL。
输出示例
clusterversion.config.openshift.io/version patched
35
第 9 章执行 CANARY ROLLOUT 更新
有些情况下，您可能希望对 worker 节点进行更多受控的更新推出，以确保任务关键型应用程序在更新过
程中仍然可用，即使更新过程导致您的应用程序失败。根据您的机构需求，您可能需要更新一小部分
worker 节点，在一个时间段内评估集群和工作负载健康状况，然后更新剩余的节点。这通常被称为
Canary 更新。或者，您可能还希望将通常需要主机重新引导的 worker 节点更新放入较小的定义的维护窗
口（不可能一次使用大型维护窗口来更新整个集群）。
在这些情况下，您可以创建多个自定义机器配置池 (MCP)，以防止某些 worker 节点在更新集群时进行更

新。在更新剩余的集群后，您可以在适当的时间批量更新这些 worker 节点。
例如，如果您的集群有 100 个节点，且有 10% 过量的容量，维护窗口不能超过 4 小时，并且您知道排空

和重新引导 worker 节点的时间不超过 8 分钟，您可以利用 MCP 来实现您的目标。例如，您可以定义四
个 MCP，分别名为 workerpool-canary、workerpool-A、workerpool-B 和 workerpool-C，分别有
10、30、30 和 30 个节点。
在第一次维护窗口中，您将暂停 workerpool-A、workerpool-B 和 workerpool-C 的 MCP，然后启动集

群更新。这会更新在 OpenShift Container Platform 上运行的组件，以及属于 workerpool-canary MCP
成员的 10 个节点，因为这个池没有暂停。其他三个 MCP 不会更新，因为它们已暂停。如果出于某种原
因，您确定集群或工作负载健康受到 workerpool-canary 更新的负面影响，那么在分析完问题前，您会
在保持足够容量的同时，对那个池中的所有节点进行 cordon 和 drain 操作。当一切正常时，您将在决定
取消暂停前评估集群和工作负载健康状况，从而在每个额外的维护窗口中持续更新 workerpool-
A、workerpool-B 和 workerpool-C。
使用自定义 MCP 管理 worker 节点更新提供了灵活性，这可能是一个耗时的过程，需要您执行多个命令。

这种复杂性可能会导致出现可能会影响整个集群的错误。建议您仔细考虑您的组织需求，并在开始之前仔
细规划流程的实施。
注意
不建议将 MCP 更新至不同的 OpenShift Container Platform 版本。例如，请勿将一个

MCP 从 4.y.10 更新至 4.y.11，另一个更新为 4.y.12。这个场景还没有被测试，可能会导致未
定义的集群状态。
重要
暂停机器配置池可防止 Machine Config Operator 在关联的节点上应用任何配置更改。暂

停 MCP 还可以防止任何自动轮转的证书被推送到关联的节点，包括自动轮转 kube-
apiserver-to-kubelet-signer CA 证书。如果 kube-apiserver-to-kubelet-signer CA 证书
过期且 MCO 尝试自动更新证书时，MCP 会暂停，但不会在相应机器配置池中的节点中应
用新证书。这会导致多个 oc 命令失败，包括但不限于 oc debug、oc logs、oc exec 和
oc attach。在暂停 MCP 时应该非常小心，需要仔细考虑 kube-apiserver-to-kubelet-
signer CA 证书过期的问题，且仅在短时间内暂停。
9.1. 关于 CANARY ROLLOUT 更新过程和 MCP

在 OpenShift Container Platform 中，节点不会被单独考虑。节点分组到机器配置池中 (MCP)。默认
OpenShift Container Platform 集群中有两个 MCP：一个用于 control plane 节点，一个用于 worker 节
点。OpenShift Container Platform 更新会同时影响所有 MCP。
在更新过程中，Machine Config Operator (MCO) 会排空并记录 MCP 中的所有节点，直至指定的

maxUnavailable 数量（如果指定），默认为 1。排空节点取消调度节点上的所有 pod，并将该节点标记
为不可调度。节点排空后，Machine Config Daemon 应用一个新的机器配置，其中包括更新操作系统
(OS)。更新操作系统需要主机重新引导。
36
要防止特定节点被更新，且不会排空、进行 cordoned 和更新，您可以创建自定义 MCP。然后，暂停这些

MCP，以确保不更新与这些 MCP 关联的节点。MCO 不会更新任何暂停的 MCP。您可以创建一个或多个
自定义 MCP，这样可以让您更好地控制您更新这些节点的顺序。更新第一个 MCP 中的节点后，您可以验
证应用兼容性，然后逐步将其余节点更新至新版本。
注意
为确保 control plane 的稳定性，不支持从 control plane 节点创建自定义 MCP。Machine

Config Operator (MCO) 会忽略为 control plane 节点创建的任何自定义 MCP。
根据工作负载部署拓扑，您应该仔细考虑您创建的 MCP 数以及每个 MCP 中的节点数量。例如，如果需

要将更新融入特定的维护窗口，您需要知道 OpenShift Container Platform 可在窗口中更新的节点数量。
这个数字取决于您具体的集群和工作负载特性。
另外，您需要考虑集群中可用的额外容量量。例如，当应用程序无法在更新的节点上按预期工作时，您可
以对池中那些节点进行 cordon 和 drain 操作，这会将应用 pod 移到其他节点上。您需要考虑您可用的额
外容量数量，以确定您需要的自定义 MCP 数量以及每个 MCP 中有多少节点。例如，如果您使用两个自
定义 MCP 和 50% 的节点在每个池中，则需要确定运行 50% 的节点是否能为您的应用程序提供足够的服
务质量(QoS)。
您可以将这个更新过程与所有记录的 OpenShift Container Platform 更新过程一起使用。但是，该过程不

适用于使用 Ansible playbook 进行更新的 Red Hat Enterprise Linux (RHEL) 机器。
9.2. 关于执行 CANARY ROLLOUT 更新

本主题描述了此 canary rollout 更新过程的一般工作流。以下小节介绍了工作流中执行每项任务的步骤。
1. 根据 worker 池创建 MCP。每个 MCP 中的节点数量取决于几个因素，如每个 MCP 的维护窗口持

续时间以及集群中可用的保留容量（即额外的 worker 节点）。
注意
您可以更改 MCP 中的 maxUnavailable 设置，以指定在任意给定时间可以更新的

机器的百分比或数量。默认值为 1。
2. 将节点选择器添加到自定义 MCP。对于您不想与剩余的集群同时更新的每个节点，请向节点添加
匹配的标签。该标签将节点与 MCP 相关联。
注意
不要从节点中删除默认 worker 标签。节点必须具有 role 标签才能在集群中正常工

作。
3. 在更新过程中暂停您不想更新的 MCP。
注意
暂停 MCP 还会暂停 kube-apiserver-to-kubelet-signer 自动 CA 证书轮转。在自

安装日期起的 292 天生成新 CA 证书，旧证书将从安装日期的 365 天后删除。请
参阅红帽 OpenShift 4 中的了解 CA 证书自动续订，以了解您在下一次自动 CA 证
书轮转前的时间。确保发生 CA 证书轮转时，池已被取消暂停。如果 MCP 暂停，
则不会发生证书轮转，这会导致集群降级，并导致多个 oc 命令失败，包括但不限
于 oc debug、oc logs、oc exec 和 oc attach。
37
4. 执行集群更新。更新过程更新没有暂停的 MCP，包括 control plane 节点。
5. 在更新的节点上测试应用，以确保它们按预期工作。
6. 逐一取消暂停剩余的 MCP，并在这些节点上测试应用程序，直到所有 worker 节点都已更新。取

消暂停 MCP 会启动与该 MCP 关联的节点的更新过程。您可以通过点击 Administration →
Cluster settings 从 web 控制台检查更新的进度。或者，使用 oc get machineconfigpools CLI
命令。
7. （可选）从更新的节点中删除自定义标签并删除自定义 MCP。
9.3. 创建机器配置池来执行 CANARY ROLLOUT 更新

执行此 canary rollout 更新的第一个任务是创建一个或多个机器配置池 (MCP)。
1. 从 worker 节点创建 MCP。
a. 列出集群中的 worker 节点。
$ oc get -l 'node-role.kubernetes.io/master!=' -o 'jsonpath={range .items[*]}

{.metadata.name}{"\n"}{end}' nodes
输出示例
ci-ln-pwnll6b-f76d1-s8t9n-worker-a-s75z4
ci-ln-pwnll6b-f76d1-s8t9n-worker-b-dglj2
ci-ln-pwnll6b-f76d1-s8t9n-worker-c-lldbm
b. 对于您要延迟的节点，在节点中添加自定义标签：
$ oc label node <node name> node-role.kubernetes.io/<custom-label>=
例如：
$ oc label node ci-ln-0qv1yp2-f76d1-kl2tq-worker-a-j2ssz node-

role.kubernetes.io/workerpool-canary=
输出示例
node/ci-ln-gtrwm8t-f76d1-spbl7-worker-a-xk76k labeled
c. 创建新的 MCP：
apiVersion: machineconfiguration.openshift.io/v1
kind: MachineConfigPool
metadata:
name: workerpool-canary 1
spec:
machineConfigSelector:
matchExpressions: 2
-{
key: machineconfiguration.openshift.io/role,
operator: In,
38
values: [worker,workerpool-canary]
}
nodeSelector:
matchLabels:
node-role.kubernetes.io/workerpool-canary: "" 3
1 为 MCP 指定名称。
2 指定 worker 和自定义 MCP 名称。
3 指定添加到此池中的自定义标签。
$ oc create -f <file_name>
输出示例
machineconfigpool.machineconfiguration.openshift.io/workerpool-canary created
d. 查看集群中的 MCP 列表及其当前状态：
$ oc get machineconfigpool
输出示例

DEGRADED MACHINECOUNT READYMACHINECOUNT
UPDATEDMACHINECOUNT DEGRADEDMACHINECOUNT AGE
master rendered-master-b0bb90c4921860f2a5d8a2f8137c1867 True
False False 3 3 3 0 97m
workerpool-canary rendered-workerpool-canary-87ba3dec1ad78cb6aecebf7fbb476a36
True False False 1 1 1 0 2m42s
worker rendered-worker-87ba3dec1ad78cb6aecebf7fbb476a36 True
创建新的机器配置池 workerpool-canary，机器计数中会显示您添加自定义标签的节点数
量。worker MCP 机器数会减少相同的数字。更新机器数可能需要几分钟时间。在本例中，一
个节点已从 worker MCP 移到 worker pool-canary MCP。
9.4. 暂停机器配置池
在这个 Canary rollout 更新过程中，在使用 OpenShift Container Platform 集群的其余集群标记了节点并
创建机器配置池 (MCP) 后，您会暂停这些 MCP。暂停 MCP 可防止 Machine Config Operator (MCO) 更
新与该 MCP 关联的节点。
注意
暂停 MCP 还会暂停 kube-apiserver-to-kubelet-signer 自动 CA 证书轮转。在自安装日期

起的 292 天生成新 CA 证书，旧证书将从安装日期的 365 天后删除。请参阅红帽
OpenShift 4 中的了解 CA 证书自动续订，以了解您在下一次自动 CA 证书轮转前的时间。
确保发生 CA 证书轮转时，池已被取消暂停。如果 MCP 暂停，则不会发生证书轮转，这会
导致集群降级，并导致多个 oc 命令失败，包括但不限于 oc debug、oc logs、oc exec
和 oc attach。
39
暂停 MCP：
1. 对您要暂停的 MCP 进行补丁：
$ oc patch mcp/<mcp_name> --patch '{"spec":{"paused":true}}' --type=merge
例如：
$ oc patch mcp/workerpool-canary --patch '{"spec":{"paused":true}}' --type=merge
输出示例
machineconfigpool.machineconfiguration.openshift.io/workerpool-canary patched
9.5. 执行集群更新
当 MCP 进入 ready 状态时，您可以执行集群更新。根据您的集群，请查看以下更新方法之一：
使用 Web 控制台更新集群
更新完成后，您可以开始逐一取消暂停 MCP。
9.6. 取消暂停机器配置池
在这个 Canary rollout 更新过程中，OpenShift Container Platform 更新完成后，取消逐一暂停自定义
MCP。取消暂停 MCP 允许 Machine Config Operator (MCO) 更新与该 MCP 关联的节点。
取消暂停 MCP：
1. 对您要取消暂停的 MCP 进行补丁：
$ oc patch mcp/<mcp_name> --patch '{"spec":{"paused":false}}' --type=merge
例如：
$ oc patch mcp/workerpool-canary --patch '{"spec":{"paused":false}}' --type=merge
输出示例
machineconfigpool.machineconfiguration.openshift.io/workerpool-canary patched
您可以使用 oc get machineconfigpools 命令检查更新的进度。
2. 在更新的节点上测试您的应用，以确保它们按预期工作。
3. 逐一取消暂停任何其他暂停的 MCP，并验证您的应用程序是否正常工作。
9.6.1. 如果应用程序失败
如果应用程序出现故障，如应用程序未在更新的节点上工作，您可以对池中的节点进行 cordon 和 drain
40
如果应用程序出现故障，如应用程序未在更新的节点上工作，您可以对池中的节点进行 cordon 和 drain

操作，这会将应用 pod 移到其他节点，以帮助维护应用程序的服务质量。第一个 MCP 不应大于过量容
量。
9.7. 将节点移到原始机器配置池中
在这个 Canary rollout 更新过程中，在取消暂停自定义机器配置池 (MCP) 并验证与该 MCP 关联的节点上
的应用程序是否按预期工作后，您应该删除添加到节点的自定义标签，将节点移回原始 MCP。
重要
节点必须具有角色才能在集群中正常工作。
将节点移动到其原始 MCP 中：
1. 从节点移除自定义标签。
$ oc label node <node_name> node-role.kubernetes.io/<custom-label>-
例如：
$ oc label node ci-ln-0qv1yp2-f76d1-kl2tq-worker-a-j2ssz node-

role.kubernetes.io/workerpool-canary-
输出示例
node/ci-ln-0qv1yp2-f76d1-kl2tq-worker-a-j2ssz labeled
MCO 将节点移回到原始 MCP，并将节点与 MCP 配置协调。
2. 查看集群中的 MCP 列表及其当前状态：
$oc get mcp

DEGRADED MACHINECOUNT READYMACHINECOUNT UPDATEDMACHINECOUNT
DEGRADEDMACHINECOUNT AGE
master rendered-master-1203f157d053fd987c7cbd91e3fbc0ed True False
False 3 3 3 0 61m
workerpool-canary rendered-mcp-noupdate-5ad4791166c468f3a35cd16e734c9028 True
worker rendered-worker-5ad4791166c468f3a35cd16e734c9028 True False
False 3 3 3 0 61m
该节点从自定义 MCP 中删除，并移回原始 MCP。更新机器数可能需要几分钟时间。在这个示例

中，将一个节点从删除的 workerpool-canary MCP 移到 'worker'MCP。
3. 可选：删除自定义 MCP：
$ oc delete mcp <mcp_name>
41
第 10 章更新包含使用 RHEL 的计算（COMPUTE）系统的集群

您可以更新或升级OpenShift Container Platform集群。如果您的集群包含Red Hat Enterprise
Linux（RHEL）系统，则必须执行额外的步骤来更新这些系统。
10.1. 先决条件

装替换。

态。如需更多信息，请参阅为 AWS、Azure 或 GCP 手动维护凭证升级集群。

STS 为手动模式升级 OpenShift Container Platform 集群。

其他资源
10.2. 使用WEB控制台更新集群
如果有可用更新，您可以从Web控制台更新集群。
先决条件
流程
1. 在 web 控制台中点击 Administration → Cluster Settings 并查看 Details 选项卡中的内容。
2. 对于生产环境中的集群，请确保将 Channel 设置为您要升级到的版本的正确频道，如 stable-

4.10。
重要
对于生产环境中的集群，您必须订阅一个 stable-*, eus-* 或 fast-* 频道。
注意
42
注意
如果 Update 状态不是 Updates available，则无法升级集群。
Select channel 表示集群正在运行或正在更新的集群版本。
3. 选择要更新到的版本，然后单击 Save。
输入频道 Update Status 变为Update to <product-version> in progress，您可以通过监视
Operator 和节点的进度条来查看集群更新的进度。
注意
如果您要将集群升级到下一个次版本，如从 4.y 升级到 4.(y+1)，建议在部署依赖新

功能的工作负载前确认您的节点已升级：任何尚未更新的 worker 节点池都会显示
在 Cluster Settings 页面。
4. 更新完成后，Cluster Version Operator 会刷新可用更新，检查当前频道中是否有更多可用更新。
如果有可用更新，请继续在当前频道中执行更新，直到您无法再更新为止。

更新至您在该频道中想要的版本。
您可能需要执行一些过渡的更新，直到您到达您想要的版本。
注意
当您更新包含有 Red Hat Enterprise Linux (RHEL) worker 机器的集群时，这些

worker 会在更新过程中暂时不可用。当集群进入 NotReady 状态时，您需要针对
每个 RHEL 机器运行升级 playbook 以完成更新。
10.3. 可选：添加 HOOK 以在RHEL系统上执行ANSIBLE任务

在OpenShift Container Platform更新期间，您可以使用hook在RHEL计算系统上运行Ansible任务。
10.3.1. 在升级过程中使用 Ansible hook

更新OpenShift Container Platform时，可以使用hook在执行特定操作时在Red Hat Enterprise
Linux（RHEL）节点上运行自定义的任务。您可以使用 hook 提供定义了在执行特定任务之前或之后要运
行的任务的文件。在OpenShift Container Platform集群中更新RHEL计算节点时，可以使用 hook 来验证
或修改自定义的基础架构。
因为当 hook 失败时，这个操作将会失败，所以您必须把 hook 设计为可以多次运行，并且获得相同的结

果。
hook 有以下限制： - hook 没有已定义或版本化的界面。它们可以使用内部的openshift-ansible变量，但
43
hook 有以下限制： - hook 没有已定义或版本化的界面。它们可以使用内部的openshift-ansible变量，但

这些变量可能会在将来的OpenShift Container Platform版本被修改或删除。 - hook 本身没有错误处理机
制，因此 hook 中的错误会暂停更新过程。如果出现错误，则需要解决相关的问题，然后再次进行升级。
10.3.2. 配置Ansible inventory文件以使用 hook

您可以在 hosts inventory 文件的all:vars 部分中定义 Red Hat Enterprise Linux（RHEL）compute 机器
（也称为 worker 机器）更新时使用的 hook 。
先决条件
您可以访问用于添加RHEL compute 系统集群的计算机。您必须有访问定义RHEL系统的hosts

Ansible 清单文件的权限。
流程
1. 在设计了 hook 后，创建一个YAML文件，为其定义Ansible任务。此文件必须是一组任务，不能

是一个 playbook，如以下示例所示：
---
# Trivial example forcing an operator to acknowledge the start of an upgrade
# file=/home/user/openshift-ansible/hooks/pre_compute.yml
- name: note the start of a compute machine update

debug:
msg: "Compute machine upgrade of {{ inventory_hostname }} is about to start"
- name: require the user agree to start an upgrade

pause:
prompt: "Press Enter to start the compute machine update"
2. 修改 hosts Ansible inventory 文件来指定 hook 文件。hook 文件作为参数值在 [all:vars] 部分指

定。如下所示：
清单文件中的 hook 定义示例
[all:vars]
openshift_node_pre_upgrade_hook=/home/user/openshift-ansible/hooks/pre_node.yml
openshift_node_post_upgrade_hook=/home/user/openshift-ansible/hooks/post_node.yml
为了避免歧义，请在其定义中使用 hook 文件的绝对路径而不要使用相对路径。
10.3.3. RHEL计算系统可用的 hook

在更新OpenShift Container Platform集群中的Red Hat Enterprise Linux（RHEL）compute 系统时，可
以使用以下 hook。
Hook 名描述
44
Hook 名描述
openshift_node_pre_cordon_hook
在每个节点被封锁（cordon）之前运行。
此 hook 以串行方式针对每个节点运行。
如果某个任务必须针对其他主机运行，则该
任务必须使用delegate_to或local_action
。
openshift_node_pre_upgrade_hook
在每个节点被封锁后，且被更新前运行。
。
openshift_node_pre_uncordon_hook
在每个节点被更新后，且被取消封锁
（uncordon）前运行。
。
openshift_node_post_upgrade_hook
每个节点未被取消封锁后运行。这是最后一
个节点更新操作。
。
10.4. 更新集群中的RHEL COMPUTE 系统

在对集群进行更新后，必须更新集群中的Red Hat Enterprise Linux（RHEL）compute 系统。
重要
RHEL 计算机器支持 Red Hat Enterprise Linux (RHEL) 版本 8.5 和 8.6。
如果您使用 RHEL 作为操作系统，您还可以将计算机器更新至 OpenShift Container Platform 的另一个次

要版本。当执行次版本更新时，您不需要排除 RHEL 中的任何 RPM 软件包。
重要
45
重要
您无法将 RHEL 7 计算机器升级到 RHEL 8。您必须部署新的 RHEL 8 主机，并且应该删除

旧的 RHEL 7 主机。
先决条件
已更新了集群。
重要
因为 RHEL 机器需要集群生成的资产才能完成更新过程，所以您必须在更新其中的
RHEL worker 机器前更新集群。
您可以访问用于将 RHEL 计算机器添加到集群的本地机器。您必须有权访问定义了 RHEL 系统及

upgrade playbook 的 hosts Ansible 清单文件。
对于次版本的更新，RPM 存储库使用的是集群上运行的相同版本的 OpenShift Container

Platform。
流程
1. 停止并禁用主机上的防火墙：
# systemctl disable --now firewalld.service
注意
默认情况下，使用 "Minimal" 安装选项的基础操作系统 RHEL 启用 firewalld 保护。

在主机上启用了 firewalld 服务会阻止您访问 worker 上的 OpenShift Container
Platform 日志。如果您希望继续访问 worker 上的 OpenShift Container Platform
日志，以后不要启用 firewalld。
2. 启用 OpenShift Container Platform 4.10 所需的存储库：
a. 在运行 Ansible playbook 的机器上，更新所需的存储库：
# subscription-manager repos --disable=rhel-7-server-ose-4.9-rpms \

--enable=rhel-7-server-ose-4.10-rpms
重要
从 OpenShift Container Platform 4.10.23 开始，在 RHEL 7 上运行 Ansible

playbook 已被弃用，建议仅针对更新现有安装的目的。完成此步骤后，您必
须将 Ansible 主机升级到 RHEL 8，或在 RHEL 8 系统中创建新的 Ansible 主
机，并通过旧 Ansible 主机复制清单。从 OpenShift Container Platform 4.11
开始，只有 RHEL 8 提供了 Ansible playbook。
b. 在运行 Ansible playbook 的机器上，更新所需的软件包，包括 openshift-ansible：
# yum update openshift-ansible openshift-clients
46
c. 在每个 RHEL 计算节点上，更新所需的软件仓库：
# subscription-manager repos --disable=rhocp-4.9-for-rhel-8-x86_64-rpms \

--enable=rhocp-4.10-for-rhel-8-x86_64-rpms
3. 更新 RHEL worker 机器：
a. 检查 /<path>/inventory/hosts 中的 Ansible 清单文件并更新其内容，以便 RHEL 8 机器列在

[workers] 部分中，如下例所示：
[all:vars]
ansible_user=root
#ansible_become=True
openshift_kubeconfig_path="~/.kube/config"
[workers]
mycluster-rhel8-0.example.com
b. 进入 openshift-ansible 目录：
$ cd /usr/share/ansible/openshift-ansible
c. 运行 upgrade playbook:
$ ansible-playbook -i /<path>/inventory/hosts playbooks/upgrade.yml 1
1 对于<path> ，指定您创建的Ansible库存文件的路径。
注意
upgrade playbook 仅升级 OpenShift Container Platform 软件包。它不会更

新操作系统软件包。
4. 更新完所有 worker 后，确认所有集群节点已更新至新版本：
# oc get node
输出示例

mycluster-control-plane-0 Ready master 145m v1.23.0
mycluster-rhel8-0 Ready worker 98m v1.23.0
47
5. 可选：更新 upgrade playbook 没有更新的操作系统软件包。要更新不是 4.10 的软件包，请使用

以下命令：
# yum update
注意
如果您使用安装 4.10 时使用的同一 RPM 存储库，则不需要排除 RPM 软件包。
48
第 11 章在断开连接的环境中更新集群
11.1. 关于在断开连接的环境中的集群更新
断开连接的环境是集群节点无法访问互联网的环境。因此，您必须在 registry 中填充安装镜像。如果您的
registry 主机无法同时访问互联网和集群，您可以将镜像镜像到与这个环境断开连接的文件系统中，然后
使用主机或可移动介质填补该空白。如果本地容器 registry 和集群连接到镜像 registry 的主机，您可以直
接将发行镜像推送到本地 registry。
一个独立的容器镜像 registry 足以为断开连接的网络中的多个集群托管 mirror 的镜像。
11.1.1. 镜像 OpenShift Container Platform 镜像存储库

要在断开连接的环境中更新集群，您的集群环境必须有权访问具有目标更新所需镜像和资源的镜像
registry。以下页提供了将镜像镜像到断开连接的集群中的存储库的说明：
镜像 OpenShift Container Platform 镜像存储库
11.1.2. 在断开连接的环境中执行集群更新
您可以使用以下步骤之一更新断开连接的 OpenShift Container Platform 集群：
使用 OpenShift Update Service 在断开连接的环境中更新集群
在没有 OpenShift Update Service 的断开连接的环境中更新集群
11.1.3. 从集群中删除 OpenShift Update Service

您可以使用以下步骤从集群中卸载 OpenShift Update Service (OSUS) 的本地副本：
从集群中删除 OpenShift Update Service
11.2. 镜像 OPENSHIFT CONTAINER PLATFORM 镜像存储库

您必须将容器镜像镜像到镜像 registry 中，然后才能在受限网络环境中更新集群。您还可以在连接的环境
中使用此流程来确保集群只运行满足您机构对外部内容控制的批准的容器镜像。
11.2.1. 先决条件
您必须在托管 OpenShift Container Platform 集群的位置（如 Red Hat Quay）中有一个支持
Docker v2-2 的容器镜像 registry。
11.2.2. 准备您的镜像主机
执行镜像步骤前，必须准备主机以检索内容并将其推送到远程位置。
11.2.2.1. 通过下载二进制文件安装 OpenShift CLI
您可以安装 OpenShift CLI(oc)来使用命令行界面与 OpenShift Container Platform 进行交互。您可以在

Linux、Windows 或 macOS 上安装 oc。
重要
49
重要
如果安装了旧版本的 oc，则无法使用 OpenShift Container Platform 4.10 中的所有命令。

下载并安装新版本的 oc。如果要在断开连接的环境中升级集群，请安装您要升级到的 oc
版本。
在 Linux 上安装 OpenShift CLI

您可以按照以下流程在 Linux 上安装 OpenShift CLI(oc)二进制文件。
流程
1. 导航到红帽客户门户网站上的 OpenShift Container Platform 下载页面。
2. 在 Version 下拉菜单中选择相应的版本。
3. 点 OpenShift v4.10 Linux Client 条目旁的 Download Now 来保存文件。
4. 解包存档：
$ tar xvf <file>
5. 将 oc 二进制文件放到 PATH 中的目录中。

要查看您的 PATH，请执行以下命令：
$ echo $PATH
安装 OpenShift CLI 后，可以使用 oc 命令：
$ oc <command>
在 Windows 上安装 OpenShift CLI

您可以按照以下流程在 Windows 上安装 OpenShift CLI(oc)二进制文件。
流程
3. 点 OpenShift v4.10 Windows Client 条目旁的 Download Now 来保存文件。
4. 使用 ZIP 程序解压存档。
5. 将 oc 二进制文件移到 PATH 中的目录中。

要查看您的 PATH，请打开命令提示并执行以下命令：
C:\> path
C:\> oc <command>
在 macOS 上安装 OpenShift CLI
50
您可以按照以下流程在 macOS 上安装 OpenShift CLI(oc)二进制文件。
流程
3. 点 OpenShift v4.10 MacOSX Client 条目旁的 Download Now 来保存文件。
4. 解包和解压存档。
5. 将 oc 二进制文件移到 PATH 的目录中。

要查看您的 PATH，请打开终端并执行以下命令：
$ echo $PATH
$ oc <command>
11.2.2.2. 配置允许对容器镜像进行镜像的凭证
创建容器镜像 registry 凭证文件，允许将红帽的镜像镜像到您的镜像环境中。

警告
安装集群时不要使用此镜像 registry 凭据文件作为 pull secret。如果在安装集群时提

供此文件，集群中的所有机器都将具有镜像 registry 的写入权限。

警告
此过程需要您可以对镜像 registry 上的容器镜像 registry 进行写操作，并将凭证添加

到 registry pull secret。
先决条件
您已将镜像 registry 配置为在断开连接的环境中使用。
您在镜像 registry 中标识了镜像仓库的位置，以将容器镜像镜像(mirror)到这个位置。
您置备了一个镜像 registry 帐户，允许将镜像上传到该镜像仓库。
流程
51
在安装主机上完成以下步骤：
1. 下载您的 registry.redhat.io pull secret（从Red Hat OpenShift Cluster Manager）。
2. 以 JSON 格式创建您的 pull secret 副本：
$ cat ./pull-secret | jq . > <path>/<pull_secret_file_in_json> 1
1 指定到存储 pull secret 的文件夹的路径，以及您创建的 JSON 文件的名称。
该文件类似于以下示例：
{
"auths": {
"cloud.openshift.com": {
"auth": "b3BlbnNo...",
"email": "[email protected]"
},
"quay.io": {
},
"registry.connect.redhat.com": {
"auth": "NTE3Njg5Nj...",
},
"registry.redhat.io": {
}
}
}
3. 为您的镜像 registry 生成 base64 编码的用户名和密码或令牌：
$ echo -n '<user_name>:<password>' | base64 -w0 1

BGVtbYk3ZHAtqXs=
1 通过 <user_name> 和 <password> 指定 registry 的用户名和密码。
4. 编辑 JSON 文件并添加描述 registry 的部分：
"auths": {
"<mirror_registry>": { 1
"auth": "<credentials>", 2
}
},
1 对于 <mirror_registry>，指定 registry 域名，以及您的镜像 registry 用来提供内容的可选

端口。例如：registry.example.com 或 registry.example.com:8443
2 使用 <credentials> 为您的镜像 registry 指定 base64 编码的用户名和密码。
52
该文件类似于以下示例：
{
"auths": {
"registry.example.com": {
"auth": "BGVtbYk3ZHAtqXs=",
},
"cloud.openshift.com": {
},
"quay.io": {
},
"registry.connect.redhat.com": {
},
"registry.redhat.io": {
}
}
}
11.2.3. 镜像 OpenShift Container Platform 镜像存储库
重要
为了避免 OpenShift Update Service 应用程序过量内存用量，您必须将发行镜像镜像到单

独的存储库，如以下步骤所述。
先决条件
您已将镜像 registry 配置为在受限网络中使用，并可访问您配置的证书和凭证。
您已从 Red Hat OpenShift Cluster Manager 下载了 pull secret ，并已修改为包含镜像存储库身份
验证信息。
如果您使用自签名证书，已在证书中指定 Subject Alternative Name。
流程
1. 使用 Red Hat OpenShift Container Platform Upgrade Graph visualizer 和 update planner 计划从
一个版本升级到另一个版本。OpenShift Upgrade Graph 提供频道图形，并演示了如何确认您的
当前和预定集群版本之间有更新路径。
2. 设置所需的环境变量：
a. 导出发行版本信息：
$ export OCP_RELEASE=<release_version>
对于 <release_version>，请指定与升级到的 OpenShift Container Platform 版本对应的标

53
对于 <release_version>，请指定与升级到的 OpenShift Container Platform 版本对应的标

签，如 4.5.4。
b. 导出本地 registry 名称和主机端口：
$ LOCAL_REGISTRY='<local_registry_host_name>:<local_registry_host_port>'
对于 <local_registry_host_name>，请指定镜像存储库的 registry 域名；对于

<local_registry_host_port>，请指定用于提供内容的端口。
c. 导出本地存储库名称：
$ LOCAL_REPOSITORY='<local_repository_name>'
对于 <local_repository_name>，请指定要在 registry 中创建的仓库名称，如

ocp4/openshift4。
d. 如果使用 OpenShift Update Service，请导出一个额外的本地存储库名称，使其包含发行镜

像：
$
LOCAL_RELEASE_IMAGES_REPOSITORY='<local_release_images_repository_name>'
对于 <local_release_images_repository_name>，请指定要在 registry 中创建的仓库名

称，如 ocp4/openshift4-release-images。
e. 导出要进行镜像的存储库名称：
$ PRODUCT_REPO='openshift-release-dev'
对于生产环境版本，必须指定 openshift-release-dev。
f. 导出 registry pull secret 的路径：
$ LOCAL_SECRET_JSON='<path_to_pull_secret>'
对于 <path_to_pull_secret>，请指定您创建的镜像 registry 的 pull secret 的绝对路径和文

件名。
注意
如果您的集群使用 ImageContentSourcePolicy 对象来配置存储库镜像，则

只能将全局 pull secret 用于镜像 registry。您不能在项目中添加 pull secret。
g. 导出发行版本镜像：
$ RELEASE_NAME="ocp-release"
对于生产环境版本，您必须指定 ocp-release。
h. 为您的服务器导出构架类型，如 x86_64。
$ ARCHITECTURE=<server_architecture>
54
i. 导出托管镜像的目录的路径：
$ REMOVABLE_MEDIA_PATH=<path> 1
1 指定完整路径，包括开始的前斜杠(/)字符。
3. 查看要镜像的镜像和配置清单：
$ oc adm release mirror -a ${LOCAL_SECRET_JSON} --to-

dir=${REMOVABLE_MEDIA_PATH}/mirror
quay.io/${PRODUCT_REPO}/${RELEASE_NAME}:${OCP_RELEASE}-${ARCHITECTURE}
--dry-run
4. 将版本镜像镜像(mirror)到镜像 registry。
如果您的镜像主机无法访问互联网，请执行以下操作：
i. 将可移动介质连接到连接到互联网的系统。
ii. 将镜像和配置清单镜像到可移动介质的目录中：
$ oc adm release mirror -a ${LOCAL_SECRET_JSON} --to-

quay.io/${PRODUCT_REPO}/${RELEASE_NAME}:${OCP_RELEASE}-
${ARCHITECTURE}
iii. 将介质上传到受限网络环境中，并将镜像上传到本地容器 registry。
$ oc image mirror -a ${LOCAL_SECRET_JSON} --from-

"file://openshift/release:${OCP_RELEASE}*"
${LOCAL_REGISTRY}/${LOCAL_REPOSITORY} 1
1 对于 REMOVABLE_MEDIA_PATH，您必须使用与镜像镜像时指定的同一路径。
iv. 使用 oc 命令行界面(CLI)登录到您要升级的集群。
v. 将镜像发行镜像签名配置映射应用到连接的集群：
$ oc apply -f ${REMOVABLE_MEDIA_PATH}/mirror/config/<image_signature_file>
1
1 对于 <image_signature_file>，指定文件的路径和名称，例如 signature-sha256-
81154f5c03294534.yaml。
vi. 如果使用 OpenShift Update Service，请将发行镜像镜像到单独的存储库：
$ oc image mirror -a ${LOCAL_SECRET_JSON}

${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}-
${ARCHITECTURE}
${LOCAL_REGISTRY}/${LOCAL_RELEASE_IMAGES_REPOSITORY}:${OCP_REL
EASE}-${ARCHITECTURE}
55
如果本地容器 registry 和集群连接到镜像主机，请执行以下操作：
i. 将发行镜像直接推送到本地 registry，并使用以下命令将配置映射应用到集群：
$ oc adm release mirror -a ${LOCAL_SECRET_JSON} --

from=quay.io/${PRODUCT_REPO}/${RELEASE_NAME}:${OCP_RELEASE}-
${ARCHITECTURE} \
--to=${LOCAL_REGISTRY}/${LOCAL_REPOSITORY} --apply-release-image-
signature
注意
如果包含 --apply-release-image-signature 选项，不要为镜像签名验证

创建配置映射。
ii. 如果使用 OpenShift Update Service，请将发行镜像镜像到单独的存储库：
$ oc image mirror -a ${LOCAL_SECRET_JSON}

${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}:${OCP_RELEASE}-
${ARCHITECTURE}
${LOCAL_REGISTRY}/${LOCAL_RELEASE_IMAGES_REPOSITORY}:${OCP_REL
EASE}-${ARCHITECTURE}
11.3. 使用 OPENSHIFT UPDATE SERVICE 在断开连接的环境中更新集群

要获得与连接的集群类似的更新体验，您可以使用以下步骤在断开连接的环境中安装和配置 OpenShift
Update Service。
11.3.1. 在断开连接的环境中使用 OpenShift Update Service

OpenShift Update Service (OSUS) 为 OpenShift Container Platform 集群提供更新建议。红帽公开托管
OpenShift Update Service，连接的环境中的集群可以通过公共 API 连接到该服务，以检索更新建议。
但是，在断开连接的环境中的集群无法访问这些公共 API 来检索更新信息。要在断开连接的环境中提供类

似的更新体验，您可以在本地安装和配置 OpenShift Update Service，使其在断开连接的环境中可用。
以下小节介绍了如何安装本地 OSUS 实例，并将其配置为为集群提供更新建议。
其他资源
关于 OpenShift Update 服务
11.3.2. 先决条件
您必须安装了 oc 命令行界面（CLI）工具。
您必须使用容器镜像置备本地容器镜像 registry，如镜像 OpenShift Container Platform 镜像存储

库中所述。
11.3.3. 为 OpenShift Update Service 配置对安全 registry 的访问
如果发行镜像包含在由自定义证书颁发机构签名的 HTTPS X.509 证书的 registry 中，请完成为镜像

56
如果发行镜像包含在由自定义证书颁发机构签名的 HTTPS X.509 证书的 registry 中，请完成为镜像

registry 访问配置额外信任存储的步骤，以及对更新服务进行以下更改。
OpenShift Update Service Operator 需要 registry CA 证书中的配置映射键名称为 updateservice-

registry。
更新服务的镜像 registry CA 配置映射示例
apiVersion: v1
kind: ConfigMap
metadata:
name: my-registry-ca
data:
updateservice-registry: | 1
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
registry-with-port.example.com..5000: | 2
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
1 OpenShift Update Service Operator 需要 registry CA 证书中的配置映射键名称 updateservice-

registry。
2 如果 registry 带有端口，如 registry-with-port.example.com:5000，: 需要被 .. 替换。
11.3.4. 更新全局集群 pull secret

您可以通过替换当前的 pull secret 或附加新的 pull secret 来更新集群的全局 pull secret。
当用户使用单独的 registry 存储镜像而不使用安装过程中的 registry时，需要这个过程。
先决条件
您可以使用具有 cluster-admin 角色的用户访问集群。
流程
1. 可选：要将新的 pull secret 附加到现有 pull secret 中，请完成以下步骤：
a. 输入以下命令下载 pull secret：
$ oc get secret/pull-secret -n openshift-config --template='{{index .data

".dockerconfigjson" | base64decode}}' ><pull_secret_location> 1
1 提供 pull secret 文件的路径。
b. 输入以下命令来添加新 pull secret：
57
$ oc registry login --registry="<registry>" \ 1

--auth-basic="<username>:<password>" \ 2
--to=<pull_secret_location> 3
1 提供新的 registry。您可以在同一个 registry 中包含多个软件仓库，例如：--registry="

<registry/my-namespace/my-repository>"。
2 提供新 registry 的凭据。
3 提供 pull secret 文件的路径。
另外，您可以对 pull secret 文件执行手动更新。
2. 输入以下命令为您的集群更新全局 pull secret：
$ oc set data secret/pull-secret -n openshift-config --from-file=.dockerconfigjson=

<pull_secret_location> 1
1 提供新 pull secret 文件的路径。
该更新将推广至所有节点，可能需要一些时间，具体取决于集群大小。
注意
从 OpenShift Container Platform 4.7.4 开始，对全局 pull secret 的更改不再触发

节点排空或重启。
11.3.5. 安装 OpenShift Update Service Operator

要安装 OpenShift Update Service，您必须首先使用 OpenShift Container Platform Web 控制台或 CLI
安装 OpenShift Update Service Operator。
注意
对于在断开连接的环境中安装的集群（也称为断开连接的集群），Operator Lifecycle
Manager 默认无法访问托管在远程 registry 上的红帽提供的 OperatorHub 源，因为这些远
程源需要有互联网连接。如需更多信息，请参阅在受限网络中使用 Operator Lifecycle
Manager。
11.3.5.1. 使用 Web 控制台安装 OpenShift Update Service Operator
您可以使用 Web 控制台安装 OpenShift Update Service Operator。
流程
1. 在 Web 控制台中，点 Operators → OperatorHub。
注意
在 Filter by keyword… 字段中输入 Update Service，以更快地查找 Operator。
58
2. 从可用的 Operator 列表中选择 OpenShift Update Service，然后点 Install。
a. 频道 v1 被选为 Update Channel，因为它是这个版本中唯一可用的频道。
b. 在 Installation Mode 下选择 A specific namespace on the cluster。
c. 为 Installed Namespace 选择一个命名空间，或接受推荐的命名空间 openshift-update-

service。
d. 选择一个批准策略：
Automatic 策略允许 Operator Lifecycle Manager（OLM）在有新版本可用时自动更新

Operator。
Manual 策略要求集群管理员批准 Operator 更新。
e. 点 Install。
3. 通过切换到 Operators → Installed Operators 页来验证 OpenShift Update Service Operator 是

否已安装。
4. 确保 OpenShift Update Service 列在所选命名空间中，Status 为 Succeeded。
11.3.5.2. 使用 CLI 安装 OpenShift Update Service Operator
您可以使用 OpenShift CLI（oc）安装 OpenShift Update Service Operator。
流程
1. 为 OpenShift Update Service Operator 创建命名空间：
a. 为 OpenShift Update Service Operator 创建一个 Namespace 对象 YAML 文件，如

update-service-namespace.yaml：
apiVersion: v1
kind: Namespace
metadata:
name: openshift-update-service
annotations:
openshift.io/node-selector: ""
labels:
openshift.io/cluster-monitoring: "true" 1
1 将 openshift.io/cluster-monitoring 标签设置为在该命名空间中启用 Operator-

recommended 集群监控。
b. 创建命名空间：
$ oc create -f <filename>.yaml
例如：
$ oc create -f update-service-namespace.yaml
2. 通过创建以下对象来安装 OpenShift Update Service Operator：

a. 创建一个 OperatorGroup 对象 YAML 文件，如 update-service-operator-group.yaml：
59
a. 创建一个 OperatorGroup 对象 YAML 文件，如 update-service-operator-group.yaml：
apiVersion: operators.coreos.com/v1
kind: OperatorGroup
metadata:
name: update-service-operator-group
spec:
targetNamespaces:
- openshift-update-service
b. 创建一个 OperatorGroup 对象：
$ oc -n openshift-update-service create -f <filename>.yaml
例如：
$ oc -n openshift-update-service create -f update-service-operator-group.yaml
c. 创建一个 Subscription 对象 YAML 文件，如 update-service-subscription.yaml：
订阅示例
apiVersion: operators.coreos.com/v1alpha1
kind: Subscription
metadata:
name: update-service-subscription
spec:
channel: v1
installPlanApproval: "Automatic"
source: "redhat-operators" 1
sourceNamespace: "openshift-marketplace"
name: "cincinnati-operator"
1 指定提供 Operator 的目录源的名称。对于不使用自定义 Operator Lifecycle

Manager（OLM）的集群，指定 redhat-operators。如果 OpenShift Container
Platform 集群安装在断开连接的环境中，请指定配置 Operator Lifecycle Manager
(OLM) 时创建的 CatalogSource 对象的名称。
d. 创建 Subscription 对象：
$ oc create -f <filename>.yaml
例如：
$ oc -n openshift-update-service create -f update-service-subscription.yaml
OpenShift Update Service Operator 被安装到 openshift-update-service 命名空间，并以

openshift-update-service 命名空间为目标。
3. 验证 Operator 安装：
$ oc -n openshift-update-service get clusterserviceversions
60
输出示例
NAME DISPLAY VERSION REPLACES PHASE

update-service-operator.v4.6.0 OpenShift Update Service 4.6.0 Succeeded
...
如果列出了 OpenShift Update Service Operator，则会成功安装。版本号可能与所示不同。
其他资源
在命名空间中安装 Operator。
11.3.6. 创建 OpenShift Update Service 图形数据容器镜像

OpenShift Update Service 需要图形数据容器镜像，OpenShift Update Service 从中检索有关频道成员资
格和阻止更新边缘的信息。图形数据通常直接从升级图形数据仓库中获取。在互联网连接不可用的环境
中，从 init 容器加载此信息是使图形数据可供 OpenShift Update Service 使用的另一种方式。init 容器的
角色是提供图形数据的本地副本，在 pod 初始化期间，init 容器会将数据复制到该服务可访问的卷中。
流程
1. 创建一个 Dockerfile，如 ./Dockerfile，包含以下内容：
FROM registry.access.redhat.com/ubi8/ubi:8.1
RUN curl -L -o cincinnati-graph-data.tar.gz

https://api.openshift.com/api/upgrades_info/graph-data
RUN mkdir -p /var/lib/cincinnati-graph-data && tar xvzf cincinnati-graph-data.tar.gz -C

/var/lib/cincinnati-graph-data/ --no-overwrite-dir --no-same-owner
CMD ["/bin/bash", "-c" ,"exec cp -rp /var/lib/cincinnati-graph-data/* /var/lib/cincinnati/graph-

data"]
2. 使用上一步中创建的 docker 文件来构建图形数据容器镜像，如

registry.example.com/openshift/graph-data:latest：
$ podman build -f ./Dockerfile -t registry.example.com/openshift/graph-data:latest
3. 将上一步中创建的 graph-data 容器镜像推送到 OpenShift Update Service 可以访问的存储库，

如 registry.example.com/openshift/graph-data:latest：
$ podman push registry.example.com/openshift/graph-data:latest
注意
要将图形数据镜像推送到受限网络中的本地 registry，请将上一步中创建的 graph-

data 容器镜像复制到可供 OpenShift Update Service 访问的存储库。运行 oc
image mirror --help 查看可用选项。
11.3.7. 创建 OpenShift Update Service 应用程序
您可以使用 OpenShift Container Platform Web 控制台或 CLI 创建 OpenShift Update Service 应用程
61
您可以使用 OpenShift Container Platform Web 控制台或 CLI 创建 OpenShift Update Service 应用程
序。
11.3.7.1. 使用 Web 控制台创建 OpenShift Update Service 应用程序
您可以使用 OpenShift Container Platform Web 控制台使用 OpenShift Update Service Operator 创建
OpenShift Update Service 应用程序。
先决条件
已安装 OpenShift Update Service Operator。
OpenShift Update Service graph-data 容器镜像已创建并推送到 OpenShift Update Service 访问

的存储库。
当前发行版本和更新目标版本已被 mirror 到本地可访问的 registry 中。
流程
1. 在 Web 控制台中，点 Operators → Installed Operators。
2. 从安装的 Operator 列表中选择 OpenShift Update Service。
3. 点 Update Service 选项卡。
4. 点 Create UpdateService。
5. 在 Name 字段中输入名称，如 service。
6. 在 Graph Data Image 字段中输入本地 pullspec，指向在"创建 OpenShift Update Service 图形数

据容器镜像"中创建的图形数据容器镜像，如 registry.example.com/openshift/graph-
data:latest。
7. 在 Releases 字段中，输入创建的本地 registry 和存储库，以在"镜像 OpenShift Container

Platform 镜像存储库"中包括发行镜像，例如 registry.example.com/ocp4/openshift4-release-
images。
8. 在 Replicas 字段中输入 2。
9. 单击 Create 以创建 OpenShift Update Service 应用。
10. 验证 OpenShift Update Service 应用程序：
从 Update Service 选项卡中的 UpdateServices 列表中，点刚才创建的 Update Service 应

用程序。
单击 Resources 选项卡。
验证每个应用资源的状态是否为 Created。
11.3.7.2. 使用 CLI 创建 OpenShift Update Service 应用程序
您可以使用 OpenShift CLI（oc）来创建 OpenShift Update Service 应用。
先决条件
62

的存储库。
流程
1. 配置 OpenShift Update Service 目标命名空间，如 openshift-update-service：
$ NAMESPACE=openshift-update-service
命名空间必须与 operator 组中的 targetNamespaces 值匹配。
2. 配置 OpenShift Update Service 应用程序的名称，如 service：
$ NAME=service
3. 按照"镜像 OpenShift Container Platform 镜像存储库"中配置，为发行镜像配置本地 registry 和存

储库，如 registry.example.com/ocp4/openshift4-release-images：
$ RELEASE_IMAGES=registry.example.com/ocp4/openshift4-release-images
4. 将 graph-data 镜像的本地 pullspec 设置为在"创建 OpenShift Update Service 图形数据容器镜

像"中创建的图形数据容器镜像，如 registry.example.com/openshift/graph-data:latest:
$ GRAPH_DATA_IMAGE=registry.example.com/openshift/graph-data:latest
5. 创建 OpenShift Update Service 应用程序对象：
$ oc -n "${NAMESPACE}" create -f - <<EOF

apiVersion: updateservice.operator.openshift.io/v1
kind: UpdateService
metadata:
name: ${NAME}
spec:
replicas: 2
releases: ${RELEASE_IMAGES}
graphDataImage: ${GRAPH_DATA_IMAGE}
EOF
6. 验证 OpenShift Update Service 应用程序：
a. 使用以下命令获取策略引擎路由：
$ while sleep 1; do POLICY_ENGINE_GRAPH_URI="$(oc -n "${NAMESPACE}" get -o

jsonpath='{.status.policyEngineURI}/api/upgrades_info/v1/graph{"\n"}' updateservice
"${NAME}")"; SCHEME="${POLICY_ENGINE_GRAPH_URI%%:*}"; if test "${SCHEME}"
= http -o "${SCHEME}" = https; then break; fi; done
您可能需要轮询，直到命令成功为止。
b. 从策略引擎检索图形。确保为 channel 指定一个有效版本。例如，如果在 OpenShift
63
b. 从策略引擎检索图形。确保为 channel 指定一个有效版本。例如，如果在 OpenShift

Container Platform 4.10 中运行，请使用 stable-4.10 ：
$ while sleep 10; do HTTP_CODE="$(curl --header Accept:application/json --output

/dev/stderr --write-out "%{http_code}" "${POLICY_ENGINE_GRAPH_URI}?
channel=stable-4.6")"; if test "${HTTP_CODE}" -eq 200; then break; fi; echo
"${HTTP_CODE}"; done
这会轮询到图形请求成功为止，但生成的图形可能为空，具体取决于您已镜像的发行镜像。
注意
基于 RFC-1123 的策略引擎路由名称不能超过 63 个字符。如果您看到

ReconcileCompleted 状态为 false，原因为 CreateRouteFailed caused by host must
conform to DNS 1123 naming convention and must be no more than 63
characters，请尝试使用较短的名称创建 Update Service。
11.3.7.2.1. 配置 Cluster Version Operator（CVO）
安装 OpenShift Update Service Operator 并创建 OpenShift Update Service 应用程序后，可以更新

Cluster Version Operator（CVO）从本地安装的 OpenShift Update Service 中拉取图形数据。
先决条件

的存储库。
OpenShift Update Service 应用已创建。
流程
1. 设置 OpenShift Update Service 目标命名空间，如 openshift-update-service：
$ NAMESPACE=openshift-update-service
2. 设置 OpenShift Update Service 应用程序的名称，如 service：
$ NAME=service
3. 获取策略引擎路由：
$ POLICY_ENGINE_GRAPH_URI="$(oc -n "${NAMESPACE}" get -o

jsonpath='{.status.policyEngineURI}/api/upgrades_info/v1/graph{"\n"}' updateservice
"${NAME}")"
4. 为拉取图形数据设置补丁：
$ PATCH="{\"spec\":{\"upstream\":\"${POLICY_ENGINE_GRAPH_URI}\"}}"
5. 对 CVO 进行补丁以使用本地 OpenShift 更新服务：
64
$ oc patch clusterversion version -p $PATCH --type merge
注意
请参阅启用集群范围代理以将 CA 配置为信任更新服务器。
11.3.8. 后续步骤
在更新集群前，请确认满足以下条件：
Cluster Version Operator (CVO) 被配置为使用本地安装的 OpenShift Update Service 应用程

序。
新发行版本的发行镜像签名配置映射应用到集群。
当前发行版本和更新目标发行镜像被镜像到本地可访问的 registry 中。
最近图数据容器镜像已镜像到本地 registry。
将集群配置为使用本地安装的 OpenShift Update Service 和本地镜像 registry 后，您可以使用以下任何更

新方法：
使用 Web 控制台更新集群
准备执行 EUS 更新
执行 canary rollout 更新
更新包含使用 RHEL 的计算（compute）系统的集群
11.4. 在没有 OPENSHIFT UPDATE SERVICE 的断开连接的环境中更新集群

使用以下步骤在断开连接的环境中更新集群，而无需访问 OpenShift Update Service。
11.4.1. 先决条件
您必须安装了 oc 命令行界面（CLI）工具。
您必须使用容器镜像置备本地容器镜像 registry，如镜像 OpenShift Container Platform 镜像存储

库中所述。
您必须可以使用具有 admin 权限的用户访问集群。请参阅使用 RBAC 定义和应用权限。
您需要具有最新的 etcd 备份，以防因为升级失败需要将集群恢复到以前的状态。


态。如需更多信息，请参阅为 AWS、Azure 或 GCP 手动维护凭证升级集群。

65

11.4.2. 暂停 MachineHealthCheck 资源
先决条件
流程
1. 要列出您要暂停的所有可用 MachineHealthCheck 资源，请运行以下命令：
$ oc get machinehealthcheck -n openshift-machine-api
2. 要暂停机器健康检查，请将 cluster.x-k8s.io/paused="" 注解添加到 MachineHealthCheck 资

源。运行以下命令:
$ oc -n openshift-machine-api annotate mhc <mhc-name> cluster.x-k8s.io/paused=""
注解的 MachineHealthCheck 资源类似以下 YAML 文件：
apiVersion: machine.openshift.io/v1beta1
kind: MachineHealthCheck
metadata:
name: example
namespace: openshift-machine-api
annotations:
cluster.x-k8s.io/paused: ""
spec:
selector:
matchLabels:
role: worker
unhealthyConditions:
- type: "Ready"
status: "Unknown"
timeout: "300s"
- type: "Ready"
status: "False"
timeout: "300s"
maxUnhealthy: "40%"
status:
currentHealthy: 5
expectedMachines: 5
重要
66
重要
更新集群后恢复机器健康检查。要恢复检查，请运行以下命令从
MachineHealthCheck 资源中删除暂停注解：
$ oc -n openshift-machine-api annotate mhc <mhc-name> cluster.x-

k8s.io/paused-
11.4.3. 升级断开连接的集群
将受限网络集群更新至您下载的发行镜像的 OpenShift Container Platform 版本。
注意
如果您有一个本地 OpenShift Update Service，您可以使用连接的 Web 控制台或 CLI 指令

来更新，而不是使用此流程。
先决条件
您已将新发行版本的镜像镜像（mirror）到 registry。
您已将发行镜像签名 ConfigMap 在新发行版本中应用到集群。
从镜像签名 ConfigMap 中获取了发行版本的 sha256 sum 值。
流程
更新集群：
$ oc adm upgrade --allow-explicit-upgrade --to-image

${LOCAL_REGISTRY}/${LOCAL_REPOSITORY}<sha256_sum_value> 1
1 <sha256_sum_value> 值是镜像签名 ConfigMap 的 sha256 sum 值，例如

@sha256:81154f5c03294534e1eaf0319BEF7a601134f891689ccede5d705ef659aa8c92
如果镜像 registry 使用 ImageContentSourcePolicy，可以使用 Canonical registry 名称而非

LOCAL_REGISTRY。
注意
您只能为具有 ImageContentSourcePolicy 对象的集群配置全局 pull secret。您

不能在项目中添加 pull secret。
11.4.4. 配置镜像 registry 存储库镜像

通过设置容器 registry 存储库镜像，您可以进行以下操作：
配置 OpenShift Container Platform 集群，以便重定向从源镜像 registry 上的存储库拉取（pull）

镜像的请求，并通过已镜像 (mirror) 的镜像 registry 上的存储库来解决该请求。
67
为每个目标存储库识别多个已镜像 (mirror)的存储库，以确保如果一个镜像停止运作，仍可使用
其他镜像。
OpenShift Container Platform 中存储库镜像的属性包括：
镜像拉取（pull）可应对 registry 停机的问题。
在断开连接的环境中的集群可以从关键位置（如 quay.io）拉取镜像，并让公司防火墙后面的
registry 提供请求的镜像。
发出镜像拉取（pull）请求时尝试特定 registry 顺序，通常最后才会尝试持久性 registry。
您所输入的镜像信息会添加到 OpenShift Container Platform 集群中每个节点上的

/etc/containers/registries.conf 文件中。
当节点从源存储库中请求镜像时，它会依次尝试每个已镜像的存储库，直到找到所请求的内容。
如果所有镜像均失败，集群则会尝试源存储库。如果成功，则镜像拉取至节点中。
可通过以下方式设置存储库镜像：
在 OpenShift Container Platform 安装中：

通过拉取（pull） OpenShift Container Platform 所需的容器镜像，然后将这些镜像放至公司防火
墙后，即可将 OpenShift Container Platform 安装到受限网络中的数据中心。
安装 OpenShift Container Platform 后：

即使没有在 OpenShift Container Platform 安装期间配置镜像 (mirror)，之后您仍可使用
ImageContentSourcePolicy 对象进行配置。
以下流程提供安装后镜像配置，您可在此处创建 ImageContentSourcePolicy 对象来识别：
您希望镜像 (mirror) 的容器镜像存储库的源。
您希望为其提供从源存储库请求的内容的每个镜像存储库的单独条目。
注意
您只能为具有 ImageContentSourcePolicy 对象的集群配置全局 pull secret。您不能在项

目中添加 pull secret。
先决条件
使用具有 cluster-admin 角色的用户访问集群。
流程
1. 通过以下方法配置已镜像的存储库：
按照 Red Hat Quay 存储库镜像中所述，使用 Red Hat Quay 来设置已镜像的存储库。使用

Red Hat Quay 有助于您将镜像从一个存储库复制到另一存储库，并可随着时间的推移重复自
动同步这些存储库。
使用 skopeo 等工具手动将镜像从源目录复制到已镜像的存储库。
例如：在 Red Hat Enterprise Linux（RHEL 7 或 RHEL 8）系统上安装 skopeo RPM 软件包
后，使用 skopeo 命令，如下例所示：
$ skopeo copy \
68
docker://registry.access.redhat.com/ubi8/ubi-
minimal@sha256:5cfbaf45ca96806917830c183e9f37df2e913b187adb32e89fd83fa455eba
a6 \
docker://example.io/example/ubi-minimal
在本例中，您有一个名为 example.io 的容器镜像 registry，其中包含一个名为 example 的

镜像存储库，您希望将 ubi8/ubi-minimal 镜像从 registry.access.redhat.com 复制到此镜
像存储库。创建该 registry 后，您可将 OpenShift Container Platform 集群配置为将源存储
库的请求重定向到已镜像的存储库。
2. 登录您的 OpenShift Container Platform 集群。
3. 创建 ImageContentSourcePolicy 文件（如：registryrepomirror.yaml），将源和镜像 (mirror)

替换为您自己的 registry、存储库对和镜像中的源和镜像：
apiVersion: operator.openshift.io/v1alpha1
kind: ImageContentSourcePolicy
metadata:
name: ubi8repo
spec:
repositoryDigestMirrors:
- mirrors:
- example.io/example/ubi-minimal 1
- example.com/example/ubi-minimal 2
source: registry.access.redhat.com/ubi8/ubi-minimal 3
- mirrors:
- mirror.example.com/redhat
source: registry.redhat.io/openshift4 4
- mirrors:
- mirror.example.com
source: registry.redhat.io 5
- mirrors:
- mirror.example.net/image
source: registry.example.com/example/myimage 6
- mirrors:
- mirror.example.net
source: registry.example.com/example 7
- mirrors:
- mirror.example.net/registry-example-com
source: registry.example.com 8
1 指明镜像 registry 和存储库的名称。
2 表示每个目标仓库的多个镜像仓库。如果一个镜像停机，则目标仓库可以使用另一个镜像。
3 指明包含所镜像内容的 registry 和存储库。
4 您可以在 registry 中配置命名空间以使用该命名空间中的任何镜像。如果您使用 registry 域

作为源，ImageContentSourcePolicy 资源将应用到 registry 中的所有存储库。
5 如果配置 registry 名称，则 ImageContentSourcePolicy 资源将应用到源 registry 中的所有

软件仓库。
6 拉取镜像 mirror.example.net/image@sha256:…。
69
7 从 mirror mirror.example.net/myimage@sha256:… 的源 registry 命名空间中拉取镜像

myimage。
8 从 mirror registry mirror.example.net/registry-example-

com/example/myimage@sha256:… 拉取镜像
registry.example.com/example/myimage。ImageContentSourcePolicy 资源会应用到
源 registry 中的所有仓库到到 mirror registry mirror.example.net/registry-example-
com。
4. 创建新的 ImageContentSourcePolicy 对象：
$ oc create -f registryrepomirror.yaml
创建 ImageContentSourcePolicy 对象后，新的设置将部署到每个节点，集群开始使用已镜像的
存储库来响应源存储库请求。
5. 要检查是否应用了已镜像的配置设置，在其中一个节点上执行以下内容。
a. 列出您的节点：
$ oc get node
输出示例

ip-10-0-137-44.ec2.internal Ready worker 7m v1.24.0
ip-10-0-138-148.ec2.internal Ready master 11m v1.24.0
Imagecontentsourcepolicy 资源不会重启节点。
b. 启动调试过程以访问节点：
$ oc debug node/ip-10-0-147-35.ec2.internal
输出示例
Starting pod/ip-10-0-147-35ec2internal-debug ...

To use host binaries, run `chroot /host`
c. 将您的根目录改为 /host ：
sh-4.2# chroot /host
d. 检查 /etc/containers/registries.conf 文件，确保已完成更改：
sh-4.2# cat /etc/containers/registries.conf
输出示例
70
unqualified-search-registries = ["registry.access.redhat.com", "docker.io"]

short-name-mode = ""
[[registry]]
prefix = ""
location = "registry.access.redhat.com/ubi8/ubi-minimal"
mirror-by-digest-only = true
[[registry.mirror]]
location = "example.io/example/ubi-minimal"
[[registry.mirror]]
location = "example.com/example/ubi-minimal"
[[registry]]
prefix = ""
location = "registry.example.com"
[[registry.mirror]]
location = "mirror.example.net/registry-example-com"
[[registry]]
prefix = ""
location = "registry.example.com/example"
[[registry.mirror]]
location = "mirror.example.net"
[[registry]]
prefix = ""
location = "registry.example.com/example/myimage"
[[registry.mirror]]
location = "mirror.example.net/image"
[[registry]]
prefix = ""
location = "registry.redhat.io"
[[registry.mirror]]
location = "mirror.example.com"
[[registry]]
prefix = ""
location = "registry.redhat.io/openshift4"
[[registry.mirror]]
location = "mirror.example.com/redhat"
e. 将镜像摘要从源拉取到节点，并检查是否通过镜像解析。ImageContentSourcePolicy 对象
仅支持镜像摘要，不支持镜像标签。
71
sh-4.2# podman pull --log-level=debug registry.access.redhat.com/ubi8/ubi-

minimal@sha256:5cfbaf45ca96806917830c183e9f37df2e913b187adb32e89fd83fa455eba
a6
存储库镜像故障排除
如果存储库镜像流程未按规定工作，请使用以下有关存储库镜像如何工作的信息协助排查问题。
首个工作镜像用于提供拉取（pull）的镜像。
只有在无其他镜像工作时，才会使用主 registry。
从系统上下文，Insecure 标志用作回退。
最近更改了 /etc/containers/registries.conf 文件的格式。现在它是第 2 版，采用 TOML 格式。
11.4.5. 镜像镜像目录的范围，以减少集群节点重启的频率
您可以在存储库级别或更广泛的 registry 级别限定镜像目录。一个范围广泛的
ImageContentSourcePolicy 资源可减少节点在响应资源更改时需要重启的次数。
要强化 ImageContentSourcePolicy 资源中镜像目录的范围，请执行以下步骤。
先决条件
安装 OpenShift Container Platform CLI oc。
以具有 cluster-admin 权限的用户身份登录。
配置镜像镜像目录，以便在断开连接的集群中使用。
流程
1. 运行以下命令，为 <local_registry>、<pull_spec> 和 <pull_secret_file> 指定值：
$ oc adm catalog mirror <local_registry>/<pull_spec> <local_registry> -a <pull_secret_file> --

icsp-scope=registry
其中：
<local_registry>
您为断开连接的集群配置的本地 registry，如 local.registry:5000。
<pull_spec>
是断开连接的 registry 中配置的 pull 规格，如 redhat/redhat-operator-index:v4.10
<pull_secret_file>
是 .json 文件格式的 registry.redhat.io pull secret。您可以从 Red Hat OpenShift Cluster
Manager 下载 pull secret。
oc adm catalog mirror 命令创建 /redhat-operator-index-manifests 目录，并生成

imageContentSourcePolicy.yaml、catalogSource.yaml 和 mapping.txt 文件。
2. 将新的 ImageContentSourcePolicy 资源应用到集群：
$ oc apply -f imageContentSourcePolicy.yaml
72
验证
验证 oc apply 是否成功将更改应用到 ImageContentSourcePolicy:
$ oc get ImageContentSourcePolicy -o yaml
输出示例
apiVersion: v1
items:
- apiVersion: operator.openshift.io/v1alpha1
kind: ImageContentSourcePolicy
metadata:
annotations:
kubectl.kubernetes.io/last-applied-configuration: |
{"apiVersion":"operator.openshift.io/v1alpha1","kind":"ImageContentSourcePolicy","metadata":
{"annotations":{},"name":"redhat-operator-index"},"spec":{"repositoryDigestMirrors":
[{"mirrors":["local.registry:5000"],"source":"registry.redhat.io"}]}}
...
更新 ImageContentSourcePolicy 资源后，OpenShift Container Platform 会将新设置部署到每个节点，

集群开始使用已镜像的存储库向源存储库发出请求。
11.4.6. 其他资源
在受限网络中使用 Operator Lifecycle Manager
机器配置概述
11.5. 从集群中删除 OPENSHIFT UPDATE SERVICE

要从集群中删除 OpenShift Update Service (OSUS) 的本地副本，您必须首先删除 OSUS 应用程序，然
后卸载 OSUS Operator。
11.5.1. 删除 OpenShift Update Service 应用程序

您可以使用 OpenShift Container Platform Web 控制台或 CLI 删除 OpenShift Update Service 应用程
序。
11.5.1.1. 使用 Web 控制台删除 OpenShift Update Service 应用程序
您可以使用 OpenShift Container Platform Web 控制台使用 OpenShift Update Service Operator 删除
OpenShift Update Service 应用程序。
先决条件
流程
73
2. 从安装的 Operator 列表中选择 OpenShift Update Service。
3. 点 Update Service 选项卡。
4. 从安装的 OpenShift Update Service 应用列表中，选择要删除的应用，然后单击 Delete

UpdateService。
5. 从 Delete UpdateService? 确认对话框中，单击 Delete 以确认删除。
11.5.1.2. 使用 CLI 删除 OpenShift Update Service 应用程序
您可以使用 OpenShift CLI（oc）删除 OpenShift Update Service 应用。
流程
1. 使用 OpenShift Update Service 应用程序在其中创建的命名空间获取 OpenShift Update Service

应用程序的名称，如 openshift-update-service：
$ oc get updateservice -n openshift-update-service
输出示例
NAME AGE
service 6s
2. 使用上一步中的 NAME 值以及 OpenShift Update Service 应用程序创建命名空间删除 OpenShift

Update Service 应用程序，如 openshift-update-service：
$ oc delete updateservice service -n openshift-update-service
输出示例
updateservice.updateservice.operator.openshift.io "service" deleted
11.5.2. 卸载 OpenShift Update Service Operator

您可以使用 OpenShift Container Platform Web 控制台或 CLI 卸载 OpenShift Update Service
Operator。
11.5.2.1. 使用 Web 控制台卸载 OpenShift Update Service Operator
您可以使用 OpenShift Container Platform Web 控制台卸载 OpenShift Update Service Operator。
先决条件
所有 OpenShift Update Service 应用都已删除。
流程
2. 从安装的 Operator 列表中选择 OpenShift Update Service 并点 Uninstall Operator。
74
3. 在 Uninstall Operator? 确认对话框中点 Uninstall 确认卸载。
11.5.2.2. 使用 CLI 卸载 OpenShift Update Service Operator
您可以使用 OpenShift CLI（oc）卸载 OpenShift Update Service Operator。
先决条件
所有 OpenShift Update Service 应用都已删除。
流程
1. 更改到包含 OpenShift Update Service Operator 的项目，如 openshift-update-service：
$ oc project openshift-update-service
输出示例
Now using project "openshift-update-service" on server "https://example.com:6443".
2. 获取 OpenShift Update Service Operator operator 组的名称：
$ oc get operatorgroup
输出示例
NAME AGE
openshift-update-service-fprx2 4m41s
3. 删除 operator 组，如 openshift-update-service-fprx2：
$ oc delete operatorgroup openshift-update-service-fprx2
输出示例
operatorgroup.operators.coreos.com "openshift-update-service-fprx2" deleted
4. 获取 OpenShift Update Service Operator 订阅的名称：
$ oc get subscription
输出示例
NAME PACKAGE SOURCE CHANNEL

update-service-operator update-service-operator updateservice-index-catalog v1
5. 使用上一步中的 Name 值，在 currentCSV 字段中检查订阅的 OpenShift Update Service

Operator 的当前版本：
$ oc get subscription update-service-operator -o yaml | grep " currentCSV"
75
输出示例
currentCSV: update-service-operator.v0.0.1
6. 删除订阅，如 update-service-operator：
$ oc delete subscription update-service-operator
输出示例
subscription.operators.coreos.com "update-service-operator" deleted
7. 使用上一步中的 currentCSV 值删除 OpenShift Update Service Operator 的 CSV：
$ oc delete clusterserviceversion update-service-operator.v0.0.1
输出示例
clusterserviceversion.operators.coreos.com "update-service-operator.v0.0.1" deleted
76
第 12 章更新在 VSPHERE 上运行的节点上运行的硬件

您必须确保您在 vSphere 中运行的节点在 OpenShift Container Platform 支持的硬件版本上运行。目前，
硬件版本 13 或更高版本都支持集群中的 vSphere 虚拟机。
您可以立即更新虚拟硬件，或在 vCenter 中计划更新。
重要
在 vSphere 上运行的集群节点使用硬件版本 13 现已弃用。这个版本仍然被完全支持，但在

以后的 OpenShift Container Platform 版本中将会删除支持。现在，硬件版本 15 是
OpenShift Container Platform 中 vSphere 虚拟机的默认版本。
12.1. 更新 VSPHERE 上的虚拟硬件

要在 VMware vSphere 上更新虚拟机 (VM) 的硬件，请单独更新您的虚拟机，以减少集群停机风险。
12.1.1. 为 vSphere 上的 control plane 节点更新虚拟硬件

为降低停机风险，建议按顺序升级 control plane 节点。这样可确保 Kubernetes API 保持可用，etcd 保留
仲裁。
先决条件
在托管 OpenShift Container Platform 集群的 vCenter 实例中具有执行所需权限的权限。
您的 vSphere ESXi 主机是 6.7U3 或更高版本。
流程
1. 列出集群中的 control plane 节点。
$ oc get nodes -l node-role.kubernetes.io/master
输出示例

control-plane-node-0 Ready master 75m v1.23.0
请注意 control plane 节点的名称。
2. 将 control plane 节点标记为不可调度。
$ oc adm cordon <control_plane_node>
3. 关闭与 control plane 节点关联的虚拟机 (VM)。在 vSphere 客户端中通过右键单击虚拟机并选择

Power → Shut Down Guest OS 进行此操作。不要使用 Power Off 来关闭虚拟机，因为它可能
无法安全地关闭。
4. 在 vSphere 客户端中升级虚拟机。如需更多信息，请参阅 VMware 文档中的将虚拟机升级到最新

硬件版本。
77
5. 打开与 control plane 节点关联的虚拟机。在 vSphere 客户端中通过右键单击虚拟机并选择

Power On 来进行此操作。
6. 等待节点报告为 Ready ：
$ oc wait --for=condition=Ready node/<control_plane_node>
7. 再次将 control plane 节点标记为可以调度：
$ oc adm uncordon <control_plane_node>
8. 对集群中的每个 control plane 节点重复此步骤。
12.1.2. 更新 vSphere 上计算节点的虚拟硬件

为降低停机风险，建议按顺序升级计算节点。
注意
可以并行升级多个计算节点，给定的工作负载可以接受多个节点处于 NotReady 状态。管

理员负责确保所需的计算节点可用。
先决条件
流程
1. 列出集群中的计算节点。
$ oc get nodes -l node-role.kubernetes.io/worker
输出示例

compute-node-0 Ready worker 30m v1.23.0
注意计算节点的名称。
2. 将计算节点标记为不可调度：
$ oc adm cordon <compute_node>
3. 从计算节点撤离容器集。执行此操作有多种方法。例如，您可以撤离节点上的所有或选定 pod：
$ oc adm drain <compute_node> [--pod-selector=<pod_selector>]
如需从节点上撤离 pod 的其他选项，请参阅"如何撤离节点上的 pod"部分。
4. 关闭与计算节点关联的虚拟机 (VM)。在 vSphere 客户端中通过右键单击虚拟机并选择 Power →

78
4. 关闭与计算节点关联的虚拟机 (VM)。在 vSphere 客户端中通过右键单击虚拟机并选择 Power →

Shut Down Guest OS 进行此操作。不要使用 Power Off 来关闭虚拟机，因为它可能无法安全地
关闭。
5. 在 vSphere 客户端中升级虚拟机。如需更多信息，请参阅 VMware 文档中的将虚拟机升级到最新

硬件版本。
6. 打开与计算节点关联的虚拟机。在 vSphere 客户端中通过右键单击虚拟机并选择 Power On 来进

行此操作。
7. 等待节点报告为 Ready ：
$ oc wait --for=condition=Ready node/<compute_node>
8. 将计算节点再次标记为可调度：
$ oc adm uncordon <compute_node>
9. 对集群中的每个计算节点重复此步骤。
12.1.3. 为 vSphere 上的模板更新虚拟硬件
先决条件
流程
1. 如果 RHCOS 模板被配置为 vSphere 模板，请在进行下一步前参阅将模板转换为一个虚拟机。
注意
从模板转换后，请不要打开虚拟机电源。
1. 更新 vSphere 客户端中的虚拟机。如需更多信息，请参阅 VMware 文档中的将虚拟机升级到最新

硬件版本。
2. 将 vSphere 客户端中的虚拟机从虚拟机转换为模板。如需更多信息，请参阅 VMware 文档中的将

虚拟机转换为 vSphere 客户端中的模板。
其他资源
了解如何撤离节点上的 pod
12.2. 在 VSPHERE 上调度虚拟硬件的更新

虚拟机开启或重新启动时，可以计划进行虚拟硬件更新。您可以按照 VMware 文档中的虚拟机兼容性升级
调度专门在 vCenter 中调度虚拟硬件更新。
在 OpenShift Container Platform 升级前调度升级时，在 OpenShift Container Platform 升级过程中重启

节点时会进行虚拟硬件更新。
79
80

Openshift Container Platform 4.10 Updating Clusters ZH CN

Uploaded by

Copyright:

Available Formats

Openshift Container Platform 4.10 Updating Clusters ZH CN

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Openshift Container Platform 4.10 Updating Clusters ZH CN

Uploaded by

Copyright:

Available Formats

OpenShift Container Platform 4.

更新 OpenShift Container Platform 集群

Last Updated: 2023-04-21

Java ® is a registered trademark of Oracle and/or its affiliates.

All other trademarks are the property of their respective owners.

1.1. 了解 OPENSHIFT CONTAINER PLATFORM 更新

fast 和 stable 频道的使用和策略

1.3. 了解集群 OPERATOR 条件类型

Cluster Version Operator (CVO) 负责从集群 Operator 收集状态条件，以便集群管理员可以更好地了解

available: 条件类型 Available 表示 Operator 功能且在集群中可用。如果状态是 False，则操作

progressing: 条件类型 Progressing 表示 Operator 正在主动推出新的代码、传播配置更改，或

Degraded：条件类型 Degraded 表示 Operator 具有在一段时间内不匹配其所需状态的当前状

此条件类型仅表示可能需要调查和调整某项。只要 Operator 可用，Degraded 条

Upgradeable: 条件类型 Upgradeable 表示 Operator 是否根据当前的集群状态安全升级。

除了 Available,Progressing, 和 Upgradeable 外，还有影响集群版本和 Operator 的条件类型。

Failing：集群版本状况类型 Failing 表示集群无法访问其所需状态，不健康，需要管理员干预。

Invalid: 集群版本条件类型 Invalid 表示集群版本具有阻止服务器执行操作的错误。只要设置了此

RetrievedUpdates ：集群版本条件类型 RetrievedUpdates 表示已从上游更新服务器检索可用更

ReleaseAccepted ：集群版本状况类型 ReleaseAccepted，并带有 True 状态表示请求的发行版

2.1. 准备执行 EUS 更新

2.2. 使用 WEB 控制台更新集群

关于在单节点集群中更新 OpenShift Container Platform

关于在单节点集群中更新 OpenShift Container Platform

2.4. 执行 CANARY ROLLOUT 更新

创建机器配置池来执行 Canary rollout 更新

2.5. 更新包含使用 RHEL 的计算（COMPUTE）系统的集群

可选：添加 hook 以在RHEL系统上执行Ansible任务

镜像 OpenShift Container Platform 镜像存储库

配置镜像 registry 存储库镜像

安装 OpenShift Update Service Operator

创建 OpenShift Update Service 应用程序

删除 OpenShift Update Service 应用程序

卸载 OpenShift Update Service Operator

2.7. 更新在 VSPHERE 上运行的节点上运行的硬件

在 vSphere 上运行的集群节点使用硬件版本 13 现已弃用。这个版本仍然被完全支持，但在

第 3 章 了解 OPENSHIFT CONTAINER PLATFORM 更新

OpenShift Update Service(OSUS)根据 registry 中的发行镜像构建了一个更新可能性图。该图基于特定版

之前通过 Operator Lifecycle Manager (OLM) 安装的 Operator 会遵循不同的更新过程。

3.1. 关于 OPENSHIFT UPDATE 服务

为了让 OpenShift Update Service 仅提供兼容的更新，可以使用一个版本验证管道来驱动自动化过程。每

OpenShift Update Service 显示当前集群的所有推荐更新。如果 OpenShift Update

在更新过程中，Machine Config Operator(MCO)将新配置应用到集群机器。MCO 会处理由

当新版本规格应用到旧的 kubelet 时，RHEL 机器无法返回 Ready 状态。在机器可用前，您无法完成更

当新版本规格应用到旧的 kubelet 时，RHEL 机器无法返回 Ready 状态。在机器可用前，您无法完成更

OpenShift Update Service 由 Operator 和一个或多个应用程序实例组成。

升级频道与 OpenShift Container Platform 的次版本关联。频道中的版本号代表集群最终要升级到的目标

例如，OpenShift Container Platform 4.10 更新频道提供以下建议：

从 4.9 升级到 4.10，允许所有 4.9 集群最终更新至 4.10，即使它们没有立即满足最小 z-stream 版

仅限 eus-4.10：在 4.8 中更新。

仅限 eus-4.10: 从 4.8 升级到 4.9 再到 4.10,，允许所有 4.8 集群最终更新至 4.10。

4.10 更新频道不推荐对 4.11 或更高版本的更新。这可确保管理员明确决定升级到下一个 OpenShift

更新频道只控制发行版本选择，不会影响您安装的集群版本。特定版本的 OpenShift Container Platform

OpenShift Container Platform 4.10 提供了以下更新频道：

eus-4.y （只提供 EUS 版本，有助于在 EUS 版本之间进行升级）

如果您不希望 Cluster Version Operator 从升级建议服务获取可用的更新，您可以使用 OpenShift CLI 中

红帽建议升级到 OpenShift Update Service 建议的版本。对于次版本更新，版本必须

当红帽声明版本成为正式发行 (GA) 版本时，fast-4.10 频道被更新为 OpenShift Container Platform 4.10

新安装的集群默认为使用 stable 频道。

标准和非 EUS 订阅者都可以访问所有 EUS 软件仓库和所需的 RPM(rhel-*-eus-rpms)，它

第 3 章了解 OPENSHIFT CONTAINER PLATFORM 更新

第 5 章了解 OPENSHIFT CONTAINER PLATFORM 更新持续时间

EUS 到 EUS 的更新只能在偶数的 OpenShift Container Platform 次版本之间有效。

6. 通过查看集群的最新完成的版本，确保 <4.y+1> 更新已完成。您可以在 Details 选项卡下的

9. 通过查看集群的最新完成的版本，确保 <4.y+2> 更新已完成。您可以在 Details 选项卡下的

您可以通过查看集群的最新完成版本来验证集群是否已完成更新。您可以在 Details 选项卡下的