3. Cluster API (CAPI) 基础概念
Cluster API (CAPI) 是 Kubernetes SIG 社区主导的官方子项目，旨在通过声明式 API 和 Kubernetes 原生控制器模式，实现集群的创建、配置、升级和生命周期管理。它让运维人员能够像管理 Pod 一样管理 Kubernetes 集群，将“集群”本身视为 Kubernetes 中的一等资源对象。
3.1 CAPI 是什么
CAPI 的核心思想是使用 Kubernetes 资源对象来描述集群的期望状态，并由控制器不断协调实际状态与期望状态之间的差异。它解决了传统集群管理中依赖脚本、手动操作、多云适配困难等痛点，为平台门户提供了统一的集群管理抽象层。
核心价值： CAPI 将基础设施（如虚拟机、网络、负载均衡器）的创建与 Kubernetes 集群的引导（如控制平面初始化、节点加入）自动化，实现“集群即代码”（Cluster as Code）。
3.2 核心组件
CAPI 定义了三个核心资源对象，它们构成了集群管理的基石：
| 资源对象 | 作用 | 关键字段 |
|---|---|---|
| Cluster | 集群的顶层抽象，代表一个完整的 Kubernetes 集群，包含控制平面和节点池的引用。 | spec.infrastructureRef（基础设施模板引用）、spec.controlPlaneRef（控制平面模板引用） |
| Machine | 代表集群中的一台具体节点（物理机或虚拟机），是基础设施实例的抽象。 | spec.bootstrap.dataSecretName（引导数据）、spec.infrastructureRef（具体基础设施实例引用） |
| MachineDeployment | 管理一组同质化的 Machine 对象，提供滚动更新、扩缩容、回滚等声明式管理能力。 | spec.replicas（副本数）、spec.template（Machine 模板）、spec.strategy（更新策略） |
类比理解： Cluster 相当于 Deployment（管理整个集群），MachineDeployment 相当于 ReplicaSet（管理一组同质节点），Machine 相当于 Pod（管理单个节点实例）。
3.3 Provider 模型
CAPI 采用高度可插拔的 Provider 模型，将核心逻辑与具体基础设施、引导方式、控制平面实现解耦。Provider 分为三类：
- Infrastructure Provider： 负责管理底层基础设施资源，如 AWS EC2、Azure VM、vSphere 虚拟机、OpenStack 实例等。例如
AWSCluster、AzureCluster。 - Bootstrap Provider： 负责生成节点引导数据（如 kubeadm 配置、云初始化脚本），使新节点能够加入集群。例如
KubeadmConfig。 - ControlPlane Provider： 负责管理控制平面节点的生命周期，包括高可用、升级等。例如
KubeadmControlPlane。
这种模型使得 CAPI 可以轻松扩展支持新的基础设施环境，而无需修改核心控制器代码。平台门户集成 CAPI 时，只需对接相应的 Provider 即可实现多云集群管理。
3.4 资源关系与工作流程
下图展示了 Cluster、MachineDeployment、Machine 以及 Provider 资源之间的典型关系与创建流程：
3.5 关键概念对比
| 概念 | Kubernetes 原生类比 | CAPI 中的角色 |
|---|---|---|
| Cluster | Deployment | 集群的顶层定义，包含控制平面和节点池的引用 |
| MachineDeployment | ReplicaSet | 管理一组同质化 Machine 的声明式更新和扩缩容 |
| Machine | Pod | 代表集群中的一个具体节点实例 |
| Infrastructure Provider | CSI / CNI 插件 | 将 CAPI 资源转换为云平台 API 调用 |
| Bootstrap Provider | Init Container | 生成节点加入集群所需的引导配置 |
注意： 在平台门户集成 CAPI 时，需要确保 Provider 版本与 CAPI 核心版本兼容。升级集群时，CAPI 会先更新 ControlPlane Provider，再滚动更新 MachineDeployment 中的 Machine，整个过程由控制器自动协调。