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

Source: CNCF Blog

发表于2026年2月9日
作者：Fabrizio Pandini，Broadcom

CNCF 项目在本文中的亮点

Cluster API 为 Kubernetes 集群生命周期引入声明式管理，使用户和平台团队能够定义集群的期望状态，并依赖控制器持续进行调和以实现该状态。

类似于在 Kubernetes 中使用 StatefulSets 或 Deployments 来管理一组 Pod，使用 Cluster API 时你可以：

• 使用 KubeadmControlPlane 来管理一组控制平面 Machines，或
• 使用 MachineDeployments 来管理一组工作节点 Nodes。

Cluster API v1.12.0 发行版扩展了 Cluster API 的功能，通过引入 就地更新（in‑place updates）和 链式升级（chained upgrades），降低了常见生命周期操作的摩擦。

对简洁性和可用性的强调

在 v1.12.0 中，Cluster API 项目再次展示了社区能够在为用户最小化影响的同时交付大量创新。

这在实际使用中意味着什么？

用户只需像以前的版本一样更改 Cluster 或 Machine 规范，Cluster API 将在可能且合适的情况下自动触发就地更新或链式升级。

Source: https://example.com/source-link

原位更新

就像 Kubernetes 对 Deployment 中的 Pod 所做的那样，当 Machine 规范发生变化时，Cluster API 通过 创建一个新的 Machine 并删除旧的 Machine 来执行滚动更新。

这种受不可变基础设施原则启发的方法具有以下几个优势：

• 简洁性 – 易于解释、可预测、一致且易于推理。
• 实现方式 – 仅依赖两个核心原语：创建 和 删除。
• 可移植性 – 不依赖于 Machine 的特定选择，例如操作系统或引导机制。

因此，Machine 的滚动更新大幅减少了在管理运行节点的主机服务器生命周期时需要考虑的变量数量。

虽然不可变性的好处显而易见，但 Kubernetes 和 Cluster API 正在演进，以便在可能的情况下 最小化工作负载中断。随着时间的推移，Cluster API 已引入多项对不可变滚动更新的改进，包括：

• 支持 仅对 Kubernetes 资源的更改进行原位传播——避免不必要的滚动更新。
• 提供一种 使用 PreferNoSchedule 污点标记过期节点 的方式，减少滚动更新期间的 Pod 抖动。
• 支持 先删除后创建的滚动更新策略，使不可变滚动更新在裸金属或资源受限的环境中更易实施。

Cluster API 中的新 原位更新 功能是此旅程的下一步。随着 v1.12.0 版本的发布，Cluster API 引入了对 更新扩展 的支持，允许用户在不删除并重新创建 Machine 的情况下对现有 Machine 进行原位修改。KubeadmControlPlane 和 MachineDeployments 均基于新的扩展支持原位更新，扩展了 Cluster API 的可能性。

原位更新是如何工作的？

1. 用户更改 Machine 的期望状态。
2. Cluster API 选择实现该状态的最佳工具——要么是不可变滚动更新，要么是原位更新扩展。

注意： 这不是不可变滚动更新与原位更新之间的竞争；Cluster API 会评估两种选项，并为给定的更改选择最合适的机制。

从维护者的角度来看，原位更新最适用于 不需要节点驱逐或 Pod 重启的更改（例如，在 Machine 上更新用户凭证）。当工作负载无论如何都会被中断时，仍然首选传统的滚动更新。

Cluster API 仍保持可扩展性——任何人都可以创建自己的更新扩展，并决定何时以及如何使用原位更新，以在需要时权衡不可变滚动更新的一些优势。

想要深入了解，请参加 KubeCon EU（阿姆斯特丹）上的会议 “In‑place Updates with Cluster API: The Sweet Spot Between Immutable and Mutable Infrastructure”：
In‑place Updates with Cluster API (KubeCon EU 2026)

Source: …

链式升级

ClusterClass 与 Cluster API 中的受管拓扑共同提供了一个强大的框架，作为许多提供 Kubernetes‑as‑a‑Service 平台的构建块。

现在在 v1.12… (原文在此结束)

此功能通过允许用户在一次操作中跨越多个 Kubernetes 小版本进行升级，标志着向前迈出重要一步，通常称为 链式升级。

用户无需手动管理每一次小版本升级，只需声明目标 Kubernetes 版本，Cluster API 即会安全地编排所需的中间步骤。

链式升级的工作原理

1. 触发更新 – 更改 Cluster 的期望版本。
2. 计算升级计划 – Cluster API 确定所需的中间版本。
3. 执行计划 – 按严格受控的顺序升级控制平面和工作节点机器，必要时重复该过程，直至达到期望状态。

例如，与其先将集群依次升级到 v1.33.0、再到 v1.34.0，最后到 v1.35.0，链式升级允许直接升级到 v1.35.0。

Cluster API 还会优化工作节点机器的升级步骤：只要符合 Kubernetes 版本倾斜策略，它们将跳过中间的 Kubernetes 小版本发布。

可扩展性

• 升级计划运行时扩展 – 影响升级计划的计算方式。参见 runtime SDK 文档。
• 生命周期钩子 – 自动化在升级期间必须运行的任务（例如，在控制平面更新后升级插件）。参见 生命周期钩子文档。

注意： 链式升级特别适用于倾向于不频繁升级（例如每年一次）并希望一次跨越多个版本（n‑3 → n）的用户。但一次性升级多个版本的能力 并不是 省略常规补丁的理由。

发布团队

我想感谢所有为发布团队志愿服务的贡献者、维护者和工程师。

Cluster API 发布的可靠性和可预测性——是用户最欣赏的特性之一——仅因社区的支持、承诺和辛勤工作而得以实现。

向整个 Cluster API 社区致敬，感谢 v1.12.0 版本以及 2025 年发布的所有精彩版本！

如果您有兴趣参与，请了解 Cluster API 贡献指南。

接下来是什么？

如果您阅读了 Cluster API manifesto，您会看到该子项目如何拥抱持续演进、改进以及对用户需求和更广泛 Cloud Native 生态系统变化的适应。

随着 Kubernetes 本身的演进，Cluster API 子项目也将同步前进，重点关注：

• 更安全的升级
• 减少中断
• 为大规模管理 Kubernetes 的平台提供更强大的构建块

创新始终是 Cluster API 的核心——敬请期待 2026 年期间的激动人心的新进展！

有用链接

• Cluster API
• Cluster API v1.12.0 发布
• 就地更新提案
• 链式升级提案
• 了解更多关于 VMware Cloud Foundation 的信息，这是一套统一的私有云平台，集成了计算、存储、网络、安全和管理。

此维护者博客最初发布在 kubernetes.io，经许可在此重新发布。