OpenShift 文档正在迁移，很快将仅在 docs.redhat.com（所有 Red Hat 产品文档的中心）提供。立即体验 新的文档体验。
  1. 文档
    2. history bug_report picture_as_pdf
×

使用 Web 控制台更新集群

您可以使用 Web 控制台对 OpenShift Container Platform 集群执行次要版本和补丁更新。

使用 Web 控制台或 `oc adm upgrade channel ` 来更改更新通道。更改为 4.17 通道后，您可以按照使用 CLI 更新集群中的步骤完成更新。

更新 OpenShift Container Platform 集群之前

更新前，请考虑以下事项

  • 您最近已备份 etcd。

  • 在 `PodDisruptionBudget` 中，如果 `minAvailable` 设置为 `1`，则会排空节点以应用可能阻止驱逐过程的挂起机器配置。如果重新启动多个节点，所有 Pod 都可能只在一个节点上运行，并且 `PodDisruptionBudget` 字段可以阻止节点排空。

  • 如果您的集群使用手动维护的凭据，则可能需要为新版本更新云提供商资源。

  • 您必须查看管理员确认请求，采取任何建议的操作，并在准备好时提供确认。

  • 您可以通过更新工作节点或自定义节点池来执行部分更新，以适应更新所需的时间。您可以在每个池的进度条中暂停和恢复。

  • 当更新未能完成时，集群版本操作员 (CVO) 会在尝试协调更新时报告任何阻塞组件的状态。不支持将集群回滚到以前的版本。如果更新未能完成，请联系 Red Hat 支持。

  • 使用 `unsupportedConfigOverrides` 部分修改操作员的配置不受支持，并可能阻止集群更新。您必须在更新集群之前删除此设置。

使用 Web 控制台更改更新服务器

更改更新服务器是可选的。如果您已安装并配置了本地 OpenShift Update Service (OSUS)，则必须将服务器的 URL 设置为 `upstream`，以便在更新期间使用本地服务器。

先决条件

  • 您可以使用 `cluster-admin` 权限访问集群。

  • 您可以访问 OpenShift Container Platform Web 控制台。

步骤

  1. 导航到**管理** → **集群设置**，单击**版本**。

  2. 单击**YAML** 选项卡，然后编辑 `upstream` 参数值

    示例输出
      ...
  spec:
    clusterID: db93436d-7b05-42cc-b856-43e11ad2d31a
    upstream: '<update-server-url>' (1)
  ...
    1 `` 变量指定更新服务器的 URL。

    默认 `upstream` 为 `https://api.openshift.com/api/upgrades_info/v1/graph`。

  3. 单击**保存**。

其他资源

使用 Web 控制台暂停 MachineHealthCheck 资源

在更新过程中，集群中的节点可能会暂时不可用。对于工作节点，机器健康检查可能会将此类节点识别为不健康并重新启动它们。为了避免重新启动此类节点，请在更新集群之前暂停所有 `MachineHealthCheck` 资源。

先决条件

  • 您可以使用 `cluster-admin` 权限访问集群。

  • 您可以访问 OpenShift Container Platform Web 控制台。

步骤

  1. 登录到 OpenShift Container Platform Web 控制台。

  2. 导航到**计算** → **MachineHealthChecks**。

  3. 要暂停机器健康检查，请将 `cluster.x-k8s.io/paused=""` 注释添加到每个 `MachineHealthCheck` 资源。例如，要将注释添加到 `machine-api-termination-handler` 资源，请完成以下步骤

    1. 单击 `machine-api-termination-handler` 旁边的选项菜单 kebab 并单击**编辑注释**。

    2. 在**编辑注释**对话框中，单击**添加更多**。

    3. 在**键**和**值**字段中，分别添加 `cluster.x-k8s.io/paused` 和 `""` 值，然后单击**保存**。

使用 Web 控制台更新集群

如果可用更新，您可以从 Web 控制台更新集群。

您可以在客户门户的勘误部分中找到有关可用的 OpenShift Container Platform 安全公告和更新的信息。

先决条件

  • 以具有 `cluster-admin` 权限的用户身份访问 Web 控制台。

  • 您可以访问 OpenShift Container Platform Web 控制台。

  • 暂停所有 `MachineHealthCheck` 资源。

  • 您已将之前通过 Operator Lifecycle Manager (OLM) 安装的所有 Operator 更新到与目标版本兼容的版本。更新 Operator 可确保在集群更新期间默认 OperatorHub 目录从当前次要版本切换到下一个次要版本时，它们具有有效的更新路径。有关如何检查兼容性以及如何在必要时更新已安装的 Operator 的更多信息，请参阅“其他资源”部分中的“更新已安装的 Operator”。

  • 您的机器配置池 (MCP) 正在运行且未暂停。在更新过程中会跳过与已暂停 MCP 关联的节点。如果您正在执行金丝雀发布更新策略，则可以暂停 MCP。

  • 您的 RHEL7 工作节点已替换为 RHEL8 或 RHCOS 工作节点。Red Hat 不支持 RHEL 工作节点的 RHEL7 原地升级到 RHEL8；这些主机必须使用干净的操作系统安装进行替换。

步骤

  1. 在 Web 控制台中，单击**管理** → **集群设置**，然后查看**详细信息**选项卡的内容。

  2. 对于生产集群，请确保**通道**设置为要更新到的版本的正确通道，例如stable-4.17。

    对于生产集群，您必须订阅stable-*、eus-*或fast-*通道。

    当您准备好切换到下一个次要版本时，请选择与该次要版本对应的通道。越早声明更新通道，集群就能越有效地为您的目标版本推荐更新路径。集群可能需要一些时间来评估所有可用的更新并提供最佳的更新建议供您选择。更新建议会随着时间的推移而变化，因为它们基于当时可用的更新选项。

    如果您看不到到目标次要版本的更新路径，请继续将集群更新到当前版本的最新补丁版本，直到下一个次要版本出现在路径中。

    • 如果**更新状态**不是**可用更新**，则无法更新集群。

    • **选择通道**指示集群正在运行或正在更新到的集群版本。

  3. 选择要更新到的版本，然后单击**保存**。

    输入通道**更新状态**更改为**正在更新到 **，您可以通过观察 Operator 和节点的进度条来查看集群更新的进度。

    如果您要将集群更新到下一个次要版本（例如，从 4.10 版更新到 4.11 版），请确认您的节点已更新，然后再部署依赖于新功能的工作负载。在**集群设置**页面上会显示任何包含尚未更新的工作节点的池。

  4. 更新完成后且集群版本 Operator 刷新了可用的更新后，请检查当前通道中是否有更多可用更新。

    • 如果有可用更新，请继续在当前通道中执行更新，直到无法再更新为止。

    • 如果没有可用更新，请将**通道**更改为下一个次要版本的stable-*、eus-*或fast-*通道，然后更新到您想要在该通道中使用的版本。

    您可能需要执行多个中间更新才能达到您想要的版本。

其他资源

在 Web 控制台中查看条件更新

您可以查看和评估与特定条件更新相关的风险。

先决条件

  • 您可以使用 `cluster-admin` 权限访问集群。

  • 您可以访问 OpenShift Container Platform Web 控制台。

  • 暂停所有 `MachineHealthCheck` 资源。

  • 您已将之前通过 Operator Lifecycle Manager (OLM) 安装的所有 Operator 更新到与目标版本兼容的版本。更新 Operator 可确保在集群更新期间默认 OperatorHub 目录从当前次要版本切换到下一个次要版本时，它们具有有效的更新路径。有关如何检查兼容性以及如何在必要时更新已安装的 Operator 的更多信息，请参阅“其他资源”部分中的“更新已安装的 Operator”。

  • 您的机器配置池 (MCP) 正在运行且未暂停。在更新过程中会跳过与已暂停 MCP 关联的节点。如果您正在执行高级更新策略（例如金丝雀发布、EUS 更新或控制平面更新），则可以暂停 MCP。

步骤

  1. 在 Web 控制台中，单击**管理** → **集群设置**页面，然后查看**详细信息**选项卡的内容。

  2. 您可以在**更新集群**模态的**选择新版本**下拉列表中启用包含已知问题版本功能，以使用条件更新填充下拉列表。

    如果选择了包含已知问题的版本，则会提供更多信息以及与该版本相关的潜在风险。

  3. 查看详细说明更新潜在风险的通知。

其他资源

执行金丝雀发布更新

在某些特定用例中，您可能需要一个更受控的更新过程，您不希望将特定节点与集群的其余部分同时更新。这些用例包括但不限于

  • 您有关键任务应用程序，您不希望在更新期间不可用。您可以在更新后分批缓慢地测试节点上的应用程序。

  • 您的维护窗口很短，不允许所有节点都更新，或者您有多个维护窗口。

滚动更新过程**不是**典型的更新工作流程。对于较大的集群，这可能是一个耗时的过程，需要您执行多个命令。这种复杂性可能导致影响整个集群的错误。建议您仔细考虑您的组织是否要使用滚动更新，并在开始之前仔细规划该过程的实施。

本主题中描述的滚动更新过程包括

  • 创建一个或多个自定义机器配置池 (MCP)。

  • 标记您不想立即更新的每个节点，以将这些节点移动到自定义 MCP。

  • 暂停这些自定义 MCP，这将阻止对这些节点的更新。

  • 执行集群更新。

  • 取消暂停一个自定义 MCP，这将触发对这些节点的更新。

  • 测试这些节点上的应用程序，以确保应用程序在这些新更新的节点上按预期工作。

  • 选择性地从剩余节点中分批删除自定义标签，并测试这些节点上的应用程序。

暂停 MCP 应谨慎进行，并且仅在短时间内进行。

如果您想使用金丝雀发布更新过程，请参阅执行金丝雀发布更新。

关于更新单节点 OpenShift Container Platform

您可以使用控制台或 CLI 更新或升级单节点 OpenShift Container Platform 集群。

但是，请注意以下限制

  • 暂停MachineHealthCheck资源的先决条件不需要，因为没有其他节点执行运行状况检查。

  • 使用 etcd 备份恢复单节点 OpenShift Container Platform 集群不受官方支持。但是，最好执行 etcd 备份，以防更新失败。如果您的控制平面处于运行状况良好状态，则可以使用备份将集群恢复到以前的状态。

  • 更新单节点 OpenShift Container Platform 集群需要停机，并且可能包括自动重启。停机时间取决于更新负载，如下面的场景所述。

    • 如果更新负载包含需要重启的操作系统更新，则停机时间较长，会影响集群管理和用户工作负载。

    • 如果更新包含不需要重启的机器配置更改，则停机时间较短，对集群管理和用户工作负载的影响较小。在这种情况下，由于集群中没有其他节点可以重新调度工作负载，因此会跳过单节点 OpenShift Container Platform 的节点驱逐步骤。

    • 如果更新负载不包含操作系统更新或机器配置更改，则会发生短暂的 API 中断，并会很快恢复。

某些情况下，例如更新包中的错误，可能导致单节点在重启后无法重新启动。在这种情况下，更新不会自动回滚。
其他资源