第 5 章 准备执行 EUS 更新

由于 Kubernetes 的设计，次版本之间的所有 OpenShift Container Platform 升级都必须按顺序进行。您必须从 OpenShift Container Platform 4.8 更新至 4.9，然后升级到 4.10。您无法直接从 OpenShift Container Platform 4.8 更新至 4.10。但是，从 OpenShift Container Platform 4.8 升级到 4.9 再升级到 4.10 开始，希望在两个延长更新支持(EUS)版本间升级的管理员可以进行这样的升级，非 master 主机只需要重启一次。

当尝试进行 EUS 到 EUS 更新时需要考虑很多注意事项。

  • EUS 到 EUS 更新仅在所有涉及的版本在 stable 频道中提供。
  • 如果您在升级到一个奇数次版本后但在升级到下一个偶数次版本前遇到了问题，则需要在继续进行前，把非控制平面主机完成升级到奇数次版本。
  • 您可以在多个维护窗口期间通过暂停中间步骤完成升级过程。但是，计划在 60 天内完成整个更新。确保完成正常的集群自动化过程非常重要，包括与证书轮转关联的操作。
  • 开始 EUS 到 EUS 升级过程前，您必须至少运行 OpenShift Container Platform 4.8.14。如果您没有满足这个最低要求，在尝试 EUS 升级到 EUS 前，升级到更新的 4.8.z。
  • OpenShift Container Platform 4.10 中删除了对 RHEL7 worker 的支持，并使用 RHEL8 worker 替代，因此使用 RHEL7 worker 的集群没有 EUS 到 EUS 的升级。
  • 节点组件没有更新至 OpenShift Container Platform 4.9。在完成升级到 OpenShift Container Platform 4.10 前，不要预期 OpenShift Container Platform 4.9 中修复的所有功能和错误都可用，并启用所有 MachineConfigPool 进行更新。
  • 所有集群可能会在不需要暂停池的情况下，对常规更新使用 EUS 频道进行更新，但只有具有非控制平面 MachineConfigPools 对象的集群可以进行 EUS 到 EUS 的更新，且需要暂停池。

5.1. EUS 到 EUS 更新

以下流程暂停所有非 master MachineConfigPools，并从 OpenShift Container Platform 4.8 升级到 4.9 再升级到 4.10，然后取消暂停之前暂停的 MachineConfigPool。以下过程减少了升级持续时间，以及重启 worker 节点的次数。

先决条件

  • 查看 OpenShift Container Platform 4.9 和 4.10 发行注记
  • 查阅有关任何层次产品和 OLM Operator 的发行注记和产品生命周期。有些操作可能需要在 EUS 到 EUS 更新之前或进行中进行。
  • 确保您熟悉了特定于版本的前提条件，如在从 OpenShift Container Platform 4.8 升级到 4.9 之前需要管理员进行确认。
  • 验证集群是否正在运行 OpenShift Container Platform 版本 4.8.14 或更高版本。如果您的集群运行早于 OpenShift Container Platform 4.8.14 的版本，则必须在升级到 4.9 前升级到更新的 4.8.z 版本。需要升级到 4.8.14 或更高版本，才能满足最低版本要求，且无需暂停 MachineConfigPool。
  • 验证 MachineConfigPools 是否已取消暂停。

流程

  1. 将任何 OLM Operator 升级到与您要升级到的版本兼容的版本。

  2. 验证所有 MachineConfigPools 均显示 UPDATED 状态，没有 MachineConfigPools 显示 UPDATING 状态。要查看所有 MachineConfigPools 的状态，请运行以下命令： 

    $ oc get mcp

    输出示例

    为清晰起见，输出已被修剪： 

    NAME     CONFIG                                         	UPDATED   UPDATING
master   rendered-master-ecbb9582781c1091e1c9f19d50cf836c       True  	  False
worker   rendered-worker-00a3f0c68ae94e747193156b491553d5       True  	  False

  3. 暂停您要跳过重启的 MachineConfigPools，运行以下命令：

    注意

    您无法暂停 master 池。 

    $ oc patch mcp/worker --type merge --patch '{"spec":{"paused":true}}'

  4. 切换到 eus-4.10 频道，运行以下命令： 

    $ oc adm upgrade channel eus-4.10

  5. 更新至 4.9，运行以下命令： 

    $ oc adm upgrade --to-latest

    输出示例

    Updating to latest version 4.9.18

  6. 运行以下命令，查看集群版本以确保更新已完成： 

    $ oc get clusterversion

    输出示例

    NAME  	  VERSION  AVAILABLE  PROGRESSING   SINCE   STATUS
version   4.9.18   True       False         6m29s   Cluster version is 4.9.18

  7. 如有必要，使用 web 控制台中的 Administrator 视角升级 OLM operator。

  8. 更新至 4.10，运行以下命令： 

    $ oc adm upgrade --to-latest

  9. 运行以下命令，查看集群版本以确保更新已完成： 

    $ oc get clusterversion

    输出示例

    NAME  	  VERSION  AVAILABLE  PROGRESSING   SINCE   STATUS
version   4.10.1   True       False         6m29s   Cluster version is 4.10.1

  10. 取消暂停所有之前暂停的 MachineConfigPools，运行以下命令： 

    $ oc patch mcp/worker --type merge --patch '{"spec":{"paused":false}}'
    注意

    如果没有取消暂停池，集群不允许升级到将来的次要维护任务，如证书轮转。这会使集群面临未来降级的风险。

  11. 验证之前暂停的池是否已更新，集群完成了更新到 4.10，运行以下命令： 

    $ oc get mcp

    输出示例

    为清晰起见，输出已被修剪： 

    NAME 	   CONFIG                                            UPDATED     UPDATING
master   rendered-master-52da4d2760807cb2b96a3402179a9a4c    True  	 False
worker   rendered-worker-4756f60eccae96fb9dcb4c392c69d497    True 	 False