SuperAPI AI 工具集
合作ENAI 行业资讯收藏
Skill 广场cluster-api

cluster-api

部署与运维

查看项目

更新于 10-23 01:25

技能介绍

Cluster API（CAPI）提供一套以 Kubernetes 原生方式管理集群生命周期的方法。与通过 SSH 登录节点执行命令的运维方式不同，使用 CAPI 时，用户以自定义资源（CR）声明集群的期望状态，再由 CAPI 控制器持续调谐，将实际状态收敛到期望状态。

用途：

  • 从管理集群声明式地创建（provision）工作负载集群。
  • 大规模管理集群集群（数十到数百个）。
  • 通过修改版本字段执行滚动升级。
  • 用 ClusterClass 蓝图标准化集群模板。
  • 使用 Docker 基础设施 Provider 搭建开发、测试环境。

不适用场景：需要进行安全加固的单集群安装（改用 rke2-deployment 或 kubespray-deployment）；没有 CAPI 控制器镜像的离线（air-gapped）环境；没有基础设施 Provider 的裸金属创建。

核心概念：

  • 管理集群（Management Cluster）：运行 CAPI 控制器并存储集群定义，是“大脑”，不运行应用 Pod。
  • 工作负载集群（Workload Cluster）：由 CAPI 创建，运行实际应用。
  • Cluster CR：定义期望的集群状态（版本、拓扑、网络）。
  • Machine：表示单个节点（VM 或容器）。
  • MachineDeployment：管理一组 Machine，类似 Deployment 管理 Pod。
  • MachineSet：MachineDeployment 与 Machine 之间的中间资源。
  • ClusterClass：可复用的蓝图，用于创建拓扑一致的集群。

与 Kubespray/RKE2 相比：Kubespray/RKE2 是命令式方式（Ansible playbook / CLI），面向单集群安装，升级需逐节点手动执行 playbook，一次处理一个集群，对离线环境支持强（RKE2 还具备 FIPS、SELinux、CIS 加固）；CAPI 是声明式方式（Kubernetes CR），面向多集群批量管理，升级只需修改版本字段，可从一个位置管理数百个集群，安全能力取决于基础设施 Provider，离线使用需保证 CAPI 控制器镜像可用。

Provider 架构： CAPI 采用模块化 Provider 架构，四类 Provider 协同工作：

  • Core Provider（capi-system）：管理 Cluster、Machine、MachineSet、MachineDeployment CRD。
  • Bootstrap Provider（capi-kubeadm-bootstrap-system）：生成 cloud-init/user-data 以及 kubeadm init/join 配置。
  • Control Plane Provider（capi-kubeadm-control-plane-system）：管理 KubeadmControlPlane，负责控制面扩缩容、升级与 etcd 成员管理。
  • Infrastructure Provider（命名空间依 Provider 而定）：创建实际的 VM/容器、负载均衡器、网络与磁盘。

基础设施 Provider 示例：Docker（CAPD，capd-system，用 Docker 容器模拟节点，用于开发测试）、vSphere（CAPV，capv-system）、AWS（CAPA，capa-system）、Azure（CAPZ，capz-system）、Metal3（CAPM3，capm3-system，通过 Ironic 管理裸金属服务器）。

使用方式（Docker Provider 实操概要）：

  1. 用 KinD 创建管理集群，需挂载 Docker socket（供 CAPD 创建容器模拟节点），并映射 NodePort 端口。
  2. 安装 clusterctl：macOS 使用 brew install clusterctl；Linux amd64 从 GitHub releases 下载二进制，chmod +x 后移至 /usr/local/bin，用 clusterctl version 验证。
  3. 初始化管理集群：export CLUSTER_TOPOLOGY=true，然后 clusterctl init --infrastructure docker。该命令会安装 cert-manager、Core、Bootstrap、Control Plane 与 Docker Infrastructure Provider。
  4. 验证：kubectl get providers.clusterctl.cluster.x-k8s.io -A，并检查 capi、capd、cert-manager 相关 Pod 均为 Running。
  5. 生成并应用集群清单：设置 SERVICE_CIDR、POD_CIDR、SERVICE_DOMAIN、POD_SECURITY_STANDARD_ENABLED 等变量后，执行 clusterctl generate cluster capi-quickstart --flavor development --kubernetes-version v1.34.3 --control-plane-machine-count=3 --worker-machine-count=3 > capi-quickstart.yaml，再 kubectl apply -f。--flavor development 选用面向本地 Docker 开发的预置模板，含 ClusterClass、DockerCluster/DockerMachine 模板与 kubeadm 配置。
  6. 监控创建过程：clusterctl describe cluster capi-quickstart（加 --show-conditions all 查看实时条件）。过程中 CAPD 创建模拟节点的容器与 HAProxy 负载均衡容器，Bootstrap Provider 生成 kubeadm 配置，控制面 Provider 依次执行 kubeadm init 与 join，Worker 通过 kubeadm join 加入。
  7. 获取 kubeconfig：clusterctl get kubeconfig capi-quickstart > capi-quickstart.kubeconfig。Docker Provider 下需将 server 地址改为 127.0.0.1 和 HAProxy 容器映射端口（用 docker ps 查看）。
  8. 安装 CNI：CAPI 不自动安装 CNI，节点会保持 NotReady；示例用 Calico 清单安装后，节点应在 1-2 分钟内变为 Ready。
  9. 完整验证：查看节点、系统 Pod、clusterctl 集群状态、Machine 与 MachineDeployment 对象。

ClusterClass（Topology）：ClusterClass 是可复用的集群蓝图；定义一次集群形态（基础设施、控制面、Worker 模板），创建集群时引用即可。使用前需在 clusterctl init 之前设置 export CLUSTER_TOPOLOGY=true。其资源层级包括：ClusterClass 引用 DockerClusterTemplate、KubeadmControlPlaneTemplate（内含 DockerMachineTemplate 控制面模板），以及 Workers 下的 MachineDeployments（如 class: default-worker）。

限制与注意事项：CAPI 不安装 CNI；Docker Provider 生成的 kubeconfig 需手工改为本地地址与映射端口；离线环境需预先提供 CAPI 控制器镜像；安全加固能力取决于所选基础设施 Provider。