第 5 章 准备执行 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 天内完成整个更新。确保完成正常的集群自动化过程非常重要,包括与证书轮转关联的操作。
- 开始 EUS 到 EUS 升级过程前,您必须至少运行 OpenShift Container Platform 4.8.14。如果您没有满足这个最低要求,在尝试 EUS 升级到 EUS 前,升级到更新的 4.8.z。
- OpenShift Container Platform 4.10 中删除了对 RHEL7 worker 的支持,并使用 RHEL8 worker 替代,因此使用 RHEL7 worker 的集群没有 EUS 到 EUS 的升级。
- 节点组件没有更新至 OpenShift Container Platform 4.9。在完成升级到 OpenShift Container Platform 4.10 前,不要预期 OpenShift Container Platform 4.9 中修复的所有功能和错误都可用,并启用所有 MachineConfigPool 进行更新。
5.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 更新之前或进行中进行。
5.1.1. 使用 Web 控制台进行 EUS 到 EUS 更新
先决条件
- 验证机器配置池是否已取消暂停。
-
使用具有
admin
权限的用户登陆到 web 控制台。
流程
- 使用 Web 控制台中的 Administrator 视角,将任何 Operator Lifecycle Manager (OLM) Operator 更新至与您的预期更新版本兼容的版本。您可以在"更新安装的 Operator"中找到有关如何执行此操作的更多信息;请参阅"添加资源"。
验证所有机器配置池的状态是否为
Up to date
,并且没有机器配置池显示UPDATING
的状态。要查看所有机器配置池的状态,请点 Compute
MachineConfigPools 并查看 Update status 列的内容。 注意如果您的机器配置池具有
Updating
状态,请等待此状态更改为Up to date
。这个过程可能需要几分钟时间。将频道设置为
eus-<4.y+2>
。要设置您的频道,请点 Administration
Cluster Settings Channel。您可以点当前的超链接频道来编辑频道。 - 暂停除 master 池外的所有 worker 机器池。您可以在 Compute 页面的 MachineConfigPools 标签页中执行此操作。选择您要暂停的机器配置池旁边的垂直图标,然后点 暂停更新。
- 更新至 <4.y+1> 版本并完成到 Save 步骤。您可以在"使用 Web 控制台更新集群"中找到有关如何执行这些操作的更多信息;请参阅"添加资源"。
- 通过查看集群的 最新完成的版本,确保 <4.y+1> 更新已完成。您可以在 Details 选项卡下的 Cluster Settings 页面中找到此信息。
- 如有必要,使用 web 控制台中的 Administrator 视角更新 OLM Operator。您可以在"更新安装的 Operator"中找到有关如何执行此操作的更多信息;请参阅"添加资源"。
- 更新至 <4.y+2> 版本并完成到 Save 步骤。您可以在"使用 Web 控制台更新集群"中找到有关如何执行这些操作的更多信息;请参阅"添加资源"。
- 通过查看集群的 最新完成的版本,确保 <4.y+2> 更新已完成。您可以在 Details 选项卡下的 Cluster Settings 页面中找到此信息。
取消暂停所有之前暂停的机器配置池。您可以在 Compute 页面的 MachineConfigPools 标签页中执行此操作。选择您要暂停的机器配置池旁边的垂直图标,然后点 Unpause updates。
重要如果没有取消暂停池,集群就无法升级到将来的任何次要版本,而维护任务(如证书轮转)会被禁止。这会使集群面临未来降级的风险。
验证之前暂停的池是否已更新,并且集群是否完成了更新到版本 <4.y+2>。
您可以通过 Compute 页中的 MachineConfigPools 标签页来验证您的池已更新。其 Update status 应用带有一个 Up to date 值。
您可以通过查看集群的 最新完成版本来验证集群是否已完成更新。您可以在 Details 选项卡下的 Cluster Settings 页面中找到此信息。
5.1.2. 使用 CLI 进行 EUS 到 EUS 更新
先决条件
- 验证机器配置池是否已取消暂停。
-
每次更新前,将 OpenShift CLI (
oc
) 更新至目标版本。
强烈建议您跳过此先决条件。如果在更新前没有将 OpenShift CLI (oc
) 更新至目标版本,则可能会出现意外的问题。
流程
- 使用 Web 控制台中的 Administrator 视角,将任何 Operator Lifecycle Manager (OLM) Operator 更新至与您的预期更新版本兼容的版本。您可以在"更新安装的 Operator"中找到有关如何执行此操作的更多信息;请参阅"添加资源"。
验证所有机器配置池的状态是否为
UPDATED
,并且没有机器配置池显示UPDATING
的状态。要查看所有机器配置池的状态,请运行以下命令:$ oc get mcp
输出示例
NAME CONFIG UPDATED UPDATING master rendered-master-ecbb9582781c1091e1c9f19d50cf836c True False worker rendered-worker-00a3f0c68ae94e747193156b491553d5 True False
您当前版本为 <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 天。运行以下命令,暂停除 master 池之外的所有 worker 机器池:
$ oc patch mcp/worker --type merge --patch '{"spec":{"paused":true}}'
注意您无法暂停 master 池。
运行以下命令来更新到最新版本:
$ oc adm upgrade --to-latest
输出示例
Updating to latest version <4.y+1.z>
运行以下命令,查看集群版本以确保更新已完成:
$ oc adm upgrade
输出示例
Cluster version is <4.y+1.z> ...
运行以下命令,更新至 <4.y+2> 版本:
$ oc adm upgrade --to-latest
运行以下命令,检索集群版本以确保 <4.y+2> 更新已完成:
$ oc adm upgrade
输出示例
Cluster version is <4.y+2.z> ...
要将 worker 节点更新至 <4.y+2>,请运行以下命令取消暂停所有之前暂停的机器配置池:
$ oc patch mcp/worker --type merge --patch '{"spec":{"paused":false}}'
重要如果没有取消暂停池,集群就无法升级到将来的任何次要版本,而维护任务(如证书轮转)会被禁止。这会使集群面临未来降级的风险。
运行以下命令,验证之前暂停的池是否已更新,并升级到 <4.y+2> 版本:
$ oc get mcp
输出示例
NAME CONFIG UPDATED UPDATING master rendered-master-52da4d2760807cb2b96a3402179a9a4c True False worker rendered-worker-4756f60eccae96fb9dcb4c392c69d497 True False
其他资源
5.1.3. 通过 Operator Lifecycle Manager 安装的分层产品和 Operator 的 EUS 到 EUS 更新
除了 web 控制台和 CLI 提到的 EUS 到 EUS 更新步骤外,还需要考虑使用以下内容为集群执行 EUS 到 EUS 更新的步骤:
- 层次产品
- 通过 Operator Lifecycle Manager (OLM) 安装的 Operator
什么是层次产品?
层次产品指的是由多个底层产品组成的产品,它们旨在一起使用且不能分为单独的订阅。有关层次 OpenShift Container Platform 产品的示例,请参阅 OpenShift 的分层组件。
当您为分层产品的集群以及通过 OLM 安装的 Operator 执行 EUS 到 EUS 更新时,您必须完成以下操作:
- 确保之前通过 OLM 安装的所有 Operator 均在其最新频道中更新至其最新版本。更新 Operator 可确保当默认 OperatorHub 目录在集群升级过程中从当前次要版本切换到下一个次版本时,它们具有有效的升级路径。有关如何更新 Operator 的详情,请参考"添加资源"中的"准备 Operator 更新"。
- 确认当前和预期的 Operator 版本之间的集群版本兼容性。您可以使用 Red Hat OpenShift Container Platform Operator Update Information Checker 验证 OLM Operator 兼容哪些版本。
例如,以下是为 OpenShift Data Foundation (ODF )执行从 <4.y> 到 <4.y+2> 的 EUS 到 EUS 更新的步骤。这可以通过 CLI 或 Web 控制台来完成。有关如何通过所需接口更新集群的详情,请参考 使用 Web 控制台进行 EUS 到 EUS 的升级和 "Additional 资源"中的"EUS 到 EUS 的更新"。
工作流示例
- 暂停 worker 机器池。
- 升级 OpenShift <4.y> 到 OpenShift <4.y+1>。
- 升级 ODF <4.y> 到 ODF <4.y+1>。
- 升级 OpenShift <4.y+1> 到 OpenShift <4.y+2>。
- 升级到 ODF <4.y+2>。
- 取消暂停 worker 机器池。
升级到 ODF <4.y+2> 可以在 worker 机器池被取消暂停前或之后进行。