Cluster API v1.12：引入就地更新和链式升级
Cluster API 为 Kubernetes 集群生命周期带来了声明式管理， 允许用户和平台团队定义集群的期望状态，并依靠控制器持续协调以达到该状态。
类似于在 Kubernetes 中使用 StatefulSet 或 Deployment 管理一组 Pod， 在 Cluster API 中，你可以使用 KubeadmControlPlane 来管理一组控制平面 Machine， 或者使用 MachineDeployment 管理一组工作节点。
Cluster API v1.12.0 版本扩展了 Cluster API 的能力范围， 通过引入就地更新和链式升级减少了常见生命周期操作的摩擦。
强调简单性和可用性
通过 v1.12.0，Cluster API 项目再次证明这个社区能够提供大量创新， 同时最大程度地减少对 Cluster API 用户的影响。
这在实践中意味着什么？
用户只需更改 Cluster 或 Machine 的规约（与之前的 Cluster API 版本一样），Cluster API 会在可能且合适的情况下自动触发就地更新或链式升级。
就地更新
就像 Kubernetes 对 Deployment 中的 Pod 所做的那样， 当 Machine 的规约更改时，Cluster API 也通过创建新 Machine 并删除旧 Machine 来执行滚动更新。
这种方法受不可变基础设施原则的启发，具有一系列显著优势：
- 易于解释、可预测、一致，且用户和工程师易于理解。
- 实现简单，因为它只依赖两个核心原语：创建和删除。
- 实现不依赖于 Machine 特定的选择，如操作系统、引导机制等。
因此，Machine 滚动更新大大减少了管理承载节点的主机服务器生命周期时需要考虑的变量数量。
然而，虽然不可变性的优势毋庸置疑，但 Kubernetes 和 Cluster API 都在经历类似的历程，引入更改以允许用户尽可能减少工作负载中断。
随着时间的推移，Cluster API 也对不可变滚动更新引入了多项改进，包括：
- 支持仅影响 Kubernetes 资源的就地变更传播， 从而避免不必要的滚动更新
- 一种使用 PreferNoSchedule 污染过时节点的方法， 通过优化滚动更新期间 Pod 的重新调度方式来减少 Pod 更替。
- 支持先删除后创建的滚动更新策略， 从而更容易在裸金属/资源受限环境中执行不可变滚动更新。
Cluster API 中的新就地更新 特性是这一历程的下一步。
在 v1.12.0 版本中，Cluster API 引入了对更新扩展的支持， 允许用户在现有机器上就地进行更改，而无需删除和重新创建 Machine。
KubeadmControlPlane 和 MachineDeployments 都基于新的更新扩展支持就地更新， 这意味着 Cluster API 的能力边界现在发生了重大变化。
就地更新如何工作？
最简单的解释是，一旦用户通过更改 Machine 的期望状态触发更新， Cluster API 会选择最佳工具来实现期望状态。
现在的新消息是，Cluster API 可以在不可变滚动更新和就地更新扩展之间选择来执行所需的更改。
重要的是，这不是不可变滚动更新与就地更新的对立； Cluster API 认为两者都是有效的选项，并为给定的更改选择最合适的机制。
从 Cluster API 维护者的角度来看，就地更新最适用于不需要节点排空或 Pod 重启的更改； 例如：更改 Machine 的用户凭证。另一方面，当工作负载无论如何都会中断时，只需执行滚动更新。
尽管如此，Cluster API 仍然保持其可扩展的特性，每个人都可以创建自己的更新扩展， 并通过权衡不可变滚动更新的一些好处来决定何时以及如何使用就地更新。
要深入了解此功能，请务必参加阿姆斯特丹 KubeCon EU 的会议使用 Cluster API 进行就地更新：不可变基础架构和可变基础架构之间的最佳平衡点！
链式升级
ClusterClass 和 Cluster API 中的托管拓扑共同提供了一个强大而有效的框架， 作为许多提供 Kubernetes-as-a-Service 的平台的基础组件。
现在在 v1.12.0 中，此功能向前迈出了重要一步， 允许用户在单个操作中升级多个 Kubernetes 次要版本， 通常称为链式升级。
这允许用户声明目标 Kubernetes 版本，并让 Cluster API 安全地编排所需的中间步骤， 而不是手动管理每个次要版本升级。
最简单的解释链式升级如何工作的方式是，一旦用户通过更改 Cluster 的期望版本触发更新， Cluster API 会计算升级计划，然后开始执行它。例如，不需要先将 Cluster 更新到 v1.33.0， 然后 v1.34.0，然后 v1.35.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 宣言， 你可以看到 Cluster API 子项目如何声称保持未完成状态的权利， 认识到需要不断演进、改进并适应 Cluster API 用户和更广泛的云原生生态系统不断变化的需求。
随着 Kubernetes 本身的不断发展，Cluster API 子项目将与其一起前进， 专注于更安全的升级、减少中断以及为大规模管理 Kubernetes 的平台提供更强大的构建块。
创新仍然是 Cluster API 的核心，敬请期待激动人心的 2026 年！
有用链接：