GitOps 实战：ArgoCD 与 Flux 的 Kubernetes 持续部署

GitOps 这个概念在 Kubernetes 场景里已经不算新鲜，但真正落到选型的时候，ArgoCD 和 Flux 仍然是大多数团队绕不开的两个名字。很多团队不是不知道 GitOps 的价值，而是在这两个工具之间反复权衡。这里有一个容易被忽略的事实：它们虽然都叫 GitOps 工具，但设计思路、工作模型和适合的组织形态其实差别很大。

先想清楚一个问题：为什么 GitOps 在 Kubernetes 里特别合适。Kubernetes 的声明式 API 天然适合以 Git 作为唯一事实源。它不是把 YAML 推送到集群，而是让集群里的控制器自己从 Git 拉取期望状态，再通过 reconciliation 收敛当前状态。这个机制决定了 GitOps 不是一套流程规范，而是一种架构能力。选型 ArgoCD 还是 Flux，本质上是在选一种你愿意长期依赖的协调模型。

ArgoCD 和 Flux 的设计起点并不相同

ArgoCD 是从应用交付的视角出发的。它把每一个部署单元抽象成一个 Application，提供完整的 Web UI、同步历史和 diff 视图。它的核心假设是：会有人需要盯着界面看，确认某个应用当前处于什么状态。

Flux 则完全是另一条路线。Flux v2 从一开始就定位成一组可拼装的控制器集合，source-controller 负责拉取 Git 仓库和 Helm 仓库，kustomize-controller 负责渲染并应用 Kustomize 资源，helm-controller 负责管理 HelmRelease。默认没有 UI，一切通过 kubectl 和 Git 仓库交互。它的核心假设是：系统应该自己协调，人只需要在异常时介入。

这个差异会直接影响你团队的使用方式。如果你有一群不熟悉 kubectl 的研发同事，ArgoCD 的 UI 几乎是刚需；如果你的平台团队面对的是几十个集群，那 Flux 这种没有中心控制面的架构反而更省心。

核心模型：从 Application 到控制器组合

ArgoCD 的部署单元是 Application CRD。你需要在集群里创建一个 Application 资源，指定代码仓库、目标路径、目标集群和同步策略。控制器会定期检查 Git 仓库中的状态，与集群实际状态做 diff，发现漂移后自动或手动 sync。

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: payment-service
  namespace: argocd
spec:
  project: platform
  source:
    repoURL: https://github.com/example/team-manifests
    targetRevision: main
    path: services/payment-service
  destination:
    server: https://kubernetes.default.svc
    namespace: payment
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
      - CreateNamespace=true

这段配置表达的事情是：从主分支的 services/payment-service 目录读取期望状态，部署到 payment 这个 namespace，并开启自动同步和自动清理。注意 automated.prune 这个选项，它意味着从 Git 中删除的资源配置也会从集群中移除。很多刚上手 ArgoCD 的团队会纠结要不要开 prune，从经验看，在建立了代码评审机制之后，开 prune 是更符合 GitOps 预期的行为。

Flux v2 的写法是另一个风格。GitRepository 和 Kustomization 是分开的两个资源，你可以让多个 Kustomization 引用同一个 GitRepository，也可以让 Kustomization 从不同来源拉取内容。这种解耦让多租户场景下的权限设计更灵活。

apiVersion: source.toolkit.fluxcd.io/v1
kind: GitRepository
metadata:
  name: platform
  namespace: flux-system
spec:
  interval: 1m
  url: https://github.com/example/team-manifests
  ref:
    branch: main
---
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: payment-service
  namespace: flux-system
spec:
  interval: 5m
  path: ./services/payment-service
  prune: true
  sourceRef:
    kind: GitRepository
    name: platform

两个工具都在做同一件事——让 Git 成为唯一事实源，但抽象层级完全不同。ArgoCD 把应用当作一等公民，Flux 把资源源和资源生成当作一等公民。这个区别在你需要精细控制部署粒度时会变得非常重要。

关键差异对比

表格里的对比不代表谁更好，而是指向不同的使用场景。ArgoCD 的集中式管理在多集群时很直观，但也会引入单点——ArgoCD 本身挂了，所有集群的同步操作都会受影响。Flux 每个集群独立运行，反而更符合 Kubernetes 的自治理念。

三个容易踩坑的地方

GitOps 不等于把 YAML 放进 Git

很多团队把 manifest 塞进仓库就不管了，集群里的状态漂移无人发现。GitOps 的核心不是静态文件管理，而是持续协调。没有控制器去对比期望状态和实际状态，Git 仓库只是一个备份目录而已。这里常见的问题是：手动 kubectl apply 之后，集群状态已经偏离 Git，但 ArgoCD 或 Flux 的 diff 会一直报错，团队又没有处理漂移的流程，时间一长大家就不看同步状态了。

Helm 支持方式不是一回事

ArgoCD 的 Helm 支持是把 chart 拉到本地渲染，再把渲染后的结果作为目标状态。Flux 的 HelmRelease 则是通过 Helm 控制器直接协调 release 状态。这意味着，如果你大量依赖 Helm 的 hooks、依赖处理，或者需要保留 Helm release 的历史状态，Flux 会自然一些。而如果你的主力是 Kustomize 和纯 YAML，ArgoCD 的 diff 和 UI 会让日常操作更顺手。不要因为两个工具都写了支持 Helm 就认为体验一样。

CI 和 CD 的边界必须提前定好

实际项目中，GitOps 工具负责的是 CD 后半段——把已经构建好的镜像部署到集群。镜像构建和推送到仓库仍然是 CI 的事情。常见的问题是团队把镜像 tag 写成 latest，导致 Git 仓库里的配置无法准确表达当前部署版本。比较稳的做法是 CI 在构建完成后更新 Git 仓库中的 manifest 或 values 文件，然后让 GitOps 工具自动拉起部署。Flux 的 image automation controller 可以自动更新 tag，这是它相对独特的能力，但自动更新也意味着 Git 仓库内容可能被控制器修改，需要配合审计机制。

什么情况下选择 ArgoCD 或 Flux

一个 50 人左右的研发团队，服务数量不到 30 个，刚开始推 GitOps。这时候最需要的不是复杂的控制器编排，而是让研发同学能直观看到自己提交的 PR 合并之后，集群里的状态发生了什么变化。ArgoCD 的 UI 在这个阶段几乎是决定性的，因为 diff 能力直接降低了团队的学习门槛。团队不需要理解 GitOps 的底层机制，只要会看界面就能完成日常发布。

另一个场景是负责多个集群的平台团队。管理着 4 个以上的生产集群，每个集群有上百个 Helm release。这个规模下，ArgoCD 的 UI 反而会成为瓶颈——你不可能靠人肉盯着 UI 去发现几十个集群里的漂移。Flux 的做法是让所有控制器只围绕 Git 仓库工作，集群里的状态变化通过 notification-controller 发送到 Slack 或自定义 webhook，团队只需要在事件发生时介入。Flux 的 tenant 模型还允许不同团队在各自 namespace 内管理自己的 Kustomization，权限隔离比较干净。

如果你还在纠结，可以按这个思路判断：团队是否依赖可视化界面做日常操作？是，就选 ArgoCD。是否面临多集群、多租户、高度自动化的压力？是，就优先评估 Flux。两个都满足，那就看你们对 Helm 的依赖程度。

落地路径：从试点到铺开

GitOps 工具选型不是一次性决策，落地方式更重要。建议先在非生产集群试运行，不要一上来就双跑生产。从少量服务开始，比如先迁移 2-3 个业务服务，跑通完整流程再铺开。这里有几个实操建议：

• 为 Git 仓库设计清晰的目录结构，建议 apps/ 和 infrastructure/ 分开，业务应用和集群基础组件不要混在一个目录里。
• 把 Git 仓库的提交权限和代码评审绑定，避免直接 push 到主分支。GitOps 的可靠性建立在 Git 历史可追溯的基础上。
• 在团队内约定同步策略：哪些应用允许自动同步，哪些需要手动确认。自动同步省事，但生产环境的核心应用建议保留人工审批步骤。
• 如果选择 ArgoCD，提前规划好 Project 和 RBAC；如果选择 Flux，先设计好 namespace 的租户边界。

当你发现团队开始出现这些信号——手动 diff 次数变多、需要频繁通过 UI 干预同步、多集群数量增加导致运维成本上升——就是时候重新评估当前工具是否还匹配团队规模了。工具本身不会限制你的发展，但错误的抽象层级会让你在扩展时付出额外的成本。

GitOps 的价值不是工具带来的，而是“以 Git 为唯一事实源 + 持续协调”这套机制带来的。工具只是帮你把这个机制落地得更好。

选 ArgoCD 还是 Flux，本质上不是比功能多少，而是看你的团队怎么理解交付这件事。ArgoCD 把 GitOps 做成了一套可观测、可操作的应用交付系统，适合需要视觉反馈和集中管控的团队。Flux 把 GitOps 做成了一组可拼装的自动化控制器，适合多集群、多租户、高度自动化的环境。理解这一点，选型就不会纠结于某个功能的缺失，而是看哪个工具更匹配你团队的工作方式。