Argo CD ApplicationSet 3大杀手级场景：集群插件、Monorepo多仓一管与租户自助服务

Argo CD ApplicationSet 3大杀手级场景：集群插件、Monorepo多仓一管与租户自助服务

【免费下载链接】applicationsetThe ApplicationSet controller manages multiple Argo CD Applications as a single ApplicationSet unit, supporting deployments to large numbers of clusters, deployments of large monorepos, and enabling secure Application self-service.项目地址: https://gitcode.com/gh_mirrors/ap/applicationset

Argo CD ApplicationSet是一个 Kubernetes 控制器，它用“生成器（Generator）+ 模板渲染”的机制，让你用一个ApplicationSet资源批量创建并持续管理成百上千个 Argo CDApplication，完美覆盖集群插件、Monorepo 多仓一管、租户自助服务三大高价值场景，是多集群 GitOps 交付的自动化利器。

🧩 先搞懂 ApplicationSet：1 分钟看懂它如何工作

普通的 Argo CDApplication只能“一个应用 → 一个集群/命名空间”。而ApplicationSet由两部分组成：

• generators（生成器）：从 List 列表、Argo CD 已注册集群、Git 仓库文件/目录等来源，动态产出一组组模板参数；
• template（模板）：一个带{{参数}}占位符的Application模板。

控制器的工作流程只有 4 步：

1. 生成器处理数据源，产出参数列表；
2. 每组参数替换一次模板占位符；
3. 每份渲染结果变成一个 Argo CDApplication资源；
4. Argo CD 接管这些Application，完成实际同步。

之后对ApplicationSet的任何增删改，都会自动同步到它生成的每一个Application，无需手工维护。

上图来自 docs/index.md 中的经典示例：List 生成器列出 3 个集群，ApplicationSet控制器随即批量渲染出engineering-dev-guestbook、engineering-prod-guestbook等多个 Application，在 Argo CD Web UI 中一目了然。

🏗️ 场景一：集群插件（Cluster Add-Ons）——新集群自动装好“全家桶”

痛点：基础设施团队需要把 Prometheus Operator、Argo Workflows 等“集群插件”部署到几十甚至上千个 Kubernetes 集群。每个新集群都要人工装一遍？那几乎不可能规模化。

解法：插件清单放在 Git 仓库中，由 ApplicationSet 批量下发。你可以按管理精细度三选一：

• List 生成器：在ApplicationSet里直接维护目标集群清单，简单直接，示例见 list-example.yaml；
• Cluster 生成器：自动发现 Argo CD 中已注册的集群——往 Argo CD 里加一个集群，插件就自动部署过去，零手工操作；
• Matrix 生成器：把“Git 目录 × 集群”两个维度做笛卡尔积，一次实现“多个插件 × 多个集群”的组合下发，参考 cluster-and-git.yaml。

此外还能通过集群标签（如 staging / production）精确圈定插件的部署范围。详细原理见 docs/Use-Cases.md 的 cluster add-ons 一节。

📦 场景二：Monorepo 多仓一管——一个 Git 仓库驱动整个集群

痛点：基础设施团队和业务团队把全部清单维护在同一个大仓库（Monorepo）里，合并进仓库的变更应自动部署到集群，而不是靠人肉触发。

解法：用Git 生成器扫描仓库。它有两种玩法：

• directories：用通配符指向仓库中的子目录，每个目录自动变成一个独立的Application。例如 git-directories-example.yaml 中扫描cluster-addons/*，argo-workflows、prometheus-operator两个目录就被自动“一目录一应用”地管理起来；
• files：指定仓库中的 JSON 元数据文件，每个文件描述一个应用（仓库地址、分支、路径等），同样自动渲染成 Application。

只要业务团队把新服务的清单合并进仓库，Argo CD 就会自动接管部署——真正做到“仓库即集群状态”。

🔐 场景三：租户自助服务——开发者自助部署，管理员高枕无忧

痛点：多租户集群里，开发者想用自己的 Argo CD 部署应用，按传统 app-of-apps 模式只能把Application清单提交给管理员审核合并。但Application的 spec 里有project、cluster、namespace等敏感字段，一旦误合并，应用就可能越权访问不该访问的命名空间或集群——审核成本极高。

解法：管理员预先创建好一个ApplicationSet，用模板把“危险字段”锁死为固定值，只开放“安全字段”给开发者自助填写：

spec: generators: - git: repoURL: https://git.example.com/teams/config.git files: - path: "apps/**/config.json" # 开发者只需改这个 JSON template: spec: project: dev-team-one # 危险字段：锁死 source: repoURL: '{{app.source}}' # 安全字段：开发者可自定义 targetRevision: '{{app.revision}}' path: '{{app.path}}' destination: name: production-cluster # 危险字段：锁死 namespace: dev-team-one

开发者只需在自己的配置文件里填源仓库、分支、路径，就能安全地自助部署多个应用；目标集群与命名空间由管理员掌控，越权风险从机制上被消除。完整示例见 docs/Use-Cases.md 的 self-service 章节。

🚀 快速上手：安装与最小配置

• Argo CD v2.3 及以上版本已内置ApplicationSet 控制器，随 Argo CD 一起安装即可，无需单独部署；
• 老版本可通过仓库内的安装清单一键部署：kubectl apply -n argocd -f manifests/install.yaml，文件见 manifests/install.yaml；
• 安装后无需额外配置，创建一个ApplicationSet资源即可开始体验。

想深入源码时，各生成器的实现都集中在 pkg/generators/ 目录（如 cluster.go、git.go），入门教程可参考 docs/Getting-Started.md。

📌 一句话总结

场景	核心生成器	解决的问题
集群插件	Cluster / List / Matrix	新集群自动安装全套基础设施组件
Monorepo 多仓一管	Git（directories / files）	一个仓库合并即自动部署全集群
租户自助服务	Git + 模板锁字段	开发者自助部署，管理员锁定敏感字段

一个ApplicationSet，三种玩法，把 GitOps 的规模化难题一次性解决——这正是它被称为“杀手级”能力的原因。

【免费下载链接】applicationsetThe ApplicationSet controller manages multiple Argo CD Applications as a single ApplicationSet unit, supporting deployments to large numbers of clusters, deployments of large monorepos, and enabling secure Application self-service.项目地址: https://gitcode.com/gh_mirrors/ap/applicationset