Argo CD App of Apps 模式深度解析像管理应用一样管理应用当你用 Argo CD 部署第一个应用时一切都简单美好。但当你需要管理几十上百个应用、实现一键自举整个集群或者让团队自助创建部署环境时手动一个个创建 Application 就变成噩梦。App of Apps 模式正是为解决这类问题而生它让你把 Application 当作普通资源进行编排真正实现“用 GitOps 管理 GitOps”。目录从单个 Application 到批量管理之痛什么是 App of Apps 模式为什么需要 App of Apps工作原理一个 Application 管理一群 Application实战从零构建 App of Apps5.1 准备 Git 仓库目录5.2 编写子 Application5.3 编写根 Application5.4 部署并观察5.5 应用更新与维护App of Apps vs ApplicationSet怎么选高级变体与自举Bootstrap最佳实践与避坑指南总结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 仓库结构如下textargocd-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 Apps5.1 准备 Git 仓库目录创建一个名为app-of-apps-demo的 Git 仓库结构如下textapp-of-apps-demo/ ├── root-app.yaml ├── apps/ │ ├── guestbook-app.yaml │ └── nginx-app.yaml其中root-app.yaml就是根 Applicationapps/目录下是子 Application 的定义。5.2 编写子 Applicationapps/guestbook-app.yaml与以前创建的 guestbook 应用相同yamlapiVersion: 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: - CreateNamespacetrueapps/nginx-app.yamlyamlapiVersion: 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: - CreateNamespacetrue5.3 编写根 Application根 Application 指向仓库根目录路径.会递归发现所有 YAMLyaml# 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: - CreateNamespacetrue注意这里path: .会包含自身root-app.yaml但因为 Argo CD 只在同一个 Application 资源中管理自己根应用不会管理自己的同步这不会造成问题。但为了干净你也可以把根应用放在仓库别处例如一个bootstrap/目录通过 kubectl 手动 apply让仓库内的apps/只包含子应用。5.4 部署并观察首先确保你已经安装好 Argo CD 并登录。手动部署根 Application这通常是一次性操作bashkubectl apply -f root-app.yaml或者通过 Argo CD CLIbashargocd 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同步根应用bashargocd 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 AppsApplicationSet本质模式用根 Application 管理静态子 Application YAMLCRD用生成器动态生成 Application子应用数量由仓库中静态 YAML 数量决定由生成器输出决定可动态变化新增应用需要人往 Git 加一个 YAML可以自动感知新分支/新集群/新目录等多集群需要为每个集群写一个 ApplicationCluster 生成器自动为新集群生成应用参数化能力弱要靠 Helm/Kustomize 辅助内建模板变量非常灵活复杂度低纯 Git 操作中需要理解生成器适用场景中小规模固定应用集合需人类审批大规模动态环境PR 预览、多租户推荐策略应用数量少、环境固定 → 用 App of Apps 简单直接。需要多集群、自动发现、参数化 → 用 ApplicationSet。两者可以共存用 App of Apps 部署一个 ApplicationSet或者用 ApplicationSet 管理一组 App of Apps 仓库。7. 高级变体与自举Bootstrap7.1 分层 App of Apps你可以有多个根应用分别管理不同类别的服务textbootstrap/ ├── 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 的安装和配置textbootstrap/ └── bootstrap-root.yaml → 指向 argocd/ 目录该目录中包含 argocd 的 Helm Chart 或 Application YAML新集群只需要执行bashkubectl apply -f bootstrap-root.yamlArgo 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 有了更清晰的认识欢迎点赞、收藏。你是否也在使用这套模式有什么踩坑经验评论区等你分享