GitOps 多环境管理：ApplicationSet 实现环境矩阵式自动部署

一、手动给每个环境改配置的日子该结束了

微服务拆了 30 个，环境有 dev/staging/prod 三个，集群按区域还有 us-east/us-west/eu-central——然后你发现管理这些部署的 manifest 成了一场噩梦。每个服务的每个环境都要一份 ArgoCD Application 配置，30 × 3 × 3 = 270 个 YAML 文件。

这不是人力能维护的。一旦加一个新环境（比如新增了 ap-southeast 集群），你需要为 30 个服务各创建一份新配置——这活不该手动做。

ArgoCD 的ApplicationSet就是为了终结这种重复劳动。它本质是一个模板引擎 + 矩阵生成器：你定义一个模板，它自动为每个 (集群, 环境, 服务) 组合生成 Application 对象。

flowchart TD A[ApplicationSet 控制器] --> B[矩阵生成器 Matrix Generator] B --> C[第一维度: 集群列表] B --> D[第二维度: 环境列表] C --> E[us-east] C --> F[us-west] C --> G[eu-central] D --> H[dev] D --> I[staging] D --> J[prod] E & F & G & H & I & J --> K[笛卡尔积展开] K --> L[Application 1: us-east/dev] K --> M[Application 2: us-east/staging] K --> N[Application 3: us-east/prod] K --> O[...] L & M & N & O --> P[ArgoCD Sync] P --> Q[目标集群部署]

二、ApplicationSet 矩阵生成器的核心逻辑

矩阵生成器（Matrix Generator）执行两个维度的笛卡尔积。第一个维度通常是 Git 仓库中按目录组织的服务列表（Git Generator），第二个维度是集群/环境列表（List/Cluster Generator）。

笛卡尔积的结果 ={service_1} × {env_1, env_2} × {cluster_1, cluster_2}。

这个设计的巧妙之处在于：每增加一个维度，只需要往 generator 中加一项，不需要改任何现有配置。

三、多环境矩阵式部署配置

apiVersion: argoproj.io/v1alpha1 kind: ApplicationSet metadata: name: microservices-matrix namespace: argocd spec: # 矩阵生成器：两层笛卡尔积 generators: - matrix: generators: # 第一层：Git 目录遍历，每个子目录 = 一个服务 - git: repoURL: https://github.com/org/infra-config.git revision: main directories: - path: apps/* # 第二层：集群 + 环境列表 - list: elements: - cluster: us-east-dev env: dev server: https://dev-us-east.example.com namespace_prefix: dev - cluster: us-east-staging env: staging server: https://staging-us-east.example.com namespace_prefix: staging - cluster: us-east-prod env: prod server: https://prod-us-east.example.com namespace_prefix: prod - cluster: eu-prod env: prod server: https://prod-eu.example.com namespace_prefix: prod # 注意：不是所有服务都要部署到所有集群 # 通过后续 template 中的 exclude 逻辑过滤 # 模板：通过 templating 变量组合路径 template: metadata: name: '{{path.basename}}-{{cluster}}' labels: app: '{{path.basename}}' env: '{{env}}' # finalizers: cascade 删除时自动清理底层资源 finalizers: - resources-finalizer.argocd.argoproj.io spec: project: default source: repoURL: https://github.com/org/infra-config.git targetRevision: main # 关键路径组合：apps/{服务名}/overlays/{环境} path: 'apps/{{path.basename}}/overlays/{{env}}' destination: server: '{{server}}' namespace: '{{namespace_prefix}}-{{path.basename}}' syncPolicy: automated: prune: true selfHeal: true syncOptions: - CreateNamespace=true - PruneLast=true # PruneLast：最后删除旧资源，防止服务中断 retry: limit: 5 backoff: duration: 10s factor: 2 maxDuration: 3m

关键配置解读

directories[].path: apps/*遍历 Git 仓库中 apps 目录下的所有子目录。每个子目录名（path.basename）成为第一个维度的值——通常是服务名。

list.elements是第二个维度，每个元素包含 cluster 名、server 地址、环境前缀。模板中的{{server}}和{{env}}都来自这里。

PruneLast: true是关键安全设置：删除 Application 时先创建新资源再删除旧资源，避免部署窗口期服务中断。

四、生产环境部署中的陷阱与对策

陷阱一：笛卡尔积爆炸

3 个集群 × 3 个环境 × 30 个服务 = 270 个 Application。ArgoCD 的 Application Controller 在每个 sync 周期内都需要检查全部 Application 的状态，高基数下 CPU 和内存线性增长。

对策：用goTemplate: true开启模板化，在模板中用条件过滤不需要的组合。例如某些内部服务不需要部署到 prod。

陷阱二：配置漂移预防

ApplicationSet 只负责创建和更新 Application，不直接管理应用配置。如果有人在集群中手动改了 Deployment，selfHeal 会在 3 分钟内自动回滚——但前提是 syncPolicy.automated.selfHeal 设为 true。

陷阱三：Secret 管理

不同环境的 Secret 如何区分？推荐用 External Secrets Operator + 命名空间隔离，而不是在 Git 中管理加密 Secret。

适用边界

• 服务数量 > 5 且环境 > 2 的场景，ApplicationSet 收益显著
• 单集群单环境的简单场景用静态 Application 足够
• 对 GitOps 流水线不熟悉的小团队，ApplicationSet 的抽象层级会增加认知负担

五、总结

ApplicationSet 解决的核心问题不是部署本身，而是部署配置的爆炸式增长。矩阵生成器把 O(N×M) 的配置维护量压缩到 O(1) 的模板 + O(N+M) 的源数据。但不要为了用而用——当服务不到 5 个时，静态 Application 更直观。