3.3. 执行 Control Plane Only 更新
由于 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-to-EUS 更新,现在被称为 Control Plane Only 更新。这些更新只能在 偶数的 OpenShift Container Platform 次版本之间进行。
尝试 Control Plane Only 时需要考虑一些注意事项。
-
Control Plane Only 更新仅在所有涉及的版本在
stable
频道中提供。 - 如果您在升级到一个奇数次版本后但在升级到下一个偶数次版本前遇到了问题,则需要在继续进行前,把非控制平面主机完成升级到奇数次版本。
- 您可以通过更新 worker 或自定义池节点来对部分更新进行部分更新,以适应维护所需的时间。
- 在机器配置池被取消暂停且更新完成前,OpenShift Container Platform 的 <4.y+1> 和 <4.y+2> 中的一些功能和程序错误修复不可用。
-
所有集群可能会在不需要暂停池的情况下,对常规更新使用 EUS 频道进行更新,但只有具有非控制平面
MachineConfigPools
对象的集群可以进行 Control Plane Only 更新,且需要暂停池。
3.3.1. 执行 Control Plane Only 更新
以下流程暂停所有非 master 机器配置池,并从 OpenShift Container Platform <4.y> 升级到 <4.y+1> 到 <4.y+2>,然后取消暂停之前暂停的机器配置池。以下过程减少了升级持续时间,以及重启 worker 节点的次数。
先决条件
- 查看 OpenShift Container Platform <4.y+1> 和 <4.y+2> 发行注记
- 查看任何层次产品和 Operator Lifecycle Manager (OLM) Operator 的发行注记和产品生命周期。有些更新可能需要在 Control Plane Only 更新前或期间进行更新。
- 确保您熟悉了特定于版本的前提条件,如删除已弃用的 API,在从 OpenShift Container Platform <4.y+1> 升级到 <4.y+2> 之前是必需的。
3.3.1.1. 使用 Web 控制台执行 Control Plane Only 更新
先决条件
- 验证机器配置池是否已取消暂停。
-
使用具有
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 值。
重要当您更新包含有 Red Hat Enterprise Linux (RHEL) 计算机器的集群时,这些机器会在更新过程中暂时不可用。当集群进入
NotReady
状态时,您需要针对每个 RHEL 机器运行升级 playbook 以完成更新。如需更多信息,请参阅附加资源部分中的"更新包含 RHEL 计算机器的集群"。您可以通过查看集群的 最新完成版本来验证集群是否已完成更新。您可以在 Details 选项卡下的 Cluster Settings 页面中找到此信息。
3.3.1.2. 使用 CLI 执行 Control Plane Only 更新
先决条件
- 验证机器配置池是否已取消暂停。
-
每次更新前,将 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
重要当您更新包含有 Red Hat Enterprise Linux (RHEL) 计算机器的集群时,这些机器会在更新过程中暂时不可用。当集群进入
NotReady
状态时,您需要针对每个 RHEL 机器运行升级 playbook 以完成更新。如需更多信息,请参阅附加资源部分中的"更新包含 RHEL 计算机器的集群"。输出示例
NAME CONFIG UPDATED UPDATING master rendered-master-52da4d2760807cb2b96a3402179a9a4c True False worker rendered-worker-4756f60eccae96fb9dcb4c392c69d497 True False
3.3.1.3. Control Plane only 更新通过 Operator Lifecycle Manager 安装的层次产品和 Operator
除了 web 控制台和 CLI 提到的 Control Plane Only 更新步骤外,还需要考虑使用以下内容为集群执行 Control Plane Only 更新的步骤:
- 层次产品
- 通过 Operator Lifecycle Manager (OLM) 安装的 Operator
什么是层次产品?
层次产品指的是由多个底层产品组成的产品,它们旨在一起使用且不能分为单独的订阅。有关层次 OpenShift Container Platform 产品的示例,请参阅 OpenShift 的分层组件。
当您为分层产品的集群以及通过 OLM 安装的 Operator 执行 Control Plane Only 更新时,您必须完成以下操作:
- 您已将之前通过 Operator Lifecycle Manager (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> 的 Control Plane Only 更新的步骤。这可以通过 CLI 或 Web 控制台来完成。有关如何通过所需接口更新集群的详情,请参考 使用 Web 控制台执行 Control Plane Only 更新, 以及"额外资源"中的使用 CLI 执行 Control Plane 更新。
工作流示例
- 暂停 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 机器池被取消暂停前或之后进行。