10.2. 关于 Canary rollout 更新过程和 MCP

在 OpenShift Container Platform 中，节点不会被单独考虑。相反，它们被分组到机器配置池中 (MCP)。默认情况下，OpenShift Container Platform 集群中的节点分组到两个 MCP 中：一个用于 control plane 节点，一个用于 worker 节点。OpenShift Container Platform 更新会同时影响所有 MCP。

在更新过程中，如果指定了最大数字，Machine Config Operator (MCO) 会排空并封锁 MCP 中的最多为 maxUnavailable 中指定的数量的节点。默认情况下，maxUnavailable 设置为 1。排空节点取消调度节点上的所有 pod，并将该节点标记为不可调度。

节点排空后，Machine Config Daemon 应用一个新的机器配置，其中包括更新操作系统 (OS)。更新操作系统需要主机重新引导。

使用自定义机器配置池

要防止特定节点被更新，您可以创建自定义 MCP。因为 MCO 不会在暂停的 MCP 中更新节点，所以您可以在启动集群更新前暂停包含您不想更新的节点的 MCP。

使用一个或多个自定义 MCP 可以让您更好地控制您更新 worker 节点的顺序。例如，在更新第一个 MCP 中的节点后，您可以验证应用程序兼容性，然后逐步将其余节点更新至新版本。

使用自定义机器配置池时的注意事项

根据工作负载部署拓扑，请仔细考虑您创建的 MCP 数以及每个 MCP 中的节点数。例如，如果必须将更新适合特定的维护窗口，您必须了解在给定窗口中可以更新多少个节点 OpenShift Container Platform。这个数字取决于您具体的集群和工作负载特性。

您还必须考虑集群中有多少额外容量，以确定自定义 MCP 的数量以及每个 MCP 中的节点数。当应用程序无法在更新的节点上按预期工作时，您可以对池中那些节点进行 cordon 和 drain 操作，这会将应用 pod 移到其他节点上。但是，您必须确定剩余的 MCP 中的可用节点是否可以为您的应用程序提供足够的服务质量 (QoS)。