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 中断并快速解决。
某些条件(如更新的软件包中的错误)可能会导致单个节点在重启后无法重启。在这种情况下,更新不会自动回滚。