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

了解 OpenShift Container Platform 更新持续时间

OpenShift Container Platform 更新持续时间因部署拓扑而异。此页面可帮助您了解影响更新持续时间的因素，并估算集群更新在您的环境中需要多长时间。

影响更新持续时间的因素

以下因素会影响集群更新持续时间

  • 机器配置运算符 (MCO) 将计算节点重新引导到新的机器配置

    • 机器配置池中MaxUnavailable的值

      maxUnavailable的默认设置为OpenShift Container Platform中所有机器配置池的1。建议不要更改此值，并一次更新一个控制平面节点。不要将此值更改为控制平面池的3。

    • 在 Pod disruption budget (PDB) 中设置的最小副本数或百分比

  • 集群中的节点数量

  • 集群节点的运行状况

集群更新阶段

在 OpenShift Container Platform 中，集群更新分为两个阶段

  • 集群版本运算符 (CVO) 目标更新有效负载部署

  • 机器配置运算符 (MCO) 节点更新

集群版本运算符目标更新有效负载部署

集群版本操作符 (CVO) 获取目标更新发行版镜像并将其应用于集群。此阶段将更新所有以 Pod 形式运行的组件，而主机组件则由机器配置操作符 (MCO) 更新。此过程可能需要 60 到 120 分钟。

更新的 CVO 阶段不会重启节点。

机器配置操作符节点更新

机器配置操作符 (MCO) 将新的机器配置应用于每个控制平面和计算节点。在此过程中，MCO 对集群的每个节点执行以下顺序操作：

  1. 隔离并驱逐所有节点

  2. 更新操作系统 (OS)

  3. 重启节点

  4. 取消隔离所有节点并在节点上调度工作负载。

隔离节点后，无法在其上调度工作负载。

完成此过程所需的时间取决于多个因素，包括节点和基础设施配置。此过程每个节点可能需要 5 分钟或更长时间才能完成。

除了 MCO 之外，还应考虑以下参数的影响：

  • 控制平面节点更新持续时间是可预测的，并且通常短于计算节点，因为控制平面工作负载经过调整，可以实现优雅更新和快速驱逐。

  • 可以通过将机器配置池 (MCP) 中的maxUnavailable字段设置为大于1来并行更新计算节点。MCO 隔离maxUnavailable中指定数量的节点，并将其标记为不可用于更新。

  • 增加 MCP 上的maxUnavailable可以帮助池更快地更新。但是，如果maxUnavailable设置过高，并且同时隔离多个节点，则由于找不到可调度的节点来运行副本，因此 Pod 中断预算 (PDB) 保护的工作负载可能会无法驱逐。如果增加 MCP 的maxUnavailable，请确保仍然有足够的可调度节点来允许 PDB 保护的工作负载驱逐。

  • 在开始更新之前，必须确保所有节点都可用。任何不可用的节点都会严重影响更新持续时间，因为节点不可用会影响maxUnavailable和 Pod 中断预算。

    要从终端检查节点状态，请运行以下命令：

    $ oc get node
    示例输出
    NAME                                        STATUS                      ROLES   AGE     VERSION
ip-10-0-137-31.us-east-2.compute.internal   Ready,SchedulingDisabled    worker  12d     v1.23.5+3afdacb
ip-10-0-151-208.us-east-2.compute.internal  Ready                       master  12d     v1.23.5+3afdacb
ip-10-0-176-138.us-east-2.compute.internal  Ready                       master  12d     v1.23.5+3afdacb
ip-10-0-183-194.us-east-2.compute.internal  Ready                       worker  12d     v1.23.5+3afdacb
ip-10-0-204-102.us-east-2.compute.internal  Ready                       master  12d     v1.23.5+3afdacb
ip-10-0-207-224.us-east-2.compute.internal  Ready                       worker  12d     v1.23.5+3afdacb

    如果节点的状态为NotReady或SchedulingDisabled，则该节点不可用，这会影响更新持续时间。

    可以通过在 Web 控制台中扩展**计算** → **节点**来从**管理员**角度检查节点状态。

其他资源

集群操作符的示例更新持续时间

A diagram displaying the periods during which cluster Operators update themselves during an OCP update

上图显示了集群操作符更新到其新版本可能花费的时间示例。该示例基于一个三节点 AWS OVN 集群，该集群具有健康的计算MachineConfigPool，并且没有需要长时间驱逐的工作负载，从 4.13 更新到 4.14。

  • 集群及其操作符的具体更新持续时间会根据多个集群特性而有所不同，例如目标版本、节点数量以及调度到节点的工作负载类型。

  • 某些操作符（例如集群版本操作符）会在很短的时间内自行更新。这些操作符要么已从图表中省略，要么包含在标记为“其他并行操作符”的操作符的更广泛组中。

每个集群操作符都具有影响其自身更新时间的特性。例如，此示例中的 Kube API 服务器操作符花费了超过 11 分钟的时间进行更新，因为kube-apiserver提供优雅终止支持，这意味着允许现有活动请求优雅地完成。这可能会导致kube-apiserver关闭时间更长。对于此操作符，为了帮助防止和限制更新期间对集群功能的中断，牺牲了更新速度。

另一个影响操作符更新持续时间的特性是操作符是否使用 DaemonSet。网络和 DNS 操作符使用全集群 DaemonSet，这可能需要时间才能推出其版本更改，这是这些操作符自身更新可能需要更长时间的几个原因之一。

某些操作符的更新持续时间很大程度上取决于集群本身的特性。例如，机器配置操作符更新会将机器配置更改应用于集群中的每个节点。与节点较少的集群相比，节点较多的集群的机器配置操作符更新持续时间更长。

每个集群操作符都被分配一个可以更新的阶段。同一阶段的操作符可以同时更新，并且给定阶段的操作符只有在所有先前阶段都完成后才能开始更新。有关更多信息，请参阅“其他资源”部分中的“了解更新期间如何应用清单”。
其他资源

估算集群更新时间

类似集群的历史更新持续时间为您提供了未来集群更新的最佳估计。但是，如果历史数据不可用，则可以使用以下约定来估算集群更新时间：

Cluster update time = CVO target update payload deployment time + (# node update iterations x MCO node update time)

节点更新迭代包括一个或多个并行更新的节点。控制平面节点始终与计算节点并行更新。此外，根据maxUnavailable值，可以并行更新一个或多个计算节点。

maxUnavailable的默认设置为OpenShift Container Platform中所有机器配置池的1。建议不要更改此值，并一次更新一个控制平面节点。不要将此值更改为控制平面池的3。

例如，要估算更新时间，请考虑一个具有三个控制平面节点和六个计算节点的 OpenShift Container Platform 集群，每个主机大约需要 5 分钟才能重新启动。

重新启动特定节点所需的时间差异很大。在云实例中，重新启动可能需要大约 1 到 2 分钟，而在物理裸机主机中，重新启动可能需要超过 15 分钟。
方案 1

当您为控制平面和计算节点机器配置池 (MCP) 将maxUnavailable设置为1时，所有六个计算节点都将一个接一个地在每次迭代中更新。

Cluster update time = 60 + (6 x 5) = 90 minutes
方案 2

当您为计算节点 MCP 将maxUnavailable设置为2时，则每次迭代将并行更新两个计算节点。因此，更新所有节点总共需要三个迭代。

Cluster update time = 60 + (3 x 5) = 75 minutes

OpenShift Container Platform 中所有 MCP 的maxUnavailable默认设置为1。建议不要更改控制平面 MCP 中的maxUnavailable。

Red Hat Enterprise Linux (RHEL) 计算节点

Red Hat Enterprise Linux (RHEL) 计算节点需要额外使用openshift-ansible来更新节点二进制组件。更新 RHEL 计算节点实际花费的时间与更新 Red Hat Enterprise Linux CoreOS (RHCOS) 计算节点的时间差异不应显著。

其他资源

更多资源