📚 课程目录第2章 CAPI基础概念

多集群发布流水线集成CAPI集群生命周期 - 第2节

2.1 Cluster API 项目简介

Cluster API (CAPI) 是 Kubernetes SIG Cluster Lifecycle 下的官方子项目，旨在通过声明式 API 和 Kubernetes 原生控制器模式，实现集群的创建、配置、升级、扩缩容及销毁等全生命周期管理。其核心理念是将“集群”视为与 Pod、Service 同等的 Kubernetes 资源对象，从而让 GitOps 和 CI/CD 流水线能够以一致的方式管理基础设施。

  关键设计目标：
  声明式集群管理：用户通过 YAML 定义期望的集群状态，CAPI 控制器负责调和至目标状态。
多云与混合云抽象：通过 Provider 机制屏蔽不同基础设施（AWS、Azure、vSphere、裸金属等）的差异。
与 Kubernetes 生态融合：复用 CRD、Controller、Webhook 等成熟扩展机制。
自动化运维：支持滚动升级、自动修复、节点池管理，减少人工干预。

自 v1.0 发布以来，CAPI 已成为生产级多集群管理的事实标准，被广泛用于边缘计算、混合云、大规模 Kubernetes 集群舰队等场景。

2.2 核心资源对象

CAPI 定义了若干核心 CRD（Custom Resource Definition），它们共同构成了集群生命周期的描述模型。以下是最关键的四个资源对象：

资源对象	作用域	核心职责	类比 Kubernetes 原生对象
Cluster	Namespace	定义集群的顶层拓扑、网络、控制平面端点	Deployment（集群级）
Machine	Namespace	代表一个具体的计算节点（物理机/虚拟机）	Pod
MachineDeployment	Namespace	管理一组同质 Machine 的声明式更新与扩缩容	Deployment
MachineSet	Namespace	确保指定数量的 Machine 副本运行（由 MachineDeployment 管理）	ReplicaSet

理解要点：Cluster 是“集群蓝图”，Machine 是“节点实例”，MachineDeployment 是“节点池控制器”。这种分层设计与 Kubernetes 工作负载模型高度一致，降低了学习成本。

2.2.1 Cluster 对象

Cluster 是顶层资源，它引用了基础设施提供商的集群模板（如 AWSCluster、AzureCluster）和控制平面配置（如 KubeadmControlPlane）。一个典型的 Cluster 定义包含：

基础设施引用：指向 Provider 特定的集群资源（如 VPC、网络、负载均衡器）。
控制平面引用：指向控制平面对象（如 KubeadmControlPlane），定义 Master 节点配置。
集群网络：Pod 网段、Service 网段、DNS 域名等。

apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
metadata:
  name: my-production-cluster
spec:
  infrastructureRef:
    apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
    kind: AWSCluster
    name: my-production-cluster-aws
  controlPlaneRef:
    apiVersion: controlplane.cluster.x-k8s.io/v1beta1
    kind: KubeadmControlPlane
    name: my-production-cluster-cp

2.2.2 Machine 与 MachineDeployment

Machine 是 CAPI 中最细粒度的节点抽象。每个 Machine 对应一个基础设施实例（如 EC2、VM），并包含引导数据（如 cloud-init）用于初始化节点并加入集群。Machine 具有明确的生命周期状态：Pending → Provisioning → Running → Deleting。

MachineDeployment 则提供了对一组 Machine 的声明式管理，支持：

滚动更新：通过 strategy 字段控制升级速率。
自动修复：当 Machine 节点不健康时自动替换。
扩缩容：修改 replicas 即可调整节点池大小。

apiVersion: cluster.x-k8s.io/v1beta1
kind: MachineDeployment
metadata:
  name: worker-pool-1
spec:
  clusterName: my-production-cluster
  replicas: 5
  template:
    spec:
      version: v1.28.0
      bootstrap:
        configRef:
          apiVersion: bootstrap.cluster.x-k8s.io/v1beta1
          kind: KubeadmConfigTemplate
          name: worker-bootstrap-template
      infrastructureRef:
        apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
        kind: AWSMachineTemplate
        name: worker-machine-template

2.3 Provider 机制与生态

Provider 是 CAPI 实现多云扩展的核心设计。它通过接口抽象将 CAPI 核心控制器与具体基础设施、控制平面、引导方式的实现解耦。每个 Provider 以独立的 Controller 和 CRD 形式存在，通过 Webhook 进行校验。

关键原则：CAPI 核心不直接管理任何基础设施资源，所有与云 API 的交互均由 Provider 完成。这种插件化架构使得社区可以独立开发和维护不同平台的 Provider。

2.3.1 Provider 分类

Provider 类型	职责	典型实现
Infrastructure Provider	管理计算、网络、存储等基础设施资源	AWS (CAPA), Azure (CAPZ), vSphere (CAPV), GCP (CAPG)
Control Plane Provider	管理 Kubernetes 控制平面组件的部署与升级	KubeadmControlPlane (KCP), TalosControlPlane
Bootstrap Provider	生成节点初始化配置（如 kubeadm join 命令）	KubeadmConfigTemplate, EKSConfig

此外，还有 IPAM Provider（IP 地址管理）和 Runtime SDK Provider（扩展钩子）等辅助类型，进一步丰富了生态。

2.3.2 Provider 生态现状

截至 2025 年，CAPI 官方及社区维护的 Provider 已覆盖几乎所有主流基础设施平台：

公有云：AWS (CAPA)、Azure (CAPZ)、GCP (CAPG)、阿里云 (CAPA-ALIBABA)、腾讯云 (TKE)。
私有云/虚拟化：vSphere (CAPV)、OpenStack (CAPO)、Nutanix (CAPX)。
裸金属：Metal3 (CAPM3)、Tinkerbell。
边缘/轻量级：KubeVirt (CAPK)、MicroK8s、K3s。

  选择建议：优先选择官方或 CNCF 毕业项目维护的 Provider（如 CAPA、CAPZ、CAPV），它们通常拥有更完善的测试覆盖和更快的 bug 修复周期。对于非主流平台，可考虑基于 Runtime SDK 自建 Provider。

2.4 本章小结

Cluster API 通过 Cluster、Machine、MachineDeployment 等核心资源对象，将集群生命周期管理抽象为 Kubernetes 原生的声明式工作流。Provider 机制则确保了这种抽象能够无缝适配从公有云到裸金属的各类基础设施。理解这些基础概念，是后续设计多集群发布流水线的必要前提。