搜索

第 10 章 执行 canary rollout 更新

download PDF

金丝雀更新是一种更新策略,其中 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-Aworkerpool-Bworkerpool-C 的 MCP,然后启动集群更新。这将更新在 OpenShift Container Platform 上运行的组件,以及作为取消暂停的 workerpool-canary MCP 一部分的 10 个节点。其他三个 MCP 不会更新,因为它们已暂停。

确定是否继续剩余的 worker 池更新

如果出于某种原因,您确定集群或工作负载健康受到 workerpool-canary 更新的负面影响,那么在分析完问题前,您会在保持足够容量的同时,对那个池中的所有节点进行 cordon 和 drain 操作。当一切按预期工作时,您可以在决定取消暂停前评估集群和工作负载健康状况,从而更新 workerpool-Aworkerpool-Bworkerpool-C 在每个额外的维护窗口中连续工作。

使用自定义 MCP 管理 worker 节点更新提供了灵活性,但它可能是一个耗时的过程,需要您执行多个命令。这种复杂性可能会导致错误可能会影响整个集群。建议您仔细考虑您的组织需求,并在开始之前仔细规划流程的实施。

重要

暂停机器配置池可防止 Machine Config Operator 在关联的节点上应用任何配置更改。暂停 MCP 还可以防止任何自动轮转的证书被推送到关联的节点,包括自动轮转 kube-apiserver-to-kubelet-signer CA 证书。

kube-apiserver-to-kubelet-signer CA 证书过期且 MCO 尝试自动更新证书时,MCO 无法将新轮转的证书推送到这些节点。这会导致多个 oc 命令失败,包括 oc debugoc logsoc execoc 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。这个场景还没有被测试,可能会导致未定义的集群状态。

Red Hat logoGithubRedditYoutubeTwitter

学习

尝试、购买和销售

社区

关于红帽文档

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

让开源更具包容性

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

關於紅帽

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

© 2024 Red Hat, Inc.