第 7 章 执行 canary rollout 更新
有些情况下，您可能希望对 worker 节点进行更多受控的更新推出，以确保任务关键型应用程序在更新过程中仍然可用，即使更新过程导致您的应用程序失败。根据您的机构需求，您可能需要更新一小部分 worker 节点，在一个时间段内评估集群和工作负载健康状况，然后更新剩余的节点。这通常被称为 Canary 更新。或者，您可能还希望将通常需要主机重新引导的 worker 节点更新放入较小的定义的维护窗口（不可能一次使用大型维护窗口来更新整个集群）。
在这些情况下，您可以创建多个自定义机器配置池 (MCP)，以防止某些 worker 节点在更新集群时进行更新。在更新剩余的集群后，您可以在适当的时间批量更新这些 worker 节点。
例如，如果您的集群有 100 个节点，且有 10% 过量的容量，维护窗口不能超过 4 小时，并且您知道排空和重新引导 worker 节点的时间不超过 8 分钟，您可以利用 MCP 来实现您的目标。例如，您可以定义四个 MCP，分别名为 workerpool-canary、workerpool-A、workerpool-B 和 workerpool-C，分别有 10、30、30 和 30 个节点。
在第一次维护窗口中，您将暂停 workerpool-A、workerpool-B 和 workerpool-C 的 MCP，然后启动集群更新。这会更新在 OpenShift Container Platform 上运行的组件，以及属于 workerpool-canary MCP 成员的 10 个节点，因为这个池没有暂停。其他三个 MCP 不会更新，因为它们已暂停。如果出于某种原因，您确定集群或工作负载健康受到 workerpool-canary 更新的负面影响，那么在分析完问题前，您会在保持足够容量的同时，对那个池中的所有节点进行 cordon 和 drain 操作。当一切正常时，您将在决定取消暂停前评估集群和工作负载健康状况，从而在每个额外的维护窗口中持续更新 workerpool-A、workerpool-B 和 workerpool-C。
使用自定义 MCP 管理 worker 节点更新提供了灵活性，这可能是一个耗时的过程，需要您执行多个命令。这种复杂性可能会导致出现可能会影响整个集群的错误。建议您仔细考虑您的组织需求，并在开始之前仔细规划流程的实施。
不建议将 MCP 更新至不同的 OpenShift Container Platform 版本。例如，请勿将一个 MCP 从 4.y.10 更新至 4.y.11，另一个更新为 4.y.12。这个场景还没有被测试，可能会导致未定义的集群状态。
暂停机器配置池可防止 Machine Config Operator 在关联的节点上应用任何配置更改。暂停 MCP 还可以防止任何自动轮转的证书被推送到关联的节点，包括自动轮转 kube-apiserver-to-kubelet-signer CA 证书。如果 kube-apiserver-to-kubelet-signer CA 证书过期且 MCO 尝试自动更新证书时，MCP 会暂停，但不会在相应机器配置池中的节点中应用新证书。这会导致多个 oc 命令失败，包括但不限于 oc debug、oc logs、oc exec 和 oc attach。在暂停 MCP 时应该非常小心，需要仔细考虑 kube-apiserver-to-kubelet-signer CA 证书过期的问题，且仅在短时间内暂停。
7.1. 关于 Canary rollout 更新过程和 MCP
在 OpenShift Container Platform 中，节点不会被单独考虑。节点分组到机器配置池中 (MCP)。默认 OpenShift Container Platform 集群中有两个 MCP：一个用于 control plane 节点，一个用于 worker 节点。OpenShift Container Platform 更新会同时影响所有 MCP。
在更新过程中，Machine Config Operator (MCO) 会排空并记录 MCP 中的所有节点，直至指定的 maxUnavailable 数量（如果指定），默认为 1。排空节点取消调度节点上的所有 pod，并将该节点标记为不可调度。节点排空后，Machine Config Daemon 应用一个新的机器配置，其中包括更新操作系统 (OS)。更新操作系统需要主机重新引导。
要防止特定节点被更新，且不会排空、进行 cordoned 和更新，您可以创建自定义 MCP。然后，暂停这些 MCP，以确保不更新与这些 MCP 关联的节点。MCO 不会更新任何暂停的 MCP。您可以创建一个或多个自定义 MCP，这样可以让您更好地控制您更新这些节点的顺序。更新第一个 MCP 中的节点后，您可以验证应用兼容性，然后逐步将其余节点更新至新版本。
为确保 control plane 的稳定性，不支持从 control plane 节点（也称为 master 节点）创建自定义 MCP。Machine Config Operator (MCO) 会忽略为 control plane 节点创建的任何自定义 MCP。
根据工作负载部署拓扑，您应该仔细考虑您创建的 MCP 数以及每个 MCP 中的节点数量。例如，如果需要将更新融入特定的维护窗口，您需要知道 OpenShift Container Platform 可在窗口中更新的节点数量。这个数字取决于您具体的集群和工作负载特性。
另外，您需要考虑集群中可用的额外容量量。例如，当应用程序无法在更新的节点上按预期工作时，您可以对池中那些节点进行 cordon 和 drain 操作，这会将应用 pod 移到其他节点上。您需要考虑您可用的额外容量数量，以确定您需要的自定义 MCP 数量以及每个 MCP 中有多少节点。例如，如果您使用两个自定义 MCP 和 50% 的节点在每个池中，则需要确定运行 50% 的节点是否能为您的应用程序提供足够的服务质量(QoS)。
您可以将这个更新过程与所有记录的 OpenShift Container Platform 更新过程一起使用。但是，该过程不适用于使用 Ansible playbook 进行更新的 Red Hat Enterprise Linux (RHEL) 机器。
