4. CAPI 架构深度解析：管理集群与工作集群、Provider 模式、控制平面与节点管理

Cluster API (CAPI) 的核心架构围绕“管理集群”与“工作集群”的职责分离展开，并通过强大的 Provider 模式实现了对异构基础设施的抽象。本章将深入剖析这一架构，帮助您理解 CAPI 如何实现声明式的集群生命周期管理。

4.1 管理集群与工作集群：职责分离

CAPI 将 Kubernetes 集群分为两种逻辑角色，这种分离是架构设计的基石：

• 管理集群 (Management Cluster)：运行 CAPI 控制器（cluster-api-controller）和各类 Provider 控制器。它负责编排和监控所有工作集群的创建、升级、扩缩容和销毁。管理集群本身不运行用户业务负载。
• 工作集群 (Workload Cluster)：由管理集群通过声明式 API 创建和管理的“业务”集群。它运行用户的容器化应用，对 CAPI 控制器的存在无感知。

下图展示了管理集群与工作集群之间的核心交互关系：

4.2 Provider 模式：基础设施抽象

Provider 是 CAPI 架构中最具扩展性的设计。它将 CAPI 核心逻辑与具体基础设施（如 AWS、vSphere、OpenStack）解耦。每个 Provider 都是一个独立的 Kubernetes 控制器，负责实现特定资源的生命周期管理。

Provider 分为四大类，下表总结了它们的职责与典型实现：

下图展示了 Provider 模式如何协同工作，完成一个工作集群的创建：

4.3 控制平面与节点管理

CAPI 通过两个核心 CRD 来管理集群的控制平面和节点：KubeadmControlPlane 和 MachineDeployment。它们分别对应有状态和无状态组件的生命周期。

4.3.1 控制平面管理：KubeadmControlPlane

KubeadmControlPlane (KCP) 是 CAPI 管理控制平面节点的标准方式。它封装了 kubeadm 的复杂性，提供了声明式的控制平面生命周期管理：

• 版本管理：通过 spec.version 字段声明 Kubernetes 版本，KCP 会自动执行滚动升级。
• 高可用：通过 spec.replicas 控制控制平面节点数量（通常为 3 或 5），确保 etcd 和 API Server 的高可用。
• 故障自愈：当控制平面节点发生故障时，KCP 会自动创建新节点替换，并重新加入集群。

apiVersion: controlplane.cluster.x-k8s.io/v1beta1
kind: KubeadmControlPlane
metadata:
  name: my-cluster-control-plane
spec:
  replicas: 3
  version: v1.28.0
  machineTemplate:
    infrastructureRef:
      apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
      kind: AWSMachineTemplate
      name: my-cluster-cp-template
  kubeadmConfigSpec:
    clusterConfiguration:
      controllerManager:
        extraArgs:
          bind-address: "0.0.0.0"
    initConfiguration:
      nodeRegistration:
        name: '{{ ds.meta_data.local_hostname }}'

4.3.2 节点管理：MachineDeployment 与 MachineSet

工作节点（Worker Node）的管理通过 MachineDeployment 实现，其概念与 Kubernetes 原生的 Deployment 完全一致：

以下是一个 MachineDeployment 的示例，它定义了如何创建和管理一组工作节点：

apiVersion: cluster.x-k8s.io/v1beta1
kind: MachineDeployment
metadata:
  name: my-cluster-worker-md-0
spec:
  clusterName: my-cluster
  replicas: 5
  selector:
    matchLabels:
      cluster.x-k8s.io/cluster-name: my-cluster
  template:
    spec:
      version: v1.28.0
      bootstrap:
        configRef:
          apiVersion: bootstrap.cluster.x-k8s.io/v1beta1
          kind: KubeadmConfigTemplate
          name: my-cluster-worker-config
      infrastructureRef:
        apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
        kind: AWSMachineTemplate
        name: my-cluster-worker-template

4.4 架构总结：声明式集群生命周期

综合以上组件，CAPI 的完整架构形成了一个清晰的声明式闭环：

1. 用户定义：通过 Cluster、KubeadmControlPlane、MachineDeployment 等 YAML 清单声明集群的期望状态。
2. 核心调和：CAPI 核心控制器监听这些 CRD 的变化，创建对应的 Machine 和 Cluster 状态对象。
3. Provider 执行：基础设施 Provider 创建虚拟机，引导 Provider 生成启动脚本，控制平面 Provider 初始化 Kubernetes 组件。
4. 状态反馈：Provider 将实际状态（如 IP 地址、节点就绪状态）写回 CRD 的 status 字段。
5. 持续调和：CAPI 控制器持续比较期望状态与实际状态，自动修复偏差（如节点故障、版本不一致）。