2. CAPI 核心概念回顾

在深入多集群发布流水线与回滚策略之前，必须重新校准对 Cluster API (CAPI) 核心资源模型的理解。CAPI 的本质是使用 Kubernetes 原生声明式 API 来管理 Kubernetes 集群的生命周期。其核心抽象围绕“集群是什么”以及“集群如何被构建”展开，主要由以下七个关键概念构成。

2.1 核心资源模型总览

CAPI 将物理/虚拟集群的拓扑结构映射为一组 Kubernetes 自定义资源 (CRD)。这些资源通过控制器协作，最终达到用户定义的期望状态。下表总结了每个核心资源的职责与层级关系：

2.2 资源关系与生命周期

下图展示了 CAPI 核心资源之间的依赖与所有权关系。注意 MachineDeployment 与 MachineSet 的层级关系，以及 Cluster 如何作为顶层协调者。

2.3 核心概念深度解析

2.3.1 Cluster — 聚合根

Cluster 对象是整个 CAPI 体系的入口。它不直接管理节点，而是通过 spec.controlPlaneRef 和 spec.infrastructureRef 将控制面与基础设施的创建委托给专门的 Provider。Cluster 控制器负责协调这两个子资源的就绪状态，并在两者都就绪后更新 Cluster 的 status.controlPlaneReady 和 status.infrastructureReady 字段。

apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
metadata:
  name: prod-cluster-01
spec:
  clusterNetwork:
    pods:
      cidrBlocks: ["10.96.0.0/12"]
    services:
      cidrBlocks: ["10.32.0.0/16"]
  controlPlaneRef:
    apiVersion: controlplane.cluster.x-k8s.io/v1beta1
    kind: KubeadmControlPlane
    name: prod-cluster-01-cp
  infrastructureRef:
    apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
    kind: AWSCluster
    name: prod-cluster-01-aws

2.3.2 Machine — 节点原子单元

Machine 是 CAPI 中最底层的计算资源抽象。每个 Machine 对应一个具体的虚拟机或裸金属实例。它通过 spec.bootstrap.dataSecretName 引用 BootstrapProvider 生成的初始化数据，通过 spec.infrastructureRef 引用 InfrastructureProvider 定义的资源规格。Machine 控制器负责将这两个 Provider 的输出组合起来，完成节点的创建与加入。

2.3.3 MachineDeployment 与 MachineSet — 声明式节点管理

MachineDeployment 是管理无状态工作节点组的首选方式。它提供了声明式更新策略（RollingUpdate、OnDelete）、副本数管理以及历史版本回滚能力。MachineSet 作为 MachineDeployment 的下级控制器，负责维持一组 Machine 的副本数稳定。当 MachineDeployment 更新模板时，它会创建一个新的 MachineSet，并逐步缩容旧的 MachineSet。

2.3.4 ControlPlane — 控制面生命周期

ControlPlane 资源（如 KubeadmControlPlane）负责管理 Kubernetes 控制面组件的生命周期。它支持高可用配置（多副本 etcd 与 apiserver）、版本升级、以及证书轮换。在回滚场景中，ControlPlane 的回滚通常比 MachineDeployment 更敏感，因为控制面版本回退可能导致 API 兼容性问题。

2.3.5 BootstrapProvider 与 InfrastructureProvider — 插件化扩展

这两个 Provider 是 CAPI 可扩展性的核心。BootstrapProvider 负责生成节点加入集群所需的引导数据（如 kubeadm join 命令、证书、令牌）。InfrastructureProvider 负责创建底层基础设施资源（如 AWS EC2 实例、VPC、安全组）。CAPI 通过接口契约（Contract）与 Provider 交互，使得同一套 CAPI 控制面可以管理不同云厂商的集群。

2.4 资源创建流程时序

下图展示了从创建 Cluster 对象到节点就绪的完整时序，帮助理解各资源之间的协作顺序：

2.5 与回滚策略的关联

理解上述核心概念后，可以明确回滚策略在 CAPI 中的落地位置：

• 回滚粒度： 回滚操作通常作用于 MachineDeployment 和 ControlPlane 两个层级。MachineDeployment 回滚影响工作节点，ControlPlane 回滚影响控制面。
• 版本追踪： MachineDeployment 的 spec.template 变更会触发新的 Revision。回滚时通过 spec.rollbackTo.revision 指定目标版本。
• Provider 兼容性： 回滚时必须确保目标版本的 Machine 模板与当前 InfrastructureProvider 和 BootstrapProvider 的 API 版本兼容。跨版本回滚（如 v1alpha4 → v1beta1）可能导致 Provider 无法识别。
• 状态观察： 回滚进度通过观察 MachineSet 的 status.availableReplicas 和 Machine 的 status.phase 来判定。