4.3. 集群更新阶段
在 OpenShift Container Platform 中，集群更新分为两个阶段：
- Cluster Version Operator (CVO) 目标更新有效负载部署
- Machine Config Operator (MCO) 节点更新
4.3.1. Cluster Version Operator 目标更新有效负载部署
Cluster Version Operator (CVO) 检索目标更新发行镜像并应用到集群。作为 pod 运行的所有组件都会在这个阶段更新，主机组件则由 Machine Config Operator (MCO) 更新。这个过程可能需要 60 到 120 分钟。
更新的 CVO 阶段不会重启节点。
其他资源
4.3.2. Machine Config Operator 节点更新
Machine Config Operator (MCO) 将新机器配置应用到每个 control plane 和计算节点。在此过程中，MCO 在集群的每个节点中执行以下操作：
- cordon 和 drain 所有节点
- 更新操作系统 (OS)
- 重新引导节点
- 取消协调所有节点并在节点上调度工作负载
当节点被封锁时，工作负载无法调度到其中。
完成此过程的时间取决于多个因素，包括节点和基础架构配置。此过程可能需要 5 分钟或更长时间来完成每个节点。
除了 MCO 外，您应该考虑以下参数的影响：
- control plane 节点更新持续时间是可预测的，通常比计算节点更短，因为 control plane 工作负载出于安全更新和快速排空进行了调优。
-
您可以通过将
maxUnavailable字段设置为在 Machine Config Pool (MCP) 中大于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，则该节点不可用，且这会影响更新持续时间。您可以通过展开 Compute
Nodes 从 web 控制台中的 Administrator 视角检查节点的状态。
