21-FluxCD

FluxCD 是 CNCF 毕业的 GitOps 工具，与 ArgoCD 并列。Flux 走的是"控制器优先、CRD 即 API"路线——没有重 UI、没有单体 server，五个 GitOps Toolkit 控制器各司其职。本章覆盖 Flux 的核心架构、Source/Reconciler 模型、Helm/Kustomize 集成、镜像自动化，以及与 ArgoCD 的选型对比。

架构：五大控制器#

Flux v2 把自己拆成五个独立的控制器，每个都是独立的 Deployment，只管自己的一组 CRD：

text
                ┌─────────────────────────┐
                │    Git / OCI / Bucket   │
                └───────────┬─────────────┘
                            ▼
                ┌──────────────────────────┐
                │   source-controller      │  CRD: GitRepository,
                │   拉源码、缓存、通知 ready │       OCIRepository,
                └───────────┬──────────────┘       HelmRepository
              ┌─────────────┴─────────────┐
              ▼                           ▼
  ┌──────────────────────┐   ┌──────────────────────┐
  │ kustomize-controller │   │   helm-controller    │
  │ CRD: Kustomization   │   │ CRD: HelmRelease     │
  └──────────┬───────────┘   └──────────┬───────────┘
             └───────────┬──────────────┘
                         ▼
                 ┌──────────────────┐
                 │  Kubernetes API  │
                 └────────┬─────────┘
             ┌────────────┴────────────┐
             ▼                         ▼
  ┌───────────────────────┐  ┌────────────────────────┐
  │ notification-ctrl     │  │ image-reflector-ctrl / │
  │ Provider/Alert/Receiver│  │ image-automation-ctrl  │
  └───────────────────────┘  └────────────────────────┘

source-controller：拉 Git/OCI/Helm 仓库内容，生成 artifact（tar 包），通过内置 HTTP 暴露。
kustomize-controller：消费 artifact，执行 kustomize build 后 server-side apply。
helm-controller：消费 HelmChart artifact，执行真正的 Helm install/upgrade。
notification-controller：分发事件到 Slack/钉钉/Webhook，也接收外部 Webhook 触发 reconcile。
image-reflector/image-automation-controller：监听镜像仓库新版本，自动提 commit 回 Git。

关键：控制器之间无强耦合，任何一个挂了不影响别的。所有用户交互通过 CRD 完成，flux CLI 只是"生成 YAML + kubectl apply"的便利工具。

Source：源码订阅#

Flux 把"源"抽成独立的 CRD 类型，"源"和"如何使用源"彻底解耦：

yaml
apiVersion: source.toolkit.fluxcd.io/v1
kind: GitRepository
metadata:
  name: platform-config
  namespace: flux-system
spec:
  interval: 1m
  url: https://github.com/example-org/platform-config
  ref:
    branch: main

source-controller 拉完后生成 artifact 文件（tar.gz），下游控制器通过 in-cluster 网络拿这个 tar 包，不再重新连 Git。一个 GitRepository 只拉一次，多个 Kustomization 复用 artifact，Git 请求次数压到最低。

支持的 Source 类型：GitRepository、OCIRepository（从 OCI 镜像仓库拉 tar layer）、HelmRepository、HelmChart、Bucket（从 S3/GCS 拉）。

Kustomization：同步语义#

yaml
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: frontend
  namespace: flux-system
spec:
  interval: 5m                # reconcile 周期，每个应用单独配
  targetNamespace: team-alpha
  sourceRef:
    kind: GitRepository
    name: platform-config
  path: "./apps/frontend/overlays/production"
  prune: true                 # Git 里删除的资源从集群删除
  wait: true                  # 等待所有资源 Ready
  timeout: 5m
  healthChecks:
    - apiVersion: apps/v1
      kind: Deployment
      name: frontend
      namespace: team-alpha
  dependsOn:
    - name: infrastructure    # 必须等 infrastructure Kustomization 成功后才开始

关键语义：

interval：reconcile 周期。Flux 在每个间隔主动 apply 一次，即便 Git 没变，也会把集群状态收敛到渲染结果。per-resource interval 是 Flux 相比 ArgoCD 的优势——核心基础设施每 1 分钟 reconcile，业务应用每 10 分钟，CRD 每小时，把压力摊平。
prune: true：基于 label GC 删除 Git 里不存在的资源。
wait: true + healthChecks：apply 完等待所有资源 Ready 才认为成功。
dependsOn：显式拓扑依赖（CRDs → Namespaces → Apps），天然支持排序。

Helm 集成#

Flux 的 helm-controller 真的调用 Helm SDK 做 install/upgrade，创建真正的 Helm release，集群里能 helm ls 看到——这是 Flux 相比 ArgoCD 在 Helm 支持上的核心优势。

yaml
apiVersion: source.toolkit.fluxcd.io/v1
kind: HelmRepository
metadata:
  name: example-charts
  namespace: flux-system
spec:
  interval: 10m
  url: https://charts.example.com
---
apiVersion: helm.toolkit.fluxcd.io/v2
kind: HelmRelease
metadata:
  name: frontend
  namespace: team-alpha
spec:
  interval: 5m
  releaseName: frontend
  chart:
    spec:
      chart: frontend
      version: "1.2.3"
      sourceRef:
        kind: HelmRepository
        name: example-charts
        namespace: flux-system
  install:
    remediation:
      retries: 3
  upgrade:
    remediation:
      retries: 3
      remediateLastFailure: true
    cleanupOnFail: true
  valuesFrom:
    - kind: ConfigMap
      name: frontend-values
      valuesKey: values.yaml
  postRenderers:               # 渲染完 apply 前插入 kustomize patch
    - kustomize:
        patches:
          - target:
              kind: Deployment
              name: frontend
            patch: |
              - op: add
                path: /spec/template/spec/priorityClassName
                value: production

postRenderers 是 Flux 的杀手锏——能在 Helm 渲染完之后、apply 之前插入 kustomize patches，修改第三方 chart 的任何字段，而不需要 fork chart。

Image Automation：镜像自动更新#

Flux 有两个专门的控制器处理镜像自动化——image-reflector-controller 扫镜像仓库存 tag 列表，image-automation-controller 按策略选 tag 后自动提 commit 改 Git：

yaml
apiVersion: image.toolkit.fluxcd.io/v1
kind: ImageRepository
metadata:
  name: frontend
  namespace: flux-system
spec:
  image: ghcr.io/example-org/frontend
  interval: 1m
---
apiVersion: image.toolkit.fluxcd.io/v1
kind: ImagePolicy
metadata:
  name: frontend
  namespace: flux-system
spec:
  imageRepositoryRef:
    name: frontend
  policy:
    semver:
      range: ">=1.0.0"
---
apiVersion: image.toolkit.fluxcd.io/v1
kind: ImageUpdateAutomation
metadata:
  name: platform-config
  namespace: flux-system
spec:
  interval: 5m
  sourceRef:
    kind: GitRepository
    name: platform-config
  git:
    checkout:
      ref:
        branch: main
    commit:
      author:
        email: gitops@example.com
        name: gitops-bot
      messageTemplate: |
        chore(auto): update images
    push:
      branch: main
  update:
    path: ./apps
    strategy: Setters

在 manifest 里用 setter 标记占位：

yaml
image: ghcr.io/example-org/frontend:1.2.3 # {"$imagepolicy": "flux-system:frontend"}

全链路闭环：新镜像 push → image-reflector 发现 → image-automation 选 tag + 提 commit → source-controller 发现 commit → kustomize-controller reconcile → 集群收敛。CI 只需 build + push 镜像，不需要改 manifest。

漂移检测#

Flux 天然持续收敛——每个 interval 都主动 apply，不看 diff。漂移自动被纠正，不需要像 ArgoCD 那样显式开 selfHeal。

多租户#

Flux 多租户的核心是 ServiceAccount impersonation。每个 Kustomization/HelmRelease 可指定 spec.serviceAccountName，控制器 apply 时以这个 SA 的身份执行：

yaml
spec:
  serviceAccountName: gitops-reconciler

K8s RBAC 本身就是 Flux 的 RBAC——不需要学新的权限模型。配合 --no-cross-namespace-refs=true 启动参数禁止跨命名空间引用，租户完全隔离。

推 vs 拉模式#

	Pull（Flux/Argo）	Push（Jenkins CI）
谁主动	集群内 controller 主动拉 Git	CI 拿 kubeconfig push
攻击面	CI 不需持有集群凭据	CI 持有 admin token
漂移纠正	持续 reconcile	apply 完就结束
多集群扩展	新集群装一次 controller	每新增集群给 CI 配 kubeconfig

GitOps 是 pull-based 的——这是 GitOps 与传统 CIOps 的分水岭。

vs ArgoCD 选型#

维度	FluxCD	ArgoCD
架构	五控制器解耦，无中央 server	server-first，重 UI
同步语义	per-resource interval，持续收敛	全局 resync，selfHeal 开关
Helm	真 Helm release + postRenderers	helm template（无真 release）
Kustomize	原生 + substituteFrom 变量注入	原生 + Lua 健康检查
多租户	K8s RBAC + impersonation，模型干净	AppProject + 自有 RBAC，两层权限
多集群	联邦模式（每集群一个 Flux）	中心化（一个 Argo 管 N 集群）
批量部署	Git 目录结构 + 脚手架	ApplicationSet + PR Generator
镜像自动化	一等公民，setter 标记	Image Updater（独立项目，补丁）
UI	无原生 UI（Grafana 自建）	强 UI，拓扑图/diff/一键 rollback
Secret 管理	原生 SOPS 解密	依赖 External Secrets/Sealed Secrets

决策树：

集群数多、跨 region/跨云、安全合规严 → Flux 联邦。
重度使用 Helm、需要 post-renderer 改第三方 chart → Flux。
强需求 UI、开发同学自助 sync、PR preview 环境 → ArgoCD。
已有 Argo 深度落地、团队熟悉 → 继续 Argo，别为技术洁癖迁移。
平台工程团队想把 CD 嵌入 IDP，通过 CRD 编程 → Flux。

小结#

FluxCD 的控制器优先架构更 Kubernetes-native——无中央 server 单点、per-resource interval 灵活、Helm 是真 release、多租户用 K8s 原生 RBAC。如果核心用户是平台工程团队、规模大/跨云/合规严、Helm 用得重，Flux 是更干净的选择。如果核心用户是开发同学、规模中小、强依赖 UI 体验，ArgoCD 更友好。两者都不存在放之四海皆准的最佳答案，选型应基于明确痛点而非技术审美。