3.2. 使用 Web 控制台更新集群
您可以使用 Web 控制台在 OpenShift Container Platform 集群上执行次版本和补丁更新。
使用 Web 控制台或 oc adm upgrade channel <channel> 更改更新频道。在改到一个 4.16 频道后，按使用 CLI 更新集群中的步骤完成更新。
3.2.1. 在更新 OpenShift Container Platform 集群前
在更新前，请考虑以下几点：
- 最近备份了 etcd。
-
在
PodDisruptionBudget中，如果minAvailable设置为1，节点会排空以应用可能会阻止驱除过程的待处理机器配置。如果重启了几个节点，则所有 pod 只能有一个节点上运行，PodDisruptionBudget字段可能会阻止节点排空。 - 如果集群使用手动维护的凭证，您可能需要为新版本更新云供应商资源。
- 您必须检查管理员确认请求，采取任何推荐的操作，并在准备好时提供确认。
- 您可以通过更新 worker 或自定义池节点来执行部分更新，以适应更新所需的时间。您可以在每个池的进度栏中暂停并恢复。
- 当更新无法完成时，Cluster Version Operator(CVO)会在尝试协调更新时报告任何阻塞组件的状态。当前还不支持将集群还原到以前的版本。如果您的更新无法完成，请联系红帽支持。
-
使用
unsupportedConfigOverrides部分修改 Operator 配置不受支持，并可能会阻止集群更新。您必须在更新集群前删除此设置。
3.2.2. 使用 Web 控制台更改更新服务器
更改更新服务器是可选的。如果您在本地安装和配置了 OpenShift Update Service (OSUS)，您必须将服务器的 URL 设置为 upstream，以便在更新期间使用本地服务器。
先决条件
-
您可以使用
cluster-admin权限访问集群。 - 访问 OpenShift Container Platform web 控制台。
流程
-
导航到 Administration
Cluster Settings，点 version。 点击 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。- 点击 Save。
其他资源
3.2.3. 使用 Web 控制台暂停 MachineHealthCheck 资源
在更新过程中，集群中的节点可能会临时不可用。对于 worker 节点，机器健康检查可能会认为这样的节点不健康，并重新引导它们。为避免重新引导这样的节点，请在更新集群前暂停所有 MachineHealthCheck 资源。
先决条件
-
您可以使用
cluster-admin权限访问集群。 - 访问 OpenShift Container Platform web 控制台。
流程
- 登陆到 OpenShift Container Platform Web 控制台。
-
进入到 Compute
MachineHealthChecks。 要暂停机器健康检查，请在每个
MachineHealthCheck资源中添加cluster.x-k8s.io/paused=""注解。例如，要将注解添加到machine-api-termination-handler资源，请完成以下步骤：-
点
machine-api-termination-handler旁边的 Options 菜单
并点 Edit annotations。
- 在 Edit annotations 对话框中，点 Add more。
-
在 Key 和 Value 字段中，分别添加
cluster.x-k8s.io/paused和""值，然后点 Save。
-
点
3.2.4. 使用Web控制台更新集群
如果有可用更新，您可以从Web控制台更新集群。
您可以在客户门户网站的勘误部分找到有关可用 OpenShift Container Platform 公告和更新的信息。
先决条件
-
使用具有
cluster-admin权限的用户访问 Web 控制台。 - 访问 OpenShift Container Platform web 控制台。
-
暂停所有
MachineHealthCheck资源。 - 您已将之前通过 Operator Lifecycle Manager (OLM) 安装的所有 Operator 更新至与目标发行版本兼容的版本。更新 Operator 可确保当默认 OperatorHub 目录在集群升级过程中从当前次要版本切换到下一个次版本时，它们有有效的升级路径。如需了解如何检查兼容性的更多信息，请参阅"添加资源"部分中的"更新已安装的 Operator"部分，如有必要，更新已安装的 Operator。
- 您的机器配置池 (MCP) 正在运行且未暂停。在更新过程中跳过与暂停 MCP 关联的节点。如果要执行 canary rollout 更新策略，可以暂停 MCP。
- 您的 RHEL7 worker 替换为 RHEL8 或 RHCOS worker。红帽不支持对 RHEL worker 的 从 RHEL7 到 RHEL8 的原位升级 ; 这些主机必须使用干净的操作系统安装替换。
流程
-
在 web 控制台中点击 Administration
Cluster Settings 并查看 Details 选项卡中的内容。 对于生产环境中的集群，请确保将 Channel 设置为您要升级到的版本的正确频道，如
stable-4.16。重要对于生产环境中的集群，您必须订阅一个
stable-*,eus-*或fast-*频道。注意当您准备好升级到下一个次版本时，请选择与该次版本对应的频道。声明更新频道后，集群可以更方便地为您的目标版本更新路径。集群可能需要一些时间来评估所有可用的更新，并提供最佳更新建议。更新建议可能会随时间变化，因为它们基于哪些更新选项。
如果您无法看到到目标次版本的更新路径，请保持将集群更新至当前版本的最新补丁版本，直到下一个次版本在路径中可用。
- 如果 Update 状态 不是 Updates available，则无法升级集群。
- Select channel 表示集群正在运行或正在更新的集群版本。
选择要更新到的版本，然后单击 Save。
输入频道 Update Status 变为Update to <product-version> in progress，您可以通过监视 Operator 和节点的进度条来查看集群更新的进度。
注意如果您要将集群升级到下一个次版本，例如从 4.10 升级到 4.11，请在部署依赖新功能的工作负载前确认您的节点已更新。任何尚未更新的 worker 节点池都会显示在 Cluster Settings 页面。
更新完成后，Cluster Version Operator 会刷新可用更新，检查当前频道中是否有更多可用更新。
- 如果有可用更新，请继续在当前频道中执行更新，直到您无法再更新为止。
-
如果没有可用的更新，请将 Channel 改为下一个次版本的
stable-*,eus-*或fast-*频道，并更新至您在该频道中想要的版本。
您可能需要执行一些过渡的更新，直到您到达您想要的版本。
其他资源
3.2.5. 在 web 控制台中查看条件更新
您可以使用条件更新来查看和评估与特定更新相关的风险。
先决条件
-
您可以使用
cluster-admin权限访问集群。 - 访问 OpenShift Container Platform web 控制台。
-
暂停所有
MachineHealthCheck资源。 - 您已将之前通过 Operator Lifecycle Manager (OLM) 安装的所有 Operator 更新至与目标发行版本兼容的版本。更新 Operator 可确保当默认 OperatorHub 目录在集群升级过程中从当前次要版本切换到下一个次版本时，它们有有效的升级路径。如需了解如何检查兼容性的更多信息，请参阅"添加资源"部分中的"更新已安装的 Operator"部分，如有必要，更新已安装的 Operator。
- 您的机器配置池 (MCP) 正在运行且未暂停。在更新过程中跳过与暂停 MCP 关联的节点。如果要执行高级更新策略，如 Canary rollout、EUS 更新或 control-plane 更新，可以暂停 MCP。
流程
-
在 Web 控制台中，点 Administration
Cluster settings 页面并查看 Details 选项卡的内容。 您可以在 更新集群 模态的 Select new version 下拉列表中启用
Include versions with known issues功能以使下拉列表中包括有条件的更新。注意如果选择了具有已知问题的版本，则会提供与版本相关的潜在风险的更多信息。
- 查看通知详细描述了更新的潜在风险。
其他资源
3.2.6. 执行 canary rollout 更新
在某些情况下，您可能需要一个受控的更新过程，如您不希望特定节点与集群的其余部分同时更新。这些用例包括但不限于：
- 您有任务关键型应用程序，您希望在更新过程中仍然可以使用这些应用程序。在更新后，您可以慢慢地以小批的形式对应用进行测试。
- 您有一个短的维护窗口，在此期间不允许更新所有节点；或者您有多个维护窗口。
滚动更新过程不是典型的更新工作流。对于较大的集群，这可能是一个耗时的过程，需要您执行多个命令。这种复杂性可能会导致出现可能会影响整个集群的错误。建议您仔细考虑您的机构是否希望使用滚动更新，并在开始前仔细规划流程的实施。
本主题中描述的滚动更新过程涉及：
- 创建一个或多个自定义机器配置池 (MCP)。
- 标记您不想立即更新的每个节点，以将这些节点移至自定义 MCP。
- 暂停这些自定义 MCP，这会阻止对这些节点的更新。
- 执行集群更新。
- 取消暂停一个自定义 MCP，它会在这些节点上触发更新。
- 测试这些节点上的应用程序，以确保应用程序在这些新更新的节点上可以正常工作。
- （可选）从小批处理中的其余节点移除自定义标签，并在这些节点上测试应用。
暂停 MCP 应该谨慎考虑，且只在短时间内进行。
如果要使用 Canary rollout 更新过程，请参阅执行 Canary 推出部署更新。
3.2.7. 关于更新单个节点 OpenShift Container Platform
您可以使用控制台或 CLI 更新或升级单节点 OpenShift Container Platform 集群。
但请注意以下限制：
-
不需要暂停
MachineHealthCheck资源，因为没有其他节点可以执行健康检查。 - 不支持使用 etcd 备份来恢复单节点 OpenShift Container Platform 集群。但是，最好在升级失败时执行 etcd 备份。如果 control plane 健康，您可以使用备份将集群恢复到以前的状态。
更新单节点 OpenShift Container Platform 集群需要停机，并可包括自动重启。停机时间取决于更新有效负载，如下例所示：
- 如果更新有效负载包含操作系统更新（需要重启），则停机时间会非常显著，并影响集群管理和用户工作负载。
- 如果更新包含不需要重启的机器配置更改，则停机时间会减少，并且对集群管理和用户工作负载的影响会减少。在这种情况下，节点排空步骤会通过单节点 OpenShift Container Platform 跳过，因为集群中没有其他节点可以重新调度工作负载。
- 如果更新有效负载不包含操作系统更新或机器配置更改，则会出现简短的 API 中断并快速解决。
某些条件（如更新的软件包中的错误）可能会导致单个节点在重启后无法重启。在这种情况下，更新不会自动回滚。
