企业官网建设流程全解析

ArgoCD进阶指南：多集群、ApplicationSet、自动更新与生产级最佳实践

把ArgoCD玩出花——从单集群管理到企业级GitOps平台的进阶之路

如果你已经看完了我的前两篇ArgoCD入门文章，并且成功在本地跑起了ArgoCD、体验了selfHeal和prune的神奇效果，那么恭喜你——你已经掌握了ArgoCD的基础操作。

但真实的生产环境远比一个单集群、单应用复杂得多：

• 公司可能有开发、测试、预发布、生产四套K8s集群

• 你的微服务架构可能有几十甚至上百个应用需要管理

• 每次代码构建后，需要自动更新镜像版本

• 不同团队需要不同的权限，不能所有人都能改生产环境

这篇文章，就是写给已经入门、想要把ArgoCD真正用起来的你。

一、多集群管理：一个ArgoCD管所有集群

为什么需要多集群管理？

在真实的企业场景中，你几乎不可能只面对一个Kubernetes集群。常见的布局是：

• 开发集群（dev）：开发人员自测用，可以随意折腾

• 测试集群（staging）：QA测试、集成测试用

• 预发布集群（pre-prod）：模拟生产环境的最后一道关卡

• 生产集群（prod）：真正的线上环境，谁敢乱动？

传统做法是：每个集群单独装一套ArgoCD，各自管理各自的应用。这带来了几个问题：

• 配置分散，难以统一管理

• 每个集群都要单独登录、单独查看状态

• 跨集群部署一致性难以保证

ArgoCD的解决方案是：一个ArgoCD实例作为“控制平面”，同时连接和管理多个Kubernetes集群。

如何添加远程集群？

添加集群的核心是在目标集群中创建一个ServiceAccount，然后把它的Token配置到ArgoCD中。

powershell

# 1. 在目标集群（比如生产集群）中创建ServiceAccount并绑定权限 kubectl apply -f - <<EOF apiVersion: v1 kind: ServiceAccount metadata: name: argocd-manager namespace: kube-system --- apiVersion: rbac.authorization.k8s.io/v1 kind: ClusterRoleBinding metadata: name: argocd-manager-role roleRef: apiGroup: rbac.authorization.k8s.io kind: ClusterRole name: cluster-admin subjects: - kind: ServiceAccount name: argocd-manager namespace: kube-system EOF # 2. 获取Token kubectl -n kube-system create token argocd-manager # 3. 在ArgoCD中注册该集群（通过UI或CLI） argocd cluster add <cluster-context-name>

添加完成后，在ArgoCD UI的Settings -> Clusters中就能看到所有已注册的集群了。

多集群管理的价值

多集群管理的真正价值在于一致性。你可以用一个Application同时部署到dev、staging、prod三个集群，确保三个环境的配置完全一致。而ArgoCD ApplicationSet正是实现这一目标的利器。

二、ApplicationSet：一个YAML批量生成应用

为什么要用ApplicationSet？

假设你有10个微服务，每个微服务要部署到dev、staging、prod三个环境。按照传统方式，你需要写30个Application YAML文件——枯燥、重复、容易出错，而且一旦要改某个通用配置，30个文件都得改一遍。

ApplicationSet就是为了解决这个问题而生的。

ApplicationSet允许你用一个模板 + 一个参数生成器，自动生成多个Application。

生成器（Generator）有哪些？

ArgoCD ApplicationSet提供了多种生成器，适应不同的场景：

实战：用List Generator为三个环境生成应用

假设你有dev、staging、prod三个环境，分别对应不同的集群、分支和values文件：

yaml

apiVersion: argoproj.io/v1alpha1 kind: ApplicationSet metadata: name: myapp-per-env namespace: argocd spec: generators: - list: elements: - env: dev cluster: https://dev.example.com namespace: myapp-dev targetRevision: develop values_file: values-dev.yaml - env: staging cluster: https://staging.example.com namespace: myapp-staging targetRevision: release values_file: values-staging.yaml - env: production cluster: https://prod.example.com namespace: myapp targetRevision: main values_file: values-prod.yaml template: metadata: name: 'myapp-{{env}}' spec: project: default source: repoURL: https://github.com/myorg/myapp.git targetRevision: '{{targetRevision}}' path: deploy helm: valueFiles: - '{{values_file}}' destination: server: '{{cluster}}' namespace: '{{namespace}}' syncPolicy: automated: prune: true selfHeal: true

这个ApplicationSet会自动生成三个Application：myapp-dev、myapp-staging、myapp-production，分别指向各自的集群、分支和配置文件。

进阶：用Cluster Generator自动适配所有集群

如果你的集群数量很多，List Generator就不够看了——每加一个新集群就要手动改YAML。这时候可以用Cluster Generator，它会自动发现ArgoCD中注册的所有集群：

yaml

apiVersion: argoproj.io/v1alpha1 kind: ApplicationSet metadata: name: guestbook namespace: argocd spec: generators: - clusters: selector: matchLabels: env: "production" # 只选打了production标签的集群 template: metadata: name: '{{.name}}-guestbook' spec: source: repoURL: https://github.com/argoproj/argo-cd.git targetRevision: HEAD path: applicationset/examples/list-generator/guestbook/{{.name}} destination: server: '{{.server}}' namespace: guestbook

当你添加一个新集群并打上env: production标签后，ApplicationSet会自动为新集群生成对应的Application，无需任何手动操作。

三、App of Apps：管理大规模微服务的终极模式

什么是App of Apps？

当你管理的应用从几个变成几十个时，ApplicationSet可能还不够——你需要一个更高层次的组织方式。

App of Apps（应用之应用）模式就是为此设计的：一个父Application负责管理和部署多个子Application。

可以这样理解：

• 传统方式：你手动创建10个Application YAML

• App of Apps：你创建一个“父Application”，它里面定义了10个“子Application”的Git路径，ArgoCD会自动根据这些路径创建并管理子应用

目录结构示例

text

gitops/ ├── apps/ │ ├── nginx-ingress/ │ │ └── application.yaml │ ├── cert-manager/ │ │ └── application.yaml │ ├── backend-api/ │ │ └── application.yaml │ └── frontend/ │ └── application.yaml └── app-of-apps.yaml # 父Application

父Application定义

yaml

apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: app-of-apps namespace: argocd spec: project: default source: repoURL: https://github.com/myorg/gitops.git targetRevision: main path: apps # 指向apps目录，里面每个子目录都是一个Application destination: server: https://kubernetes.default.svc namespace: argocd syncPolicy: automated: prune: true selfHeal: true

当ArgoCD同步这个父Application时，它会扫描apps/目录下的所有子Application定义，并自动创建/更新它们。

App of Apps的优势

• 模块化管理：每个子应用独立版本化、独立控制

• 可复用性：通过复制整个apps/目录就能克隆一套完整环境

• 集中可视性：一个页面看到所有应用的状态

• 完整的Git追溯：每次变更都有记录，可审计、可回滚

四、ArgoCD Image Updater：让镜像更新彻底自动化

痛点：镜像更新还得手动改YAML？

在之前的GitOps工作流中，CI（比如GitHub Actions）构建完新镜像后，需要手动或通过脚本修改Git仓库中的镜像Tag，然后提交推送，ArgoCD再同步部署。

这个环节打断了“完全自动化”的链条。

ArgoCD Image Updater就是为了填补这个空白而生的。

它是怎么工作的？

Image Updater的工作原理很简单：

1. 你在ArgoCD Application中添加注解（annotations），告诉Image Updater要监控哪些镜像

2. Image Updater定期轮询容器仓库，检查是否有新版本

3. 如果发现符合条件的新版本，它自动更新Application的镜像配置

4. ArgoCD检测到Application变化后，自动同步部署新版本

配置示例

首先，在你的Application中添加注解：

yaml

apiVersion: argoproj.io/v1alpha1 kind: Application metadata: name: myapp annotations: argocd-image-updater.argoproj.io/image-list: myapp=nginx:latest argocd-image-updater.argoproj.io/myapp.update-strategy: semver argocd-image-updater.argoproj.io/myapp.allow-tags: regexp:^v\d+\.\d+\.\d+$ spec: # ... 其他配置

这些注解的含义是：

• image-list：指定要监控的镜像列表

• update-strategy：更新策略（semver表示遵循语义化版本，latest表示最新构建，name表示按字母顺序）

• allow-tags：只允许匹配特定正则表达式的Tag（比如只允许v1.2.3这种格式）

支持的策略

Image Updater支持多种更新策略：

完整工作流

有了Image Updater，完整的GitOps自动化闭环就打通了：

text

代码提交 → CI构建新镜像 → 推送到镜像仓库 ↓ Image Updater检测到新版本 ↓ 自动更新Git中的镜像Tag ↓ ArgoCD检测到Git变化 ↓ 自动部署新版本到集群

全程无需任何人工干预。

五、安全与权限控制：生产环境不能裸奔

当你把ArgoCD开放给多个团队使用时，安全和权限控制就成了刚需。

RBAC（基于角色的访问控制）

ArgoCD自带了RBAC功能，可以精细控制不同用户/团队对资源的访问权限。

ArgoCD默认只有两个内置角色：

• readonly：所有资源的只读权限

• admin：所有资源的完全访问权限

你可以定义自定义角色，并映射到SSO用户组或本地用户。

RBAC策略的格式如下：

text

p, <角色/用户/组>, <资源>, <操作>, <对象>

例如，给dev-team组授予对dev项目下所有应用的同步权限：

text

p, dev-team, applications, sync, dev/*

SSO（单点登录）

RBAC需要配合SSO或本地用户配置使用。ArgoCD支持通过Dex对接各类身份提供商：

• GitHub / GitLab（OAuth2）

• Google OAuth2

• OpenID Connect（OIDC）

• LDAP / Active Directory

配置SSO后，团队成员可以用公司统一的账号登录ArgoCD，权限由RBAC策略控制。

多租户隔离：AppProject

ArgoCD的AppProject资源可以实现多租户隔离。每个Project可以：

• 限制允许部署的目标集群和命名空间

• 限制允许使用的Git仓库源

• 限制允许使用的资源类型

• 设置同步窗口（比如生产环境只允许在特定时间段同步）

六、监控与告警：让ArgoCD自己“被监控”

ArgoCD能监控你的应用，但谁来监控ArgoCD自己？

Prometheus指标

ArgoCD原生暴露了Prometheus格式的监控指标：

• 应用指标（argocd-metrics:8082/metrics）：应用健康状态、同步状态、同步历史等

• API Server指标（argocd-server-metrics:8083/metrics）：API请求总量、响应码分布等

核心指标是argocd_app_info，包含了health_status和sync_status两个关键标签。

关键告警规则

你可以配置以下告警：

• 应用长时间处于Degraded状态：说明应用有问题

• 应用长时间OutOfSync：说明同步卡住了

• 同步失败次数过多：可能是配置错误或集群问题

• 控制器内存/CPU过高：可能需要扩容

Grafana Dashboard

ArgoCD官方提供了一个Grafana Dashboard模板，可以直接导入使用，可视化展示所有应用的健康状态、同步状态、同步耗时等关键指标。

七、总结：从入门到进阶的完整路线图

回顾一下你从入门到进阶的完整学习路径：

一句话总结

ArgoCD不止是一个部署工具，它是一个企业级GitOps平台。从单集群到多集群，从几个应用到几百个应用，从手动更新镜像到全自动闭环——ArgoCD都有对应的解决方案。

把这篇文章里的知识消化掉，你就从一个“会用ArgoCD的小白”，变成了一个“能设计GitOps平台架构的工程师”。

如果觉得有用，点个赞让更多人看到吧！有任何问题欢迎在评论区交流讨论。🚀

本文是ArgoCD系列文章的第三篇。前两篇：入门篇：10分钟搞懂ArgoCD | 排坑篇：ArgoCD到底运行在哪里