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 控制台。

流程

  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。

    默认 upstreamhttps://api.openshift.com/api/upgrades_info/v1/graph

  3. 点击 Save

3.2.3. 使用 Web 控制台暂停 MachineHealthCheck 资源

在更新过程中,集群中的节点可能会临时不可用。对于 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 资源,请完成以下步骤:

    1. machine-api-termination-handler 旁边的 Options 菜单 kebab 并点 Edit annotations
    2. Edit annotations 对话框中,点 Add more
    3. KeyValue 字段中,分别添加 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 的原位升级 ; 这些主机必须使用干净的操作系统安装替换。

流程

  1. 在 web 控制台中点击 Administration Cluster Settings 并查看 Details 选项卡中的内容。
  2. 对于生产环境中的集群,请确保将 Channel 设置为您要升级到的版本的正确频道,如 stable-4.16

    重要

    对于生产环境中的集群,您必须订阅一个 stable-*, eus-*fast-* 频道。

    注意

    当您准备好升级到下一个次版本时,请选择与该次版本对应的频道。声明更新频道后,集群可以更方便地为您的目标版本更新路径。集群可能需要一些时间来评估所有可用的更新,并提供最佳更新建议。更新建议可能会随时间变化,因为它们基于哪些更新选项。

    如果您无法看到到目标次版本的更新路径,请保持将集群更新至当前版本的最新补丁版本,直到下一个次版本在路径中可用。

    • 如果 Update 状态 不是 Updates available,则无法升级集群。
    • Select channel 表示集群正在运行或正在更新的集群版本。
  3. 选择要更新到的版本,然后单击 Save

    输入频道 Update Status 变为Update to <product-version> in progress,您可以通过监视 Operator 和节点的进度条来查看集群更新的进度。

    注意

    如果您要将集群升级到下一个次版本,例如从 4.10 升级到 4.11,请在部署依赖新功能的工作负载前确认您的节点已更新。任何尚未更新的 worker 节点池都会显示在 Cluster Settings 页面。

  4. 更新完成后,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。

流程

  1. 在 Web 控制台中,点 Administration Cluster settings 页面并查看 Details 选项卡的内容。
  2. 您可以在 更新集群 模态的 Select new version 下拉列表中启用 Include versions with known issues 功能以使下拉列表中包括有条件的更新。

    注意

    如果选择了具有已知问题的版本,则会提供与版本相关的潜在风险的更多信息。

  3. 查看通知详细描述了更新的潜在风险。

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 中断并快速解决。
重要

某些条件(如更新的软件包中的错误)可能会导致单个节点在重启后无法重启。在这种情况下,更新不会自动回滚。

Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

通过我们的产品和服务,以及可以信赖的内容,帮助红帽用户创新并实现他们的目标。

让开源更具包容性

红帽致力于替换我们的代码、文档和 Web 属性中存在问题的语言。欲了解更多详情,请参阅红帽博客.

關於紅帽

我们提供强化的解决方案,使企业能够更轻松地跨平台和环境(从核心数据中心到网络边缘)工作。

© 2024 Red Hat, Inc.