GitOps：ArgoCD / Flux

GitOps 是什么

由 Weaveworks（Flux 出品方）在 2017 年提出的概念。2021 年 CNCF 启动 GitOps Working Group，OpenGitOps 项目随后整理出 4 条原则（v1.0 在 2022 年发布）：

声明式（Declarative）：系统由声明式描述定义
版本化、不可变（Versioned and Immutable）：状态以 git 为权威来源
自动拉取（Pulled Automatically）：软件代理从 git 拉到目标系统
持续 reconcile（Continuously Reconciled）：代理监测漂移并修正

简单说：git 是真相，集群追上 git。

与传统 CI/CD 的差别

传统 push 模式
  CI → kubectl apply → 集群

GitOps pull 模式
  CI → 推 image
       ↓
  改 git（更新 image tag）
       ↓
  Argo/Flux 在集群里持续监听 git
       ↓
  发现差异 → 自动 apply

关键差异：

维度	Push CI/CD	GitOps
谁触发 apply	CI 主动 push	集群 agent 主动 pull
凭据存哪	CI 拥有集群凭据	集群只读 git
漂移修正	没有	自动 reconcile
回滚	重新跑 CI	git revert + 自动 reconcile
单一真源	部分（image tag 在哪？）	git

ArgoCD vs Flux

两家都是 CNCF Graduated（毕业项目，2022 年同年毕业）。

维度	ArgoCD	Flux
UI	自带强大 Web UI	UI 弱（靠 CLI / 第三方）
多集群	一个 ArgoCD 管多集群（中央化）	每集群一个 Flux（去中心化）
App-of-apps	原生支持	用 Kustomization 实现
Helm 支持	强	强
学习曲线	中（UI 帮你看状态）	中-高（更 git 原生）
更受欢迎	一般认为 ArgoCD 用户更多	Flux 用户少但忠诚度高

没有"绝对更好"——选一个团队学得动的。

经典 ArgoCD 工作流

仓库结构：
  app-source/         应用代码
  app-config/         K8s yaml / Helm chart（GitOps 仓库）

CI（应用代码）
  push → build image → 推到 registry
       → 自动 PR 到 app-config 把 image tag 改成新值
       → Merge

ArgoCD
  在 app-config 仓库轮询（默认 3 分钟）
  发现 image tag 变了 → 自动 apply 到集群

ArgoCD 自带 Image Updater 也可以监听 registry 自动改 tag——但一般推荐 CI 改 git，理由是所有变更经过 git，审计干净。

App-of-apps 模式

一个"根 Application"指向一个目录，目录里每个文件都是另一个 Application：

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: root-app
spec:
  source:
    repoURL: https://github.com/me/gitops
    path: apps                 # 这个目录里都是 Application

新增一个微服务 = 在 apps/ 加一个 yaml + commit——不需要登录 ArgoCD 配置。

何时不上 GitOps

单体应用 + 没用 K8s：杀鸡用牛刀
小团队没人维护额外的 controller：增加运维负担
紧急修生产 bug 时绕不过 git：有的团队需要"hotfix 直接生产 + 后补 git"——GitOps 这条流程会成为阻碍

几个坑

凭据 commit 到 GitOps 仓库：用 SealedSecrets 或 ESO，不要明文 Secret
drift 默认会自动修正：人工 kubectl apply 改的会被覆盖。这通常是好事，但临时调试时会困惑
多集群 + 单 ArgoCD 故障半径：ArgoCD 挂了所有集群停部署。考虑 HA 部署 + 多副本