3. 控制面架构概览
Cluster API 的核心设计理念是将 Kubernetes 集群的声明式管理能力抽象为一系列可插拔的 Provider。这些 Provider 运行在管理集群（Management Cluster）的控制面中，通过标准的 Kubernetes 资源对象（如 Cluster、Machine、MachineDeployment）驱动目标集群（Workload Cluster）的完整生命周期。
整个控制面架构由三大核心 Provider 构成，它们各司其职，通过协调循环（Reconciliation Loop）实现最终一致性。
3.1 三大核心 Provider 定义与职责
| Provider 类型 | 核心职责 | 管理的关键资源 | 典型实现 |
|---|---|---|---|
| Core Provider | 提供 Cluster API 的通用控制逻辑与资源模型，不依赖具体基础设施。 | Cluster, Machine, MachineSet, MachineDeployment |
cluster-api-controller（官方核心控制器） |
| Infrastructure Provider | 负责在特定基础设施（AWS、vSphere、OpenStack 等）上创建、删除和管理虚拟机、网络、负载均衡器等资源。 | AWSMachine, VSphereMachine, OpenStackMachine, InfrastructureCluster |
cluster-api-provider-aws (CAPA), cluster-api-provider-vsphere (CAPV) |
| Bootstrap Provider | 负责生成节点初始化所需的配置（如 cloud-init 脚本、kubeadm 配置），将新节点加入集群。 | KubeadmConfig, KubeadmConfigTemplate |
cluster-api-bootstrap-provider-kubeadm (CABPK) |
关键理解： Core Provider 定义了“做什么”（如：我需要一个 3 节点的控制面），Infrastructure Provider 定义了“在哪里做”（如：在 AWS 的 us-east-1 区域创建 3 台 t3.medium 实例），Bootstrap Provider 定义了“怎么做”（如：用 kubeadm 初始化并加入集群）。
3.2 组件交互流程：从声明到集群就绪
当用户提交一个 Cluster 对象和关联的 Machine 对象到管理集群后，三大 Provider 通过以下标准流程协同工作：
- Cluster 对象创建：Core Provider 的
ClusterController检测到新的Cluster对象，开始协调。 - 基础设施集群创建：Core Provider 调用 Infrastructure Provider，后者创建对应的
InfrastructureCluster资源（如AWSCluster），并实际创建 VPC、子网、安全组等网络基础设施。 - 控制面 Machine 创建：Core Provider 创建
Machine对象（通常通过MachineDeployment或KubeadmControlPlane资源）。 - Bootstrap 数据生成：Core Provider 调用 Bootstrap Provider，后者生成
KubeadmConfig对象，包含加入集群的 、CA 证书哈希等敏感数据。 - 基础设施 Machine 创建：Core Provider 调用 Infrastructure Provider，后者创建
InfrastructureMachine资源（如AWSMachine），并实际启动虚拟机。 - 节点初始化：虚拟机启动后，通过 cloud-init 或 ignition 执行 Bootstrap Provider 生成的配置脚本，自动安装 kubelet、kubeadm，并执行
kubeadm init或kubeadm join。 - 状态反馈：节点成功加入后，Infrastructure Provider 和 Bootstrap Provider 更新各自资源的状态，Core Provider 最终将
Cluster对象标记为Ready。
多租户网络隔离关键点： 在第 2 步中，Infrastructure Provider 创建的网络基础设施（如 VPC、子网、安全组规则）是后续实现租户间网络隔离的基础。不同的
Cluster 对象可以映射到不同的隔离网络域。
3.3 核心交互流程示意图
下图展示了从用户提交 Cluster 对象到目标集群就绪的完整交互流程，以及三大 Provider 之间的调用关系：
3.4 Provider 之间的资源依赖关系
为了更清晰地理解控制面的数据流，下表展示了关键资源之间的 OwnerReference 和依赖链：
| 资源 A | 资源 B | 依赖关系 | 说明 |
|---|---|---|---|
Cluster |
InfrastructureCluster |
Cluster → InfrastructureCluster | Cluster 通过 .spec.infrastructureRef 引用 InfrastructureCluster |
Machine |
InfrastructureMachine |
Machine → InfrastructureMachine | Machine 通过 .spec.infrastructureRef 引用具体的虚拟机资源 |
Machine |
BootstrapConfig |
Machine → BootstrapConfig | Machine 通过 .spec.bootstrap.dataSecretName 引用初始化密钥 |
KubeadmControlPlane |
Machine |
KubeadmControlPlane → Machine | KubeadmControlPlane 负责管理控制面 Machine 的创建与更新 |
多租户隔离设计注意： 在实现多租户网络隔离时，
InfrastructureCluster 资源是定义网络边界的关键入口。不同的租户应使用不同的 InfrastructureCluster 实例，并确保其引用的网络资源（如 VPC CIDR、子网段）不重叠。Core Provider 本身不感知网络拓扑，所有隔离策略都通过 Infrastructure Provider 实现。
3.5 控制面组件部署架构
在管理集群中，三大 Provider 通常以 Deployment 形式运行，并通过 CRD（Custom Resource Definition）扩展 Kubernetes API。下图展示了这些组件在管理集群内的部署关系：
3.6 多租户场景下的组件职责划分
在多租户网络隔离场景中，理解每个 Provider 的职责边界至关重要：
- Core Provider：负责租户集群的抽象管理，不接触网络配置。它确保每个租户的
Cluster对象被正确协调，但不关心底层网络如何实现隔离。 - Infrastructure Provider：网络隔离的核心执行者。它负责为每个租户的
Cluster创建独立的网络栈（如 AWS VPC + 子网 + 安全组），并确保不同租户的网络 CIDR 不冲突。在多租户部署中，通常需要为每个租户配置独立的InfrastructureCluster模板。 - Bootstrap Provider：负责生成节点初始化配置。在多租户场景下，它可能需要根据租户身份注入不同的网络插件配置（如 Calico 的 IP 池、Cilium 的 ClusterPool），但本身不创建网络资源。
架构总结： Cluster API 通过 Provider 模式实现了关注点分离。Core Provider 提供通用编排逻辑，Infrastructure Provider 封装基础设施差异，Bootstrap Provider 处理节点初始化。这种分层设计使得多租户网络隔离策略可以完全集中在 Infrastructure Provider 层面实现，而无需修改上层编排逻辑。