Cluster API (CAPI) 基础：核心概念、架构组件与生命周期管理
Cluster API (CAPI) 是 Kubernetes SIG 主导的官方子项目，旨在通过声明式 API 和 Kubernetes 原生控制器模式，实现集群的创建、配置与管理自动化。CAPI 将“集群”视为一等资源，使得管理 Kubernetes 集群如同管理 Pod 一样简单、可重复且可版本控制。
2.1 核心概念：从声明式集群到基础设施即代码
CAPI 的核心思想是使用 Kubernetes 资源对象来描述集群的期望状态，并由控制器不断调和实际状态至期望状态。这种模式带来了以下关键优势：
- 声明式管理：用户只需定义“想要什么”，而非“如何做”。CAPI 控制器负责执行具体操作。
- 基础设施即代码 (IaC)：集群定义存储在 YAML 清单中，可进行版本控制、代码审查和自动化 CI/CD。
- 多云与混合云抽象：通过 Provider 机制，同一套 CAPI 清单可部署到 AWS、Azure、GCP、vSphere 或裸金属。
- 一致性：消除手动配置差异，确保开发、测试、生产环境集群配置一致。
关键认知：CAPI 并非创建集群的 CLI 工具，而是一个运行在 Kubernetes 之上的 Operator。它需要一个“引导集群”（Bootstrap Cluster）来承载 CAPI 控制器本身，然后由该控制器管理“目标集群”（Workload Cluster）的生命周期。
2.2 架构组件：三大核心资源对象
CAPI 围绕三个核心资源构建：Cluster、Machine 和 MachineDeployment。它们共同定义了集群的拓扑、节点组成和扩缩容策略。
| 资源对象 | 职责 | 类比 Kubernetes 原生资源 | 关键字段 |
|---|---|---|---|
| Cluster | 定义集群的全局配置、网络、控制平面端点及基础设施 Provider 引用。 | 类似于 Deployment 定义了应用的全局状态。 |
spec.infrastructureRef, spec.controlPlaneRef |
| Machine | 代表一个具体的、单一的节点（虚拟机或物理机）。是集群中最小的计算单元。 | 类似于 Pod，是调度的基本单位。 |
spec.bootstrap.dataSecretName, spec.machineTemplateRef |
| MachineDeployment | 管理一组同质化的 Machine，提供声明式更新、滚动升级和扩缩容能力。 |
完全类比 Deployment 管理 ReplicaSet 和 Pod。 |
spec.replicas, spec.template, spec.strategy |
架构关系总结：一个
Cluster 对象通常引用一个控制平面对象（如 KubeadmControlPlane）和一个基础设施对象（如 AWSCluster）。MachineDeployment 负责创建 Machine，每个 Machine 又引用一个基础设施实例（如 AWSMachine）和一个引导配置（如 KubeadmConfig）。
2.3 生命周期管理：从创建到销毁
CAPI 通过一系列协调循环（Reconciliation Loop）管理集群的完整生命周期。以下是标准工作负载集群的典型生命周期阶段：
- 创建（Create）：用户提交
Cluster和MachineDeployment清单。CAPI 控制器首先创建控制平面节点（通过KubeadmControlPlane），等待其就绪后，再创建MachineDeployment中的工作节点。 - 扩缩容（Scale）：修改
MachineDeployment.spec.replicas。控制器会创建或删除对应的Machine对象，进而触发基础设施 Provider 创建或销毁虚拟机。 - 升级（Upgrade）：修改
MachineDeployment.spec.template.spec.version。CAPI 执行滚动更新策略，逐步替换旧的Machine，确保服务不中断。 - 修复（Repair）：当
Machine对应的节点变为NotReady或基础设施实例异常时，CAPI 的MachineHealthCheck控制器会识别并自动替换故障机器。 - 销毁（Delete）：删除
Cluster对象会触发级联删除，依次清理所有Machine、MachineDeployment以及底层基础设施资源。
重要提示：CAPI 的生命周期管理依赖于 Provider 的实现质量。在生产环境中，务必确保基础设施 Provider（如
AWSCluster、AzureCluster）的版本与 CAPI 核心控制器版本兼容，并已充分测试销毁流程，避免资源泄漏。
2.4 关键设计模式：Provider 与 Bootstrap
CAPI 的扩展性依赖于两层抽象：
- 基础设施 Provider：负责管理具体的 IaaS 资源（如 AWS EC2、Azure VM、vSphere 虚拟机）。每个 Provider 实现一组 CRD（如
AWSCluster、AWSMachine）和对应的控制器。 - 引导 Provider：负责将节点加入集群并生成 kubeadm 配置。最常用的是
KubeadmControlPlane和KubeadmConfig。
这种分层设计使得 CAPI 可以轻松支持新的基础设施环境，而无需修改核心逻辑。
最佳实践：在规划集群容量时，应充分利用
MachineDeployment 的 spec.template.spec.nodeDrainTimeout 和 spec.template.spec.nodeVolumeDetachTimeout 等字段，精细控制节点排空行为，避免在缩容或升级时影响运行中的工作负载。