Cluster API v1.12: 原地更新与链式升级

概述

Cluster API 通过声明式管理方式，为 Kubernetes 集群的完整生命周期提供支持，允许平台团队定义集群的期望状态，并依靠控制器持续进行调和，确保实际状态与期望状态一致。类似于 Kubernetes 中使用 Deployment 或 StatefulSet 管理 Pod，Cluster API 使用 KubeadmControlPlane 管理控制面节点，使用 MachineDeployment 管理工作节点。在 SRE 实践中，安全、可控地管理大量集群的生命周期（如创建、更新、升级）是保障服务可靠性和运营效率的核心挑战。

Cluster API v1.12.0 的发布，引入了原地更新和链式升级两大特性，旨在减少常见生命周期操作中的摩擦，让用户和 SRE 团队能更轻松、更安全地管理 Kubernetes 集群。这些改进体现了项目在保持不可变基础设施原则优势的同时，持续降低工作负载中断的演进方向。

核心概念

原地更新 (In-Place Updates)

传统上，Cluster API（和 Kubernetes Deployment）采用不可变滚动更新策略：当机器的规格（Spec）发生变更时，会创建一台新的机器并销毁旧的机器，从而实现滚动发布。这种方法的优点在于简单、可预测且不依赖于机器的具体配置（如操作系统或启动机制）。

v1.12.0 引入的原地更新功能，扩展了这一模型。它允许用户在不删除和重建机器的情况下，对现有机器直接应用某些更改。Cluster API 控制器现在拥有了一个决策点：当检测到规格变更时，它会自动选择是采用传统的滚动更新（创建新机器），还是调用新的更新扩展（Update Extension）来在现有机器上原地执行更改。

选择哪种方式取决于变更的性质。Cluster API 的维护者建议，对于不会导致节点驱逐或 Pod 重启的变更（例如修改机器的用户凭证），使用原地更新更为合适；而对于必然会引起工作负载中断的变更，则继续使用滚动更新。

链式升级 (Chained Upgrades)

在 Kubernetes 的发布周期中，用户通常需要逐个次要版本（例如 1.32 -> 1.33 -> 1.34）进行升级。ClusterClass 和托管拓扑功能为 Kubernetes-as-a-Service 平台提供了强大的抽象。

v1.12.0 引入的链式升级功能，允许用户在一次操作中声明一个跨多个次要版本的目标版本（例如，从 1.32 直接升级到 1.35）。Cluster API 会负责安全地编排所需的中间升级步骤，自动计算升级计划并按正确的顺序（先控制面，后工作节点）执行。它还会根据 Kubernetes 版本偏差策略，尽可能优化工作节点的升级路径，可能跳过某些中间版本。

实践

对于集群操作者和 SRE 团队而言，这些新特性直接体现在更新 Kubernetes 资源定义上。

  1. 原地更新实践：

    • 确保你的 Cluster API 版本为 v1.12.0 或更高。
    • 对于需要原地更新的特定更改类型（如机器凭证更新），你需要实现或使用已有的更新扩展。
    • 当你修改 Machine 或 KubeadmControlPlane 的 .spec 时，Cluster API 会根据变更内容自动判断。如果变更适合原地更新且存在相应的扩展，它将执行原地更新而非滚动创建。
    • 该特性支持在 KubeadmControlPlane 和 MachineDeployment 上使用。

  2. 链式升级实践：

    • 此功能基于 ClusterClass 和托管拓扑。
    • 在声明集群资源的 YAML 文件中，将 .spec.topology.version 字段直接设置为你期望的最终 Kubernetes 版本（例如 v1.35.0），无需关心中间版本。
    • Cluster API 控制器将自动： a. 计算从当前版本到目标版本的最优升级计划（包括控制面和工作节点的顺序）。 b. 执行控制面升级（可能多次滚动）。 c. 按计划升级工作节点。
    • 你可以通过升级计划运行时扩展来定制升级计划的计算逻辑，或通过生命周期钩子在升级的特定阶段（如控制面升级完成后）执行自定义任务，例如升级集群插件。

SRE 要点

  • 与可靠性的关联：

    • 原地更新减少了因滚动更新而导致的不必要 Pod 重调度和节点驱逐，从而降低了升级期间的Pod 中断风险，提升了服务的可用性。
    • 链式升级将复杂的多版本升级过程自动化，减少了人工操作步骤和潜在的配置错误，使得大规模集群的版本演进更加安全、可预测。
    • 两者共同减少了集群生命周期管理的“操作摩擦”，使 SRE 团队能将精力更多地集中在架构优化和故障根治上。

  • 最佳实践与反模式：

    • 最佳实践：对于不涉及容器运行时或内核升级、不会影响工作负载的机器配置变更，优先考虑使用原地更新。将原地更新作为“轻量级”变更的工具，滚动更新作为“重量级”变更的工具。
    • 最佳实践：即使是链式升级提供了便利，也必须遵循 Kubernetes 的发布生命周期策略，及时应用补丁版本。不应因有链式升级能力就完全推迟所有次要版本的升级。
    • 反模式：将原地更新用于可能导致内核或容器运行时不兼容的底层变更，这可能超出扩展的处理能力，导致节点故障。
    • 反模式：忽略版本升级前的兼容性检查和混沌工程验证，完全依赖 Cluster API 的自动化流程。

  • 相关指标 (SLI/SLO/SLA)：

    • 监控集群升级耗时（从开始到目标版本完全就绪）。
    • 监控升级过程中的节点 NotReady 时长和Pod 重调度次数。
    • 可以将**“重大版本升级期间的服务错误率”**作为一个 SLI，并设定相应的 SLO，以确保升级过程不会显著影响用户体验。

  • 可观测性与事件响应：

    • 密切关注 Cluster API 控制器自身的日志和指标，以了解升级计划的制定与执行状态。
    • 为升级过程中的关键事件（如控制面升级开始/完成、工作节点批量升级开始）设置告警，便于事件响应和过程审计。