本文我们将学习如何使用 Kubernetes Cluster API 和 ArgoCD 创建和管理多个 Kubernetes 集群。我们将使用 Kind 创建一个本地集群，在该集群上，我们将配置其他 Kubernetes 集群的创建过程。为了自动执行该过程，我们将使用 ArgoCD，我们可以从单个 Git 存储库处理整个过程。

介绍

你听说过一个名为 Kubernetes Cluster API(https://cluster-api.sigs.k8s.io/) 的项目吗？它提供声明式 API 和工具来简化配置、升级和管理多个 Kubernetes 集群。我们会先创建一个管理其他集群生命周期的 Kubernetes 集群，在这个集群上，我们将安装 Cluster API。然后我们就可以通过创建 Cluster API 对象来定义新的工作负载集群，看起来是不是非常简单？

Cluster API 提供了一组扩展 Kubernetes API 的 CRD，它们中的每一个都代表 Kubernetes 集群安装的定制，这里我们不会详细介绍它，如果你对此感兴趣，可以在其官方文档 https://cluster-api.sigs.k8s.io/user/concepts.html 了解更多信息。对我们来说重要的是，它提供了一个 CLI 工具来处理 Cluster API 管理集群的生命周期。此外，它还允许在包括 AWS、GCP 或 Azure 在内的多个基础设施上创建集群，但是今天我们将在 Docker 和 Kind 上本地运行整个基础架构，Cluster API 也是支持的，因为它支持 Docker。

我们将使用 Cluster API CLI 来初始化管理集群并生成对应的 YAML 模板，整个过程将由安装在管理集群上的 ArgoCD 进行管理。ArgoCD 非常适合我们的场景，因为它支持多集群，安装在单个集群上的实例可以管理许多其他能够连接的集群。

最后，今天我们使用的最后一个工具是 Kind，使用它我们可以使用 Docker 容器节点在同一台机器上运行多个 Kubernetes 集群，让我们先看一下上面描述的解决方案的架构。

上面的架构图可以看出整个基础设施在 Docker 上运行，我们在管理集群上安装 Kubernetes Cluster API 和 ArgoCD，然后，使用这两个工具，使用 Kind 创建新的集群。之后，我们将把一些 Kubernetes 对象应用到工作负载集群（c1、c2）中，例如 Namespace、ResourceQuota 或 RoleBinding。当然，整个过程由 ArgoCD 实例管理，配置存储在 Git 存储库中。

使用 Kind 和 Cluster API 创建管理集群

第一步，我们要在 Kind 上创建一个管理集群，我们需要在本地机器上安装 Docker、kubectl 和 kind。因为我们将使用 Docker 基础设施来运行 Kubernetes 工作负载集群，Kind 必须有一个访问 Docker 主机的权限。下面是 Kind 集群的定义。

# mgmt-cluster-config.yaml
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
extraMounts:
- hostPath: /var/run/docker.sock
containerPath: /var/run/docker.sock

现在我们使用上面的配置文件创建一个新的管理集群：

$ kind create cluster --config mgmt-cluster-config.yaml --name mgmt
Creating cluster "mgmt" ...
✓ Ensuring node image (kindest/node:v1.23.4) ?
✓ Preparing nodes ?
✓ Writing configuration ?
✓ Starting control-plane ?️
✓ Installing CNI ?
✓ Installing StorageClass ?
Set kubectl context to "kind-mgmt"
You can now use your cluster with:
kubectl cluster-info --context kind-mgmt
Not sure what to do next? ? Check out https://kind.sigs.k8s.io/docs/user/quick-start/

接着我们需要初始化一个管理集群，也就是说我们需要在 Kind 集群上安装 Cluster API，我们首先需要在本地机器上安装 Cluster API CLI。在 macOS 上，可以使用 brew install clusterctl 进行一键安装。成功安装 clusterctl 后，我可以运行以下命令：

$ clusterctl init --infrastructure docker
Fetching providers
Skipping installing cert-manager as it is already installed
Installing Provider="cluster-api" Version="v1.2.0" TargetNamespace="capi-system"
Installing Provider="bootstrap-kubeadm" Version="v1.2.0" TargetNamespace="capi-kubeadm-bootstrap-system"
Installing Provider="control-plane-kubeadm" Version="v1.2.0" TargetNamespace="capi-kubeadm-control-plane-system"
Installing Provider="infrastructure-docker" Version="v1.2.0" TargetNamespace="capd-system"
Your management cluster has been initialized successfully!
You can now create your first workload cluster by running the following:
clusterctl generate cluster [name] --kubernetes-version [version] | kubectl apply -f -

一旦我们成功初始化了一个管理集群，我们就可以对其进行验证，Cluster API 会创建五个新的命名空间。

$ kubectl get ns
NAME STATUS AGE
capd-system Active 100s
capi-kubeadm-bootstrap-system Active 101s
capi-kubeadm-control-plane-system Active 100s
capi-system Active 102s
cert-manager Active 35m
default Active 59m
kube-node-lease Active 59m
kube-public Active 59m
kube-system Active 59m
local-path-storage Active 59m

另外，确保在新命名空间内创建的所有 pod 都应该处于运行状态。

需要注意 Cluster API 初始化后创建的 Pod 默认使用的是 grc.io 的镜像，如不能正常访问需要自己中转下。

$ kubectl get pods -A |grep cap
capd-system capd-controller-manager-85788c974f-nmzkt 1/1 Running 0 107m
capi-kubeadm-bootstrap-system capi-kubeadm-bootstrap-controller-manager-7775897d58-6wp5l 1/1 Running 0 107m
capi-kubeadm-control-plane-system capi-kubeadm-control-plane-controller-manager-6958fd6555-w66xg 1/1 Running 0 107m
capi-system capi-controller-manager-648d7b84b8-l5prr 1/1 Running 0 107m

我们还可以显示已安装 CRD 的列表，现在 Kubernetes Cluster API 正在管理集群上运行了，我们可以继续执行进一步的步骤。

$ kubectl get crd
NAME CREATED AT
certificaterequests.cert-manager.io 2022-08-14T02:52:38Z
certificates.cert-manager.io 2022-08-14T02:52:38Z
challenges.acme.cert-manager.io 2022-08-14T02:52:38Z
clusterclasses.cluster.x-k8s.io 2022-08-14T03:26:48Z
clusterissuers.cert-manager.io 2022-08-14T02:52:38Z
clusterresourcesetbindings.addons.cluster.x-k8s.io 2022-08-14T03:26:48Z
clusterresourcesets.addons.cluster.x-k8s.io 2022-08-14T03:26:48Z
clusters.cluster.x-k8s.io 2022-08-14T03:26:48Z
dockerclusters.infrastructure.cluster.x-k8s.io 2022-08-14T03:26:50Z
dockerclustertemplates.infrastructure.cluster.x-k8s.io 2022-08-14T03:26:51Z
dockermachinepools.infrastructure.cluster.x-k8s.io 2022-08-14T03:26:51Z
dockermachines.infrastructure.cluster.x-k8s.io 2022-08-14T03:26:51Z
dockermachinetemplates.infrastructure.cluster.x-k8s.io 2022-08-14T03:26:51Z
extensionconfigs.runtime.cluster.x-k8s.io 2022-08-14T03:26:48Z
ipaddressclaims.ipam.cluster.x-k8s.io 2022-08-14T03:26:49Z
ipaddresses.ipam.cluster.x-k8s.io 2022-08-14T03:26:49Z
issuers.cert-manager.io 2022-08-14T02:52:38Z
kubeadmconfigs.bootstrap.cluster.x-k8s.io 2022-08-14T03:26:49Z
kubeadmconfigtemplates.bootstrap.cluster.x-k8s.io 2022-08-14T03:26:49Z
kubeadmcontrolplanes.controlplane.cluster.x-k8s.io 2022-08-14T03:26:50Z
kubeadmcontrolplanetemplates.controlplane.cluster.x-k8s.io 2022-08-14T03:26:50Z
machinedeployments.cluster.x-k8s.io 2022-08-14T03:26:49Z
machinehealthchecks.cluster.x-k8s.io 2022-08-14T03:26:49Z
machinepools.cluster.x-k8s.io 2022-08-14T03:26:49Z
machines.cluster.x-k8s.io 2022-08-14T03:26:49Z
machinesets.cluster.x-k8s.io 2022-08-14T03:26:49Z
orders.acme.cert-manager.io 2022-08-14T02:52:38Z
providers.clusterctl.cluster.x-k8s.io 2022-08-14T02:50:54Z

安装 ArgoCD

这里我们将 ArgoCD 安装到 default 命名空间，使用下面的命令一键安装即可：

$ kubectl apply -f https://raw.githubusercontent.com/argoproj/argo-cd/v2.4.9/manifests/install.yaml

安装后查看对应的 Pod 状态：

$ kubectl get pods
NAME READY STATUS RESTARTS AGE
argocd-application-controller-0 1/1 Running 0 171m
argocd-applicationset-controller-86c8556b6d-dxlhs 1/1 Running 0 171m
argocd-dex-server-5c65569f55-mff75 1/1 Running 0 171m
argocd-notifications-controller-f5d57bc55-4hdqd 1/1 Running 0 171m
argocd-redis-65596bf87-2d5kx 1/1 Running 0 171m
argocd-repo-server-5bfd7c4cfd-4hxn5 1/1 Running 0 171m
argocd-server-8544dd9f89-cdgrw 1/1 Running 0 171m

ArgoCD 会提供一个用于管理的 Web UI，我们可以创建一个 Ingress 对象来暴露该服务，但还需要安装一个 Ingress 控制器，我们这里就直接 kubectl port-forward 命令在本地来暴露该服务：

$ kubectl port-forward svc/argocd-server 8080:80

然后我们就可以通过 http://localhost:8080 访问 ArgoCD 了。

默认情况下 admin 账号的初始密码是自动生成的，会以明文的形式存储在 ArgoCD 安装的命名空间中名为 argocd-initial-admin-secret 的 Secret 对象下的 password 字段下，我们可以用下面的命令来获取：

$ kubectl get secret argocd-initial-admin-secret -o jsonpath="{.data.password}" | base64 -d && echo

使用用户名 admin 和上面输出的密码即可登录 Dashboard。

使用 Cluster API 和 ArgoCD 创建 Kubernetes 集群

我们将使用 clusterctl 命令行工具生成带有新 Kubernetes 集群声明的 YAML 资源清单，直接执行如下所示的命令即可，它将生成清单并将其保存到 c1-clusterapi.yaml 文件中。

$ clusterctl generate cluster c1 --flavor development \
--infrastructure docker \
--kubernetes-version v1.21.1 \
--control-plane-machine-count=3 \
--worker-machine-count=3 \
> c1-clusterapi.yaml

我们的 c1 集群由三个主节点和三个工作节点组成。按照 Cluster API 文档介绍，我们需要将生成的清单应用到管理集群中，不过我们这里将使用 ArgoCD，所以我们需要使用一个 Git 仓库来托管 Cluster API 的资源清单应用到 Kubernetes 集群。所以我们需要在 Git 仓库中创建一个包含 Cluster API 对象的清单文件。为了简化流程，我们这里将使用 Helm Chart 模板。因为要创建两个集群，所以我们必须使用带有参数化的相同模板的 ArgoCD 应用程序。可以在我们提供的 Git 仓库下的 /mgmt/templates/cluster-api-template.yaml 路径找到它。

apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
metadata:
name: {{ .Values.cluster.name }}
namespace: default
spec:
clusterNetwork:
pods:
cidrBlocks:
- 192.168.0.0/16
serviceDomain: cluster.local
services:
cidrBlocks:
- 10.128.0.0/12
controlPlaneRef:
apiVersion: controlplane.cluster.x-k8s.io/v1beta1
kind: KubeadmControlPlane
name: {{ .Values.cluster.name }}-control-plane
namespace: default
infrastructureRef:
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: DockerCluster
name: {{ .Values.cluster.name }}
namespace: default
---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: DockerCluster
metadata:
name: {{ .Values.cluster.name }}
namespace: default
---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: DockerMachineTemplate
metadata:
name: {{ .Values.cluster.name }}-control-plane
namespace: default
spec:
template:
spec:
extraMounts:
- containerPath: /var/run/docker.sock
hostPath: /var/run/docker.sock
---
apiVersion: controlplane.cluster.x-k8s.io/v1beta1
kind: KubeadmControlPlane
metadata:
name: {{ .Values.cluster.name }}-control-plane
namespace: default
spec:
kubeadmConfigSpec:
clusterConfiguration:
apiServer:
certSANs:
- localhost
- 127.0.0.1
controllerManager:
extraArgs:
enable-hostpath-provisioner: "true"
initConfiguration:
nodeRegistration:
criSocket: /var/run/containerd/containerd.sock
kubeletExtraArgs:
cgroup-driver: cgroupfs
eviction-hard: nodefs.available<0%,nodefs.inodesFree<0%,imagefs.available<0%
joinConfiguration:
nodeRegistration:
criSocket: /var/run/containerd/containerd.sock
kubeletExtraArgs:
cgroup-driver: cgroupfs
eviction-hard: nodefs.available<0%,nodefs.inodesFree<0%,imagefs.available<0%
machineTemplate:
infrastructureRef:
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: DockerMachineTemplate
name: {{ .Values.cluster.name }}-control-plane
namespace: default
replicas: {{ .Values.cluster.masterNodes }}
version: {{ .Values.cluster.version }}
---
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: DockerMachineTemplate
metadata:
name: {{ .Values.cluster.name }}-md-0
namespace: default
spec:
template:
spec: {}
---
apiVersion: bootstrap.cluster.x-k8s.io/v1beta1
kind: KubeadmConfigTemplate
metadata:
name: {{ .Values.cluster.name }}-md-0
namespace: default
spec:
template:
spec:
joinConfiguration:
nodeRegistration:
kubeletExtraArgs:
cgroup-driver: cgroupfs
eviction-hard: nodefs.available<0%,nodefs.inodesFree<0%,imagefs.available<0%
---
apiVersion: cluster.x-k8s.io/v1beta1
kind: MachineDeployment
metadata:
name: {{ .Values.cluster.name }}-md-0
namespace: default
spec:
clusterName: {{ .Values.cluster.name }}
replicas: {{ .Values.cluster.workerNodes }}
selector:
matchLabels: null
template:
spec:
bootstrap:
configRef:
apiVersion: bootstrap.cluster.x-k8s.io/v1beta1
kind: KubeadmConfigTemplate
name: {{ .Values.cluster.name }}-md-0
namespace: default
clusterName: {{ .Values.cluster.name }}
infrastructureRef:
apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
kind: DockerMachineTemplate
name: {{ .Values.cluster.name }}-md-0
namespace: default
version: {{ .Values.cluster.version }}

我们可以参数化与集群创建相关的四个属性：集群名称、主节点和工作节点的数量或 Kubernetes 的版本。由于我们使用的是 Helm，所以只需要创建 values.yaml 文件，其中包含 YAML 格式的这些参数的值。下面是第一个集群的 values.yaml 文件，我们可以在 Git 仓库的 /mgmt/values-c1.yaml 路径下找到它。

cluster:
name: c1
masterNodes: 3
workerNodes: 3
version: v1.21.1

同样第二个集群也有类似的配置，该集群有一个主节点和一个工作节点，可以在 Git 仓库的 /mgmt/values-c2.yaml 路径下找到它。

cluster:
name: c2
masterNodes: 1
workerNodes: 1
version: v1.21.1

创建 ArgoCD 应用

由于 ArgoCD 支持 Helm，所以我们只需要在 ArgoCD 应用程序的配置中设置正确的 values.yaml 文件即可。除此之外，我们还需要设置我们的 Git 仓库的地址以及仓库中包含清单的目录。管理集群的所有配置都存储在 mgmt 目录中。如下所示：

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: c1-cluster-create
spec:
destination:
name: ""
namespace: ""
server: "https://kubernetes.default.svc"
source:
path: mgmt
repoURL: "https://github.com/cnych/sample-kubernetes-cluster-api-argocd.git"
targetRevision: HEAD
helm:
valueFiles:
- values-c1.yaml
project: default

第二个集群对应的应用资源清单：

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: c2-cluster-create
spec:
destination:
name: ""
namespace: ""
server: "https://kubernetes.default.svc"
source:
path: mgmt
repoURL: "https://github.com/cnych/sample-kubernetes-cluster-api-argocd.git"
targetRevision: HEAD
helm:
valueFiles:
- values-c2.yaml
project: default

ArgoCD 需要管理 Cluster API 对象的权限，为了简化起见，让我们将 ​​cluster-admin​​​ 角色添加到 ArgoCD 使用的 ​​argocd-application-controller​​ ServiceAccount。

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: cluster-admin-argocd-contoller
subjects:
- kind: ServiceAccount
name: argocd-application-controller
namespace: default
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: cluster-admin

在 Argo CD 中创建应用程序后，我们可以手动同步它们（或启用自动同步选项）。它将会开始通过 Cluster API 工具创建工作负载集群。

使用 Cluster API CLI 验证 Kubernetes 集群

使用 ArgoCD 执行同步后，我们可以验证可用 Kubernetes 集群的列表。使用以下 kind 命令即可：

$ kind get clusters
c1
c2
mgmt

可以看到现在一共有三个集群！安装在管理集群 mgmt 上的 Kubernetes Cluster API 根据 ArgoCD 应用的配置创建了另外两个集群。要检查创建的集群是否正常，我们可以使用 clusterctl describe 命令来查看。

$ clusterctl describe cluster c1
NAME READY SEVERITY REASON SINCE MESSAGE
Cluster/c1 True 4m4s
├─ClusterInfrastructure - DockerCluster/c1 True 7m49s
├─ControlPlane - KubeadmControlPlane/c1-control-plane True 4m4s
│ └─3 Machines... True 6m26s See c1-control-plane-p54fn, c1-control-plane-w4v88, ...
└─Workers
└─MachineDeployment/c1-md-0 False Warning WaitingForAvailableMachines 8m54s Minimum availability requires 3 replicas, current 0 available
└─3 Machines... True 5m45s See c1-md-0-6f646885d6-8wr47, c1-md-0-6f646885d6-m5nwb, ...

通过上面的命令可以看到创建的集群控制平面尚未准备好，接着我们需要在工作负载集群上安装 CNI 应用。Cluster API 文档建议使用 Calico 插件，在安装的时候我们需要将上下文切换到 kind-c1 和 kind-c2，它们不是由 Cluster API 在我们的本地机器上创建的，所以首先我们需要将它们导出到我们的 Kubeconfig 文件中。

$ kind export kubeconfig --name c1
$ kind export kubeconfig --name c2

导出后对应的 apiserver 地址变成了 0.0.0.0，所以我们需要编辑对应的 Kubeconfig 文件并将该地址修改为 127.0.0.1，修改完成后，我们就可以使用本地机器上的 kubectl 连接创建的两个集群了。

接着我们可以在这两个集群上安装 Calico CNI：

$ kubectl apply -f https://docs.projectcalico.org/v3.20/manifests/calico.yaml --context kind-c1
$ kubectl apply -f https://docs.projectcalico.org/v3.20/manifests/calico.yaml --context kind-c2

当然我们也可以在 ArgoCD 中去自动执行该步骤，我们可以在后面的文章中来介绍如何使用管理集群上 ArgoCD 来管理这两个集群。现在，如果我们再次使用 clusterctl describe 命令验证两个集群的状态。

$ clusterctl describe cluster c2
NAME READY SEVERITY REASON SINCE MESSAGE
Cluster/c2 True 79m
├─ClusterInfrastructure - DockerCluster/c2 True 80m
├─ControlPlane - KubeadmControlPlane/c2-control-plane True 79m
│ └─Machine/c2-control-plane-tgjph True 79m
└─Workers
└─MachineDeployment/c2-md-0 True 81s
└─Machine/c2-md-0-5b8999bf45-lwcwg True 79m

使用 ArgoCD 管理工作集群

在上一节中，我们已经使用 Cluster API 和 ArgoCD 成功创建了两个 Kubernetes 集群，执行该操作所需的所有 Kubernetes 对象都是在管理集群上创建的。现在，我们想将下面的简单配置应用于我们的两个工作负载集群。当然，我们也会使用同一个 ArgoCD 实例。

apiVersion: v1
kind: Namespace
metadata:
name: demo
---
apiVersion: v1
kind: ResourceQuota
metadata:
name: demo-quota
namespace: demo
spec:
hard:
pods: "10"
requests.cpu: "1"
requests.memory: 1Gi
limits.cpu: "2"
limits.memory: 4Gi
---
apiVersion: v1
kind: LimitRange
metadata:
name: demo-limitrange
namespace: demo
spec:
limits:
- default:
memory: 512Mi
cpu: 500m
defaultRequest:
cpu: 100m
memory: 128Mi
type: Container

不过 ArgoCD 和 Kubernetes Cluster API 工具之间并没有内置集成。尽管 Cluster API 会为每个创建的集群创建一个包含 Kubeconfig 文件的 Secret，但 ArgoCD 无法识别它以自动将此集群添加到托管集群。目前的目标是将我们的两个工作负载集群添加到由在管理集群上运行的 ArgoCD 全局实例管理的集群列表中。为此我们首先需要登录 ArgoCD，我们需要使用与 Web UI 交互时使用的相同凭据和 URL。

$ argocd login localhost:8080

现在，我们只需要运行以下命令，假设我们已经将两个 Kubernetes 上下文导出到本地 Kubeconfig 文件：

$ argocd cluster add kind-c1
$ argocd cluster add kind-c2

如果你在 macOS 或 Windows 上运行 Docker，这并不是一个容易的操作。你需要使用集群的内部 Docker 地址。Cluster API 为所有创建的集群创建包含 Kubeconfig 文件的 Secret，我们可以使用它来验证 Kubernetes API 的内部地址。以下是我们工作负载集群的 Secret 列表：

$ kubectl get secrets | grep kubeconfig
c1-kubeconfig cluster.x-k8s.io/secret 1 85m
c2-kubeconfig cluster.x-k8s.io/secret 1 57m

我们可以在解码对应的 Secret 后获得内部地址，比如我的 c1 集群内部地址是 172.20.0.3。

在后台，ArgoCD 创建了一个与每个托管集群相关的 Secret，根据标签名称和值识别：argocd.argoproj.io/secret-type: cluster。

apiVersion: v1
kind: Secret
metadata:
name: c1-cluster-secret
labels:
argocd.argoproj.io/secret-type: cluster
type: Opaque
data:
name: c1
server: https://172.20.0.3:6443
config: |
{
"tlsClientConfig": {
"insecure": false,
"caData": "<base64 encoded certificate>",
"certData": "<base64 encoded certificate>",
"keyData": "<base64 encoded key>"
}
}

如果你成功添加了所有集群，那么在 ArgoCD 实例的集群中可以看到以下列表。

最后，让我们创建 ArgoCD 应用来管理两个工作负载集群上的配置。

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: c1-cluster-config
spec:
project: default
source:
repoURL: "https://github.com/cnych/sample-kubernetes-cluster-api-argocd.git"
path: workload
targetRevision: HEAD
destination:
server: "https://172.20.0.3:6443"

同样对第二个集群对应的应用资源清单如下所示：

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: c2-cluster-config
spec:
project: default
source:
repoURL: "https://github.com/cnych/sample-kubernetes-cluster-api-argocd.git"
path: workload
targetRevision: HEAD
destination:
server: "https://172.20.0.10:6443"

一旦在 ArgoCD 上创建了这两个应用程序后，我们就可以同步它们。

最后，让我们验证配置是否已成功应用于目标集群。