Cluster API v1.12：引入原地更新和链式升级

Cluster API 为 Kubernetes 集群生命周期带来声明式管理，使用户和平台团队能够定义集群的期望状态，并依靠控制器持续协调以趋近该状态。

类似于你可以在 Kubernetes 中使用 StatefulSets 或 Deployments 来管理一组 Pods，在 Cluster API 中，你可以使用 KubeadmControlPlane 管理一组控制平面 Machines，或使用 MachineDeployments 管理一组工作节点。

Cluster API v1.12.0 版本扩展了 Cluster API 的能力，通过引入原地更新和链式升级，降低常见生命周期操作中的摩擦。

强调简洁性和可用性

在 v1.12.0 中，Cluster API 项目再次表明，该社区有能力交付大量创新，同时尽量减少对 Cluster API 用户的影响。

这在实践中意味着什么？

用户只需更改 Cluster 或 Machine 规范（与之前的 Cluster API 版本一样），Cluster API 就会在可能且适当时自动触发原地更新或链式升级。

原地更新

就像 Kubernetes 对 Deployments 中的 Pods 所做的那样，当 Machine 规范发生变化时，Cluster API 也会通过创建新的 Machine 并删除旧的 Machine 来执行滚动发布。

这种受不可变基础设施原则启发的方法具有一系列显著优势：

• 它易于解释、可预测、一致，并且便于用户和工程师理解与推理。
• 它易于实现，因为只依赖创建和删除这两个核心原语。
• 实现不依赖于 Machine 特定的选择，例如操作系统、引导机制等。

因此，在管理托管 Nodes 的主机服务器生命周期时，Machine 滚动发布大幅减少了需要考虑的变量数量。

然而，尽管不可变性的优势并无争议，Kubernetes 和 Cluster API 都在经历类似的发展过程，引入一些变更，使用户能够在可能时尽量减少工作负载中断。

随着时间推移，Cluster API 也为不可变滚动发布引入了多项改进，包括：

• 支持仅影响 Kubernetes 资源的变更进行原地传播，从而避免不必要的滚动发布
• 提供一种用 PreferNoSchedule 为过时节点打上 Taint 的方式，通过优化滚动发布期间 Pods 的重新调度方式来减少 Pod 变动。
• 支持先删除的滚动发布策略，从而使在裸金属/资源受限环境中执行不可变滚动发布变得更容易。

Cluster API 中新的原地更新功能是这一进程的下一步。

在 v1.12.0 版本中，Cluster API 引入了对更新扩展的支持，使用户能够在现有 machines 上原地进行更改，而无需删除并重新创建 Machines。

KubeadmControlPlane 和 MachineDeployments 均基于新的更新扩展支持原地更新，这意味着 Cluster API 中可实现能力的边界如今发生了显著变化。

原地更新如何工作？

最简单的解释是，一旦用户通过更改 Machines 的期望状态触发更新，Cluster API 就会选择实现该期望状态的最佳工具。

新的变化在于，现在 Cluster API 可以在不可变滚动发布和原地更新扩展之间进行选择，以执行所需更改。

重要的是，这并不是不可变滚动发布与原地更新的对立；Cluster API 将两者都视为有效选项，并会为给定变更选择最合适的机制。

从 Cluster API 维护者的角度看，原地更新最适合用于进行那些通常不需要节点腾空或 Pod 重启的变更；例如：更改 Machine 的用户凭据。另一方面，当工作负载无论如何都会被中断时，直接执行滚动发布即可。

尽管如此，Cluster API 仍然忠于其可扩展的本质，任何人都可以创建自己的更新扩展，并通过权衡放弃不可变滚动发布的部分收益，来决定何时以及如何使用原地更新。

如需深入了解此功能，请务必参加在阿姆斯特丹 KubeCon EU 举办的 In-place Updates with Cluster API: The Sweet Spot Between Immutable and Mutable Infrastructure 专场！

链式升级

Cluster API 中的 ClusterClass 和托管拓扑共同提供了一个强大且有效的框架，可作为许多提供 Kubernetes-as-a-Service 平台的构建模块。

现在，在 v1.12.0 中，该功能又迈出了重要一步，允许用户在一次操作中跨越多个 Kubernetes 次版本进行升级，通常称为链式升级。

这使用户能够声明目标 Kubernetes 版本，并让 Cluster API 安全地编排所需的中间步骤，而不是手动管理每一次次版本升级。

解释链式升级工作方式的最简单方法是：一旦用户通过更改 Cluster 的期望版本触发更新，Cluster API 就会计算升级计划，然后开始执行该计划。链式升级让你可以直接升级到 v1.35.0，而不是（例如）先将 Cluster 更新到 v1.33.0，再到 v1.34.0，再到 v1.35.0，并在每一步检查进度。

执行升级计划意味着以严格受控的顺序升级控制平面和工作机器，并根据达到期望状态所需的次数重复此过程。Cluster API 现在能够为你管理这一过程。

Cluster API 会负责优化并尽量减少工作机器的升级步骤，事实上，只要 Kubernetes 版本偏差策略允许，工作机器就会跳过中间 Kubernetes 次版本的升级。

在这种情况下，可扩展性同样是该功能的核心；升级计划运行时扩展可用于影响升级计划的计算方式；类似地，生命周期钩子可用于自动化升级期间必须执行的其他任务，例如在控制平面更新完成后升级插件。

从我们的角度看，链式升级最适合那些难以及时跟进 Kubernetes 次版本发布的用户，例如他们希望每年只升级一次，然后一次跨越三个版本（n-3 → n）。但请注意：现在可以轻松跨越多个次版本升级，并不意味着你可以不频繁为集群打补丁！

发布团队

我想感谢所有贡献者、维护者，以及所有自愿加入发布团队的工程师。

Cluster API 发布的可靠性和可预测性是用户最赞赏的特性之一，而这只有在社区的支持、投入和辛勤工作下才成为可能。

向整个 Cluster API 社区致敬，感谢 v1.12.0 版本以及 2025 年交付的所有出色版本！如果你有兴趣参与，请了解 Cluster API 贡献指南。

下一步是什么？

如果你阅读 Cluster API manifesto，就会看到 Cluster API 子项目主张保留未完成的权利，承认需要持续演进、改进并适应 Cluster API 用户和更广泛 Cloud Native 生态系统不断变化的需求。

随着 Kubernetes 本身持续演进，Cluster API 子项目也将与之同步推进，重点关注更安全的升级、更少的中断，以及为大规模管理 Kubernetes 的平台提供更强大的构建模块。

创新仍然是 Cluster API 的核心，敬请期待精彩的 2026 年！

实用链接：

• 正文：Cluster API
• Cluster API v1.12.0 版本
• 原地更新提案
• 链式升级提案

• ← 上一篇
• 下一篇 →