第 10 章 执行 canary rollout 更新
金丝雀更新是一种更新策略，其中 worker 节点更新以离散的、阶段阶段执行，而不是同时更新所有 worker 节点。这个策略在以下情况下很有用：
- 您需要一个受控的 worker 节点更新推出，以确保任务关键型应用程序在整个更新过程中仍然可用，即使更新过程会导致应用程序失败。
- 您需要更新一小部分 worker 节点，在一个时间段内评估集群和工作负载健康状况，然后更新剩余的节点。
- 您可能希望将通常需要主机重新引导的 worker 节点更新放入较小的定义的维护窗口（不可能一次使用大型维护窗口来更新整个集群）。
在这些情况下，您可以创建多个自定义机器配置池 (MCP)，以防止某些 worker 节点在更新集群时进行更新。在更新剩余的集群后，您可以在适当的时间批量更新这些 worker 节点。
10.1. 金丝雀更新策略示例
以下示例描述了一个金丝雀更新策略，其中有一个有 10% 的 100 个节点的集群，您有没有超过 4 小时的维护窗口，您知道排空并重启 worker 节点所需的时间不超过 8 分钟。
以上值是仅限示例。排空节点所需的时间可能会因工作负载等因素而异。
定义自定义机器配置池
要将 worker 节点的更新组织到不同的独立阶段，您可以从定义以下 MCP 开始：
- workerpool-canary，有 10 个节点
- workerpool-A，有 30 个节点
- workerpool-B，有 30 个节点
- workerpool-C，有 30 个节点
更新 Canary worker 池
在第一个维护窗口中，您将暂停 workerpool-A、workerpool-B 和 workerpool-C 的 MCP，然后启动集群更新。这将更新在 OpenShift Container Platform 上运行的组件，以及作为取消暂停的 workerpool-canary MCP 一部分的 10 个节点。其他三个 MCP 不会更新，因为它们已暂停。
确定是否继续剩余的 worker 池更新
如果出于某种原因，您确定集群或工作负载健康受到 workerpool-canary 更新的负面影响，那么在分析完问题前，您会在保持足够容量的同时，对那个池中的所有节点进行 cordon 和 drain 操作。当一切按预期工作时，您可以在决定取消暂停前评估集群和工作负载健康状况，从而更新 workerpool-A、workerpool-B 和 workerpool-C 在每个额外的维护窗口中连续工作。
使用自定义 MCP 管理 worker 节点更新提供了灵活性，但它可能是一个耗时的过程，需要您执行多个命令。这种复杂性可能会导致错误可能会影响整个集群。建议您仔细考虑您的组织需求，并在开始之前仔细规划流程的实施。
暂停机器配置池可防止 Machine Config Operator 在关联的节点上应用任何配置更改。暂停 MCP 还可以防止任何自动轮转的证书被推送到关联的节点，包括自动轮转 kube-apiserver-to-kubelet-signer CA 证书。
当 kube-apiserver-to-kubelet-signer CA 证书过期且 MCO 尝试自动更新证书时，MCO 无法将新轮转的证书推送到这些节点。这会导致多个 oc 命令失败，包括 oc debug、oc logs、oc exec 和 oc attach。如果在轮转证书时，如果 MCP 被暂停，则 OpenShift Container Platform Web 控制台的 Alerting UI 中收到警报。
在暂停 MCP 时应该非常小心，需要仔细考虑 kube-apiserver-to-kubelet-signer CA 证书过期的问题，且仅在短时间内暂停。
不建议将 MCP 更新至不同的 OpenShift Container Platform 版本。例如，请勿将一个 MCP 从 4.y.10 更新至 4.y.11，另一个更新为 4.y.12。这个场景还没有被测试，可能会导致未定义的集群状态。
