使用 Git 仓库中的标签，以声明方式定义应用工作负载与托管集群之间的对应关系。

这篇文章，《Argo CD 示例（第二部分）》，提供了在多集群环境下的 Argo CD 中部署应用的一个解决方案。这样一个解决方案具有一些不错的特性。

• 工作负载在 Git 中声明性地定义
• 提供了集群及其功能的权威性列表；即，通过它们的标签等信息来表示
• 可以将工作负载部署到特定集群，通过使用集群标签，即，提供了工作负载和集群之间的映射关系
• 可以通过 web UI 来可视化集群、工作负载及其映射关系

不过，它的问题在于：工作负载和集群之间的映射关系（每个工作负载手动应用的应用集）在 Git 中没有以声明的方式定义。

Argo CD 的文档，集群启动配置，提供了一个解决方案，即应用中的应用模式。

本指南面向运维人员们，他们已经安装了Argo CD，并且有一个新的集群，希望在该集群中安装许多应用程序。

解决这个问题并没有固定的套路，比如，你可以写个脚本来批量创建应用，或者手动一个一个地创建也没问题。不过，用Argo CD的小伙伴们更喜欢用应用集的方式来操作。

问题在于，这份文档仅展示了单集群 Argo CD 环境的模式。在这里，我们将探讨多集群 Argo CD 环境下的应用集合模式。

我们将使用如下所示的一个假设设置，模拟四个管理集群a、b、_c_和d，这些集群分布在两个区域和两个环境内，并根据是否包含GPU节点池进一步区分。

该解决方案将使用一个 Git 仓库标签，该标签明确地规定了工作负载与托管集群之间的映射关系。下面是一些示例工作负载：

• 常见: 在所有集群中统一部署
• 环境变量: 在工作负载因环境差异而变化的所有集群中部署
• gpu环境: 仅在测试环境中且区域为 region-1，工作负载因环境和GPU类型差异而变化的集群中的GPU节点池中部署

如果你想跟着做，你将需要多集群的 Argo CD 设置，如文章所述。文章是关于《Argo CD 集群管理示例（第二部分）》（https://medium.com/@john-tucker/argo-cd-for-cluster-administration-by-example-part-2-3743c0cfe127）。

在这里我们可以看到所有的集群，包括名为_in-cluster_的集群。

我们先来考虑以下常见的工作负载包括：

• 命名空间 common
• 命名空间中的 hello configmap

注：在本文中，工作负载将以特定于工作负载的命名空间和配置映射的形式表示。

它在 larkintuckerllc/common-app 仓库中，通过简单的 Kubernetes 配置文件进行声明性定义，这些配置文件存放在 manifests 文件夹中。因此其部署方式相同。

它也使用 Git 标签进行版本控制；其中 0.1.1 是目前最新的版本。

让我们先考虑一下所谓的“应用中的应用”资源；它更确切地说是工作负载与管理集群之间映射关系的体现。

它在larkintuckerllc/app-of-apps的Git存储库中，该存储库中的_manifests_文件夹内含有Helm图表，用于进行声明性定义。

它与_common_工作负载一样，使用相同的版本控制方式；即使用Git标签；在这里，标签为0.1.3（浏览文件）。

注：为了确保完整性，Helm 图表的版本与 Git 标签保持同步（但真正重要的是 Git 标签）。

manifests/template/required.yaml 文件使用了一个巧妙的 Helm 技巧来强制 name 值；如我们很快将看到的，这个名称是指部署工作负载的集群名称。

{{- $_ := required "名称是必填字段" .Values.name -}}

manifests/templates/common-application.yaml 文件声明将在集群中部署版本 0.1.1 的 common 工作负载。

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  finalizers:
    - 清理器.argocd.argoproj.io
  name: "{{ .Values.name }}-common"
  namespace: argocd
spec:
  目标:
    name: "{{ .Values.name }}"
    namespace: common
  项目: default
  源:
    path: manifests
    repoURL: https://github.com/larkintuckerllc/common-app
    targetRevision: 0.1.1
  syncPolicy:
    自动化:
      allowEmpty: true
      prune: true
      selfHeal: true

几点观察：

• 应用程序名称和目标集群（集群名）都使用 name 值。
• finalizer 确保一旦删除此文件，通用工作负载将从所有集群中移除。
• 这个 自动化同步策略 使托管集群中的资源与工作负载 Git 仓库中的声明保持最严格的同步。

最后，部署版本化的_app-of-apps_资源，该资源用于定义工作负载与集群之间的映射关系。将以下应用集配置（apps-applicationset.yaml）部署到中心集群（Hub 集群）。

apiVersion: argoproj.io/v1alpha1  
kind: ApplicationSet  # 应用集，用于定义和管理多个应用集合  
metadata:  
  name: apps  
  namespace: argocd  
spec:  
  goTemplate: true  
  goTemplateOptions: ["missingkey=error"]  
  generators:  
  - clusters:  
      selector:  
        matchLabels:  
          argocd.argoproj.io/secret-type: cluster  
  template:  
    metadata:  
      name: "{{.name}}-apps"  
      namespace: argocd  
    spec:  
      destination:  
        namespace: argocd  
        name: in-cluster  
      project: default  
      source:  
        helm:  # Helm是一个热门的Kubernetes包管理工具  
          valuesObject:  
            name: "{{.name}}"  
        path: manifests  
        repoURL: https://github.com/larkintuckerllc/app-of-apps  
        targetRevision: 0.1.3  
      syncPolicy:  
          automated:  
            allowEmpty: true  
            prune: true  
            selfHeal: true 

几点观察：

• 集群生成器（cluster generator）为每个集群生成一个名为 [CLUSTER]-apps 的应用；标签匹配确保中心集群（in-cluster）不会被生成
• 由于这些应用的目的地，例如 a-apps ，是中心集群（in-cluster），在 app-of-apps 中定义的应用，比如 a-common 应用，同样会在中心集群上创建
• 通过 Helm 的 name 值，分配 name 模板，这些二级应用的目的地，例如 a-common ，对应的是相应的托管的集群
• 这种自动同步策略使得集群中的二级应用能够与 app-of-apps 的 Git 仓库中声明的内容保持最接近的一致性
• 使用应用集生成应用时，最终处理程序会自动添加（因此无需在应用模板中包含它们）。此外，删除应用集时会自动移除其生成的应用（无需使用最终处理程序）

部署应用程序组。

    $ kubectl apply -f apps-applicationset.yaml --context=kind-hub

运行此命令以应用 yaml 文件到指定上下文中。请在终端中输入上述命令。

我们看到，对于每个聚类，都有一对应用程序。

    $ kubectl get applications -n argocd --context=kind-hub  
    名称 ("NAME")    同步状态    健康状态  
    a-apps     同步状态    良好  
    a-common   同步状态    良好  
    b-apps     同步状态    良好  
    b-common   同步状态    良好  
    c-apps     同步状态    良好  
    c-common   同步状态    良好  
    d-apps     同步状态    良好  
    d-common   同步状态    良好

总结起来，如下图所示的_a_和_b_集群，流程是这样的：

1. 我们部署引用了 apps-of-apps 仓库 v0.1.3 标签的 apps 应用集合。
2. apps 应用集合生成了每个管理集群的 [CLUSTER]-apps 应用，引用 apps-of-apps 仓库 v0.1.3 标签；每个应用的目标都是中心集群。
3. 然后，每个 [CLUSTER]-apps 应用部署了引用 common-app 仓库 v0.1.1 标签的 [CLUSTER]-common 应用；每个应用的目标是相应的管理集群。
4. 最终，每个 [CLUSTER]-common 应用把 common 工作负载部署到相应的管理集群，每个应用基于 common-app 仓库 v0.1.1 标签。

的确，我们可以看到在_a_集群中的最终结果的呈现，这个结果是由_common_应用程序（由_hello_配置映射所表示）带来的。

$ kubectl get configmap -n common --context=kind-a  
NAME               DATA   AGE      
hello              1      9m31s    
kube-root-ca.crt   1      9m32s    

从 web UI，我们可以按集群筛选，这里指的是工作负载被部署到的集群。

有意思的是，现在还没有办法看到某特定的_常见_工作负载部署到了哪些集群。

在第二部分，我们将从一个改进的解决方案入手，允许我们看到特定工作负载部署到哪些集群。然后，我们将描述并部署名为“环境”和“gpu-环境”的工作负载。