4.4. 估算集群更新时间


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

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

节点更新迭代由并行更新的一个或多个节点组成。control plane 节点总会与计算节点并行更新。另外,根据 maxUnavailable 值可以并行更新一个或多个计算节点。

警告

对于 OpenShift Container Platform 中的所有机器配置池,maxUnavailable 的默认设置是 1。建议您不要更改这个值,且一次只更新一个 control plane 节点。对于 control plane 池,请不要将这个值改为 3

例如,要估算更新时间,请考虑一个具有三个 control plane 节点的 OpenShift Container Platform 集群,以及每个主机需要大约 5 分钟才能重启。

注意

重启特定节点所需的时间有很大不同。在云实例中,重新启动可能需要大约 1 到 2 分钟,而在物理主机中,重新引导可能需要超过 15 分钟。

场景 1

当您将 control plane 和计算节点机器配置池 (MCP) 的 maxUnavailable 设置为 1 时,所有 6 个计算节点会在每个迭代中逐一进行更新。

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。建议您不要更改 control plane MCP 中的 maxUnavailable

Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

© 2024 Red Hat, Inc.