Argo CD 与 Flux — 单一应用控制器与多控制器组合

一句话总结

Argo CD 由 API 服务器、仓库服务器、应用控制器这三个部件围绕名为 Application 的一种资源运转，Flux 则由 source、kustomize、helm、notification、image 控制器各自负责自己的 CRD 组合而成。通知和指标在两种工具中都通过标准方式（注解/CRD、Prometheus）接入。

为什么需要它

CGOA 的 Tooling 领域（14%）并不止于知道“调谐器有 Argo CD 和 Flux”。它要问的是：两种工具用不同的结构实现了同样的原则，所以处理 Helm 的方式不同、有没有 UI 不同、解决多租户的方式也不同。在实际工作中选择工具时，与其问“哪个更好”，不如问“我们团队适合哪种结构”，这更接近答案。

工作原理

Argo CD——三个部件与 Application

这是官方架构文档中的三个组件。API 服务器是 gRPC/REST 服务器，提供 Web UI、CLI、CI/CD 系统使用的 API，负责应用管理与状态报告、sync 和 rollback 等操作的调用、仓库与集群凭据管理（K8s Secret）、委托外部 IdP 认证、RBAC，以及接收 Git Webhook。仓库服务器维护 Git 仓库的本地缓存，以仓库 URL、revision、路径、模板配置（parameters、values）为输入生成清单。应用控制器持续监视运行中的应用，比较实际状态与期望状态，检测 OutOfSync，并调用 PreSync、Sync、PostSync 钩子。

Git/Helm/OCI  ──►  repo-server (렌더: helm template / kustomize build)
                        │
                        ▼
              application-controller ──► 클러스터(들)   비교·sync·훅
                        ▲
UI / CLI / CI  ──►  api-server (RBAC, 인증, 웹훅 수신)

Flux——GitOps Toolkit 的控制器组合

Flux 是称为“GitOps Toolkit”的一组专用控制器、可组合的 API 和 Go 包，每个控制器只负责自己的 CRD。

控制器	CRD	负责的事情
source-controller	GitRepository, OCIRepository, HelmRepository, HelmChart, Bucket	定期检查来源，生成制品（tar.gz）并在集群内提供
kustomize-controller	Kustomization	用 Kustomize 构建制品并应用，SOPS 解密，服务账号模拟（impersonation），健康评估，depends-on 顺序，清理已移除的对象（prune）
helm-controller	HelmRelease	用 HelmChart 制品执行真正的 Helm 操作（安装、升级、测试、回滚、卸载），失败时自动补救
notification-controller	Provider, Alert, Receiver	接收外部事件（Receiver）来唤醒调谐，并把控制器事件发往外部（Provider/Alert）
image-reflector/automation	ImageRepository, ImagePolicy, ImageUpdateAutomation	扫描注册表，找到符合策略的新标签，并以提交回写到 Git

Source 定义“仓库的来源以及获取它的条件（凭据、版本选择器）”，按设定的间隔检查，发现新版本就生成新的制品。一个 source 可以被多个消费者共享。Kustomization 默认每 5 分钟调谐一次，通过 kubectl edit/patch/delete 改动的内容很快会被恢复原状。所有 Flux CRD 都注册在资源类别中，因此用一次 kubectl get fluxcd -A 就能全部查看。bootstrap 是把 Flux 组件本身以 GitRepository 和 Kustomization 的形式应用，让 Flux 管理它自己的过程。

结构带来的差异

最常被问到的差异是 Helm。Argo CD 只用 helm template 来展开，生命周期由自己直接管理，所以不依赖 Helm release 历史和 Helm 钩子语义。Flux 的 helm-controller 监视 HelmRelease，实际执行 Helm 安装和升级，并提供包括 Helm 测试和回滚在内的自动补救（remediation）。第二是界面。Argo CD 的 API 服务器和 Web UI 是核心组件，Flux 则以 CLI 为基础，UI 通过 Flux Operator、Capacitor、Headlamp 插件、Weave GitOps 等独立项目列表来介绍。第三是多租户。Flux 通过“借助模拟（impersonation）实现的真正 Kubernetes RBAC”，为每个 Kustomization 指定服务账号，Argo CD 则用 AppProject 和自己的 RBAC 来划分。

通知——把什么接在哪里

Argo CD Notifications 监视应用状态变化，用触发器和模板生成通知。目录中有现成可用的触发器和模板，服务注册在 argocd-notifications-cm 与 argocd-notifications-secret 中，订阅则通过 Application 或 Project 上像 notifications.argoproj.io/subscribe.on-sync-succeeded.slack: <채널>（占位符为频道名称）这样的注解来设置。Flux 是由控制器在每次资源状态变化时产生 Kubernetes 事件，再由 notification-controller 通过 Provider（type: slack 等，secretRef）和 Alert（providerRef，用 eventSources 选择 kind/name，eventSeverity 为 info/error）把它发往外部。GitHub、GitLab、Gitea、Bitbucket、Azure DevOps 这些提供方，不同之处在于它们不是发到聊天工具，而是回写为提交状态。

可观测性——Prometheus 指标

Argo CD 的每个服务器输出不同的指标集合，应用控制器指标从 argocd-metrics:8082/metrics 抓取。有代表性的是 argocd_app_info（带有 sync_status、health_status 标签的 gauge）、argocd_app_sync_total（counter）、argocd_app_reconcile（histogram）。Flux 控制器默认在端口 8080 的 /metrics 上输出 gotk_reconcile_duration_seconds_bucket{kind,name,namespace,le} 之类的调谐耗时直方图和 controller_runtime_reconcile_total{controller,result}。Flux 资源本身的状态指标不是由控制器输出，而是用 kube-state-metrics 收集，flux2-monitoring-example 仓库提供了现成的配置。

与 CI 的联动

两种工具都不运行 CI。联动点有三个。第一，CI 改动 Git 之后，通过 Webhook 把调谐提前（Argo CD /api/webhook，Flux Receiver）。第二，Argo CD 的 API 服务器是供 CI/CD 系统调用的 API，所以流水线可以请求 sync 或查询状态。第三，Flux 的镜像自动化会发现 CI 推送到注册表的新标签，并以提交回写到 Git，因此即使 CI 不修改清单，部署也能继续进行。无论哪种情况，修改集群的主体都只有调谐器一个。

在现场相遇的样子

使用 Argo CD 的团队经常问“明明是 Synced，实际 Pod 却是旧镜像”。原因通常不在调谐器，而在它之前：CI 没有修改标签，仓库服务器的缓存还是旧 revision，或者 Webhook 没有到达，正在等待 3 分钟的轮询。在指标中同时查看 argocd_app_info 的 sync_status 和 Git 的最新提交，就能分出停在了哪个阶段。

在 Flux 中，先看 kubectl get fluxcd -A 大多就能得到答案。GitRepository 不是 Ready，就在 source 阶段；Kustomization 不是 Ready，则卡在构建、应用、健康评估中的哪一步，会写在条件（condition）里。

下一项测验要确认什么

测验会问：IaC、CI/CD 与 GitOps 的边界，Webhook 如何与 pull 原则兼容，in-cluster 与 external 调谐器的凭据位置，渐进式交付与 Git 声明的关系，Argo CD 三个部件的作用，Flux 控制器与 CRD 的对应，处理 Helm 的方式差异，以及通知、指标接入的位置。参考：Argo CD Architectural Overview、GitOps Toolkit components、Argo CD Notifications、Flux alerts、Argo CD Metrics、Flux Prometheus metrics。