2. Cluster API 核心概念：Cluster、Machine、MachineDeployment、ControlPlane、Bootstrap、Infrastructure Provider
Cluster API 的核心在于将 Kubernetes 集群的生命周期管理声明式化。理解其六大核心概念是掌握一切工程实践的基础。这些概念共同构成了一个“集群即代码”的抽象层，使得创建、升级、扩缩容以及配置热更新变得可重复、可审计。
2.1 核心概念总览与关系
下图展示了 Cluster API 资源对象之间的核心依赖与组合关系。一个 Cluster 对象作为顶层聚合，通过引用 Infrastructure Cluster 定义网络与节点基础，通过 ControlPlane 定义控制面拓扑，而 MachineDeployment 则负责管理工作节点 Machine 的声明式生命周期。每个 Machine 在创建时都需要 Bootstrap 数据来初始化。
关键理解：Cluster 对象本身不创建任何基础设施，它是一个“聚合根”。真正驱动资源创建的是底层的 Provider 实现。这种分层设计使得 Cluster API 可以跨云平台工作。
2.2 六大核心概念详解
| 概念 | API 对象 | 核心职责 | 与热更新的关系 |
|---|---|---|---|
| Cluster | Cluster |
集群的顶层定义，聚合控制面与基础设施的引用 | 作为更新操作的入口，承载集群级配置 |
| Machine | Machine |
代表一个具体的节点（虚拟机或裸金属） | 通过滚动更新 MachineDeployment 实现节点替换 |
| MachineDeployment | MachineDeployment |
声明式管理工作节点 Machine 的副本、更新策略 | 控制面组件配置变更的主要执行者 |
| ControlPlane | ControlPlane (如 KubeadmControlPlane) |
管理控制面组件的版本、配置与拓扑 | 直接驱动 kube-apiserver、etcd 等组件的配置热更新 |
| Bootstrap Provider | BootstrapConfig (如 KubeadmConfig) |
生成节点初始化所需的脚本和配置（如 kubeadm join） | 配置变更时，新节点使用新的 Bootstrap 数据加入集群 |
| Infrastructure Provider | InfrastructureCluster / InfrastructureMachine |
对接具体云平台（AWS、Azure、vSphere）创建资源 | 提供底层计算资源，配合 Machine 的销毁与重建 |
2.3 核心概念在配置热更新中的角色
在“控制面组件配置热更新”这个工程案例中，每个概念都扮演着不可替代的角色。理解它们的交互是后续章节实现自动化更新的前提。
- ControlPlane 对象：是配置更新的“目标”。当我们修改
KubeadmControlPlane中的spec.kubeadmConfigSpec或spec.version时，Cluster API 控制器会检测到差异，并触发滚动更新。 - MachineDeployment：是配置更新的“执行引擎”。对于工作节点，它通过
spec.strategy.rollingUpdate控制更新速率和最大不可用数量，确保服务不中断。 - Bootstrap Provider：是配置更新的“载体”。每次更新都会生成新的 Bootstrap 数据（如包含新 kubelet 配置的
KubeadmConfig），新 Machine 在启动时自动应用这些配置。 - Infrastructure Provider：是配置更新的“底座”。它负责销毁旧 Machine 对应的虚拟机，并创建新虚拟机，为配置更新提供干净的运行环境。
工程要点：配置热更新的本质不是“原地修改”运行中的进程，而是通过声明式 API 触发“滚动替换”。ControlPlane 和 MachineDeployment 的
spec.version 或 spec.kubeadmConfigSpec 的变更，会驱动 Machine 对象的逐个替换，从而实现配置的“热”加载。
2.4 配置更新流程中的对象交互
以下流程图展示了当用户修改 ControlPlane 配置时，Cluster API 各核心对象之间的典型交互顺序：
2.5 关键差异对比：Machine vs MachineDeployment
在实际工程中，区分 Machine 和 MachineDeployment 的使用场景至关重要，尤其是在配置热更新时。
| 对比维度 | Machine | MachineDeployment |
|---|---|---|
| 管理方式 | 手动管理，创建后不再自动变更 | 声明式管理，自动维护副本数与更新策略 |
| 更新策略 | 无内置更新策略，需手动删除重建 | 支持 RollingUpdate（滚动更新）和 OnDelete |
| 适用场景 | 控制面节点（通常由 ControlPlane 对象管理） | 工作节点（无状态、可替换） |
| 配置热更新 | 通过 ControlPlane 对象的滚动更新间接实现 | 直接修改 spec.template.spec 触发滚动更新 |
| 故障恢复 | 需要手动或依赖外部工具恢复 | 自动创建新 Machine 替换故障节点 |
常见误区：不要试图直接修改运行中的 Machine 对象来更新配置。Cluster API 的设计哲学是“不可变基础设施”——配置变更应通过更新 ControlPlane 或 MachineDeployment 的模板，让控制器创建新 Machine 来承载新配置，然后销毁旧 Machine。
2.6 本章小结
本章详细拆解了 Cluster API 的六大核心概念。在后续的工程案例中，我们将重点围绕 ControlPlane 和 MachineDeployment 这两个对象，结合 Bootstrap Provider 的配置生成能力，实现控制面组件（如 kube-apiserver、kube-controller-manager）的配置热更新。理解这些概念之间的依赖与数据流，是成功实施自动化运维的基础。