Argo CD App of Apps 模式深度解析：像管理应用一样管理应用

Argo CD App of Apps 模式深度解析：像管理应用一样管理应用

当你用 Argo CD 部署第一个应用时，一切都简单美好。但当你需要管理几十上百个应用、实现一键自举整个集群，或者让团队自助创建部署环境时，手动一个个创建 Application 就变成噩梦。App of Apps 模式正是为解决这类问题而生，它让你把 Application 当作普通资源进行编排，真正实现“用 GitOps 管理 GitOps”。

目录

1. 从单个 Application 到批量管理之痛

        在 Argo CD 中，每个应用（Application）对应一个 Git 仓库中的配置集合。当你只有几个服务时，可以直接用 argocd app create 或手动 apply 几个 Application YAML 来解决。

        但随着业务增长，你可能面临：

• 微服务拆分：50 个微服务，需要 50 个 Application，每次新增服务都要手动创建。

• 多环境推广：同一套应用要部署到 dev / staging / prod，每个环境都要有一组 Application。

• 团队自助：每个团队需要独立部署自己的服务，但不能给他们 Argo CD 的管理员权限。

• 集群重建：当需要重建集群时，能不能一键把所有应用都部署回来？

        面对这些需求，靠手工管理 Application 资源肯定不行。于是诞生了两种批量管理思路：App of Apps 模式和 ApplicationSet。今天我们先深入讲解 App of Apps，它更简单、更灵活，是很多团队的首选起点。

2. 什么是 App of Apps 模式？

        App of Apps 不是一个特定的 API 对象，而是一种架构模式。其核心思想是：

用一个“根 Application”来管理一组“子 Application”，这些子 Application 的定义文件本身也存放在 Git 仓库中，根 Application 通过指向该目录将它们 apply 到集群。

        简单说，就是把 Application 的 YAML 文件当成普通 Kubernetes 资源来部署，而 Argo CD 认出了这些 Application 资源，就会自动去接管它们所描述的应用。

        一句话概括：用 Argo CD 来部署 Argo CD 的 Application，实现元级别的管理。

3. 为什么需要 App of Apps？

        相比手工管理，App of Apps 带来几个关键收益：

• 一键自举：新集群初始化时，只需部署一个根 Application，所有业务应用自动部署。

• 声明式统一管理：所有子 Application 的定义都在 Git 中，版本化、可审计、可回滚。

• 权限控制：不同团队可以维护自己的 Application 定义文件，提 PR 来管理服务，无需接触 Argo CD 本身。

• 组合灵活：你可以把根 Application 指向不同的目录，分别管理“基础设施应用”“业务应用”“监控组件”等。

        本质上，App of Apps 把 Application 的管理也纳入了 GitOps 的范围。

4. 工作原理：一个 Application 管理一群 Application

        假设你有一个 Git 仓库，结构如下：

text

argocd-apps/
├── root-app.yaml # 根 Application
└── team-a/
├── frontend-app.yaml # 子 Application
└── backend-app.yaml

• 根 Application 的 source.path 指向仓库根目录（.），它会扫描该目录下所有的 YAML 文件。

• 当根应用同步时，Argo CD 将 team-a/frontend-app.yaml 和 team-a/backend-app.yaml 中的 Application 对象应用到集群。

• Argo CD 的应用控制器监测到新的 Application 资源，开始独立管理它们，分别从各自的 Git 源拉取配置并部署实际的服务。

        注意：根 Application 本身也是一个 Application，它需要被创建一次。你可以手动创建它，或者用更高层级的 App of Apps 来创建它（听起来像套娃？确实可以）。

5. 实战：从零构建 App of Apps

5.1 准备 Git 仓库目录

        创建一个名为 app-of-apps-demo 的 Git 仓库，结构如下：

text

app-of-apps-demo/
├── root-app.yaml
├── apps/
│ ├── guestbook-app.yaml
│ └── nginx-app.yaml

        其中 root-app.yaml 就是根 Application，apps/ 目录下是子 Application 的定义。

5.2 编写子 Application

apps/guestbook-app.yaml（与以前创建的 guestbook 应用相同）：

yaml

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: guestbook
namespace: argocd
spec:
project: default
source:
repoURL: https://github.com/argoproj/argocd-example-apps.git
targetRevision: HEAD
path: guestbook
destination:
server: https://kubernetes.default.svc
namespace: guestbook
syncPolicy:
automated:
prune: true
selfHeal: true
syncOptions:
– CreateNamespace=true

apps/nginx-app.yaml：

yaml

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: nginx
namespace: argocd
spec:
project: default
source:
repoURL: https://github.com/argoproj/argocd-example-apps.git
targetRevision: HEAD
path: nginx
destination:
server: https://kubernetes.default.svc
namespace: nginx
syncPolicy:
automated:
prune: true
selfHeal: true
syncOptions:
– CreateNamespace=true

5.3 编写根 Application

根 Application 指向仓库根目录，路径 . 会递归发现所有 YAML：

yaml

# root-app.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: root-app
namespace: argocd
spec:
project: default
source:
repoURL: https://github.com/your-org/app-of-apps-demo.git
targetRevision: HEAD
path: .
destination:
server: https://kubernetes.default.svc
namespace: argocd
syncPolicy:
automated:
prune: true
selfHeal: true
syncOptions:
– CreateNamespace=true

        注意：这里 path: . 会包含自身 root-app.yaml，但因为 Argo CD 只在同一个 Application 资源中管理自己，根应用不会管理自己的同步，这不会造成问题。但为了干净，你也可以把根应用放在仓库别处（例如一个 bootstrap/ 目录，通过 kubectl 手动 apply），让仓库内的 apps/ 只包含子应用。

5.4 部署并观察

        首先确保你已经安装好 Argo CD 并登录。

        手动部署根 Application（这通常是一次性操作）：

bash

kubectl apply -f root-app.yaml

或者通过 Argo CD CLI：

bash

argocd app create root-app \\
–repo https://github.com/your-org/app-of-apps-demo.git \\
–path . \\
–dest-server https://kubernetes.default.svc \\
–dest-namespace argocd \\
–sync-policy automated \\
–auto-prune \\
–self-heal

同步根应用：

bash

argocd app sync root-app

        几秒钟后，在 Argo CD 的 UI 中，你会看到 root-app 自动创建了 guestbook 和 nginx 两个子 Application，并且它们会立即开始同步自己的资源。最终，guestbook 和 nginx 服务被部署到对应命名空间。

5.5 应用更新与维护

        新增一个服务：在 apps/ 目录下添加一个新的 xxx-app.yaml，提交到 Git，根应用下一次同步（或自动同步）就会在集群中创建新的 Application。

        删除一个服务：从仓库中删除对应的 Application YAML，根应用同步后，由于根应用开启了 prune: true，它会将集群中不再存在的 Application 删除。子 Application 删除时，根据其自身的 syncPolicy 可能会删除实际部署的资源。

        修改子 Application 配置：直接修改子 Application 的 YAML（例如更改 namespace、源路径），提交后根应用会同步更新。这比手动 argocd app set 更符合 GitOps 理念。

6. App of Apps vs ApplicationSet：怎么选？

        我们在上一篇文章已经详细介绍了 ApplicationSet，这里再做一个集中对比：

推荐策略：

• 应用数量少、环境固定 → 用 App of Apps 简单直接。

• 需要多集群、自动发现、参数化 → 用 ApplicationSet。

• 两者可以共存：用 App of Apps 部署一个 ApplicationSet，或者用 ApplicationSet 管理一组 App of Apps 仓库。

7. 高级变体与自举（Bootstrap）

7.1 分层 App of Apps

        你可以有多个根应用，分别管理不同类别的服务：

text

bootstrap/
├── infra-root.yaml → 指向 infra-apps/ 目录
├── business-root.yaml → 指向 business-apps/ 目录
└── monitoring-root.yaml → 指向 monitoring-apps/ 目录

这样，更新监控组件不影响业务应用。

7.2 自举（Bootstrap）：用 App of Apps 管理 Argo CD 自身

        更进一步，你可以用一个“超级根应用”来管理 Argo CD 的安装和配置：

text

bootstrap/
└── bootstrap-root.yaml → 指向 argocd/ 目录，该目录中包含 argocd 的 Helm Chart 或 Application YAML

新集群只需要执行：

bash

kubectl apply -f bootstrap-root.yaml

        Argo CD 就会被创建，然后这个 Argo CD 会管理自己（包括升级），实现完整的 GitOps 自举。

这种模式在企业管理数十个集群时非常强大。

8. 最佳实践与避坑指南

• 清晰划分目录：按团队、环境或服务类型划分子目录，避免单个目录文件过多。

• 使用项目（Project）隔离：不同团队的子 Application 应属于不同的 Project，限制其可访问的仓库和集群。

• 控制 prune 行为：根应用开启 prune: true 意味着删除子 Application YAML 会删除整个应用，务必谨慎。如果只是暂时停用，可以先注释掉或移出目录。

• 防止循环依赖：不要让根应用管理的子应用又去管理根应用，否则会造成不可预知的行为。

• 秘密管理：Application 定义中如果包含敏感信息（例如 repo 密码），应该使用 Sealed Secrets 或 External Secrets，不要明文提交到 Git。

• 监测根应用的健康状态：根应用如果出问题，所有子应用都会受影响。设置告警监控 root-app 的同步状态。

• 版本化 Application 定义：所有子 Application 的 YAML 文件应随着应用仓库一起打 tag，便于回滚。

9. 总结

        App of Apps 是 Argo CD 最经典的管理模式之一，它简单、直接、易理解。你不需要学习新 CRD，只需要把 Application 视为普通的 Kubernetes 资源，利用 Git 和根 Application 来批量编排它们。

        当你已经熟练使用 App of Apps 后，再结合 ApplicationSet 的动态生成能力，就能构建出弹性、可扩展的 GitOps 体系。无论是 10 个还是 1000 个应用，都能从容应对。

        试着把你现在手动管理的几个 Application 迁移到 App of Apps 模式吧，感受一下“一键部署全世界”的愉悦。

        如果这篇文章让你对 App of Apps 有了更清晰的认识，欢迎点赞、收藏。你是否也在使用这套模式？有什么踩坑经验？评论区等你分享！