Flux vs ArgoCD：GitOps 工具深度对比与 Flux 上手实战

为什么写这篇

团队已经习惯“改 Git -> 自动部署”，但在选 Flux 还是 ArgoCD 时常纠结。这里用一句话对比二者，再用 Flux 做一遍最小可行的部署，让你 10 分钟看到效果。

一句话对比

维度	Flux	ArgoCD
核心模型	控制器拉取 Git，自动和解（reconcile）	控制面 + UI，拉取/同步 Git
UI/可视化	依赖 CLI + 可选 Weave GitOps UI	自带 UI，回滚/对比方便
多集群	GitRepository + Kustomization 可多集群；也有 fleet 模式	ArgoCD Application/Project，支持多集群；App of Apps 常用
Helm/Kustomize 支持	原生支持 HelmRelease/Kustomization CRD	原生支持，两者都能跑
权限与隔离	依赖 Kubernetes RBAC，Flux 控制器按 Namespace 隔离	基于 Argo Project，多租户更直观

结论：

想要“全 CRD、轻量、少 UI、强调声明式”的体验，选 Flux。
想要“开箱 UI + 回滚/对比可视化、团队新人上手快”，选 ArgoCD。

下方用 Flux 跑一个 demo，让你感受它的工作流。

安装 Flux（CLI + 控制器）

安装 CLI（macOS 示例）：

brew install fluxcd/tap/flux
flux --version

安装控制器到集群（全局模式）：

kubectl create namespace flux-system --dry-run=client -o yaml | kubectl apply -f -
flux install --namespace=flux-system
kubectl -n flux-system get pods

准备 Git 仓库并接入

创建一个示例仓库（本地或 GitHub），目录结构如下：

GitOps-demo/
  90-flux/
     amespace.yaml
  demo/
    kustomization.yaml
    deployment.yaml
    service.yaml

namespace.yaml（目标应用命名空间）：

apiVersion: v1
kind: Namespace
metadata:
  name: demo

demo/deployment.yaml：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
  namespace: demo
spec:
  replicas: 1
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: web
        image: nginx:1.25
        ports:
        - containerPort: 80

demo/service.yaml：

apiVersion: v1
kind: Service
metadata:
  name: web
  namespace: demo
spec:
  selector:
    app: web
  ports:
  - port: 80
    targetPort: 80

demo/kustomization.yaml：

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- deployment.yaml
- service.yaml

把仓库推到 Git（以 GitHub 为例）：

git init && git add . && git commit -m "init"
git remote add origin git@github.com:<you>/gitops-demo.git
git push -u origin main

让 Flux 追踪这个仓库并部署

创建 GitRepository 资源：

flux create source git gitops-demo \
  --url=https://github.com/<you>/gitops-demo \
  --branch=main \
  --interval=1m \
  --namespace=flux-system

创建 Kustomization，指向仓库里的 demo/：

flux create kustomization demo \
  --target-namespace=demo \
  --source=GitRepository/gitops-demo \
  --path="./demo" \
  --prune=true \
  --interval=1m \
  --namespace=flux-system

等待同步：

flux get all -n flux-system
kubectl -n demo get deploy,svc

如果看到 web Deployment 和 Service 都跑起来了，说明 GitOps 生效。

修改代码并验证自动同步

在本地修改 deployment.yaml（比如 replicas 改为 2，版本改为 1.25.3）：

sed -i '' 's/replicas: 1/replicas: 2/' demo/deployment.yaml

提交推送：

git commit -am "scale to 2" && git push

等待 Flux 检测到变更：

flux get kustomization demo -n flux-system
kubectl -n demo get deploy web -w

副本应自动变为 2，无需手工 kubectl apply。

排障清单

同步失败：flux logs -f --level=error 查看错误，多为仓库地址/权限或 YAML 解析问题。
资源未更新：确认 Kustomization 的 path、prune 和 interval；GitRepository 是否能拉到最新 commit。
权限问题：Flux 控制器默认 ClusterRole，若按 Namespace 限制，需要调整 RBAC 以允许创建目标资源。

小结与用法扩展

ArgoCD vs Flux：前者 UI 强、回滚方便，后者全 CRD，轻量无中心化 UI，选哪个看团队习惯。
实践落地：把 Helm charts 也交给 Flux（HelmRelease CRD），或用 Image Update Automation 实现“镜像更新 -> 自动改 Git -> 自动部署”的闭环。
生产要点：把 Flux/Argo 控制器与业务隔离命名空间；开启审计日志；对关键资源用 Drift 检测报警。

按照上述步骤，你可以在真实集群快速体验 Flux 的 GitOps 流程，确认它能自动拉取、对比并同步 Git 里的配置。后续根据团队偏好再决定留在 Flux，或迁移到提供 UI 的 ArgoCD。EOF

为什么写这篇​

一句话对比​

安装 Flux（CLI + 控制器）​

准备 Git 仓库并接入​

让 Flux 追踪这个仓库并部署​

修改代码并验证自动同步​

排障清单​

小结与用法扩展​