使用 Cluster API 和 ArgoCD 创建管理 Kubernetes 集群

作者 |阳明
来源 | k8s技术圈（ID：kube100）

本文我们将学习如何使用 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 上创建了这两个应用程序后，我们就可以同步它们。最后，让我们验证配置是否已成功应用于目标集群。