Flux 项目概览与架构演进：Flux v1 vs Flux v2

Flux 是 Weaveworks 开源的 GitOps 工具集，也是最早将“Git 作为单一事实来源”理念落地的 CNCF 毕业项目。从 Flux v1 到 Flux v2 的演进，不仅是组件重构，更是对多集群、多租户、多工具链场景的深度适配。本节从项目概览、版本对比、组件家族和架构图四个维度，帮助你建立对 Flux 的全局认知。

1. Flux v1 vs Flux v2：核心差异

Flux v1 采用“一体化”架构，所有逻辑集中在单个二进制中；Flux v2 则拆分为多个独立控制器，每个控制器遵循 Kubernetes Operator 模式，职责单一、可独立升级和替换。下表从关键维度对比两个版本：

2. Flux v2 组件家族

Flux v2 由四个核心控制器组成，每个控制器负责 GitOps 流水线中的一个独立阶段。下图展示了组件之间的协作关系：

3. 核心控制器详解

3.1 Source Controller

Source Controller 是 Flux 的“入口”，负责从外部来源拉取配置并生成不可变的 Artifact。支持的来源类型包括：

• GitRepository：支持 SSH、HTTPS、自定义 CA 证书，可配置分支、标签、提交 SHA。
• OCIRepository：从 OCI 兼容的容器镜像仓库拉取配置层。
• Bucket：从 S3、GCS、MinIO 等对象存储拉取静态文件。

Source Controller 将拉取的内容打包为 Artifact，存储在控制器本地缓存中，并通过 Status.Artifact 字段暴露下载 URL。下游控制器（Kustomize/Helm）通过引用 Source 的 apiVersion 和 kind 来消费这些 Artifact。

3.2 Kustomize Controller

Kustomize Controller 是 Flux 的“编排引擎”，负责将 Source Controller 产出的 Artifact 进行 Kustomize 渲染并应用到集群。核心 CRD 是 Kustomization，支持以下关键字段：

apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: app-config
spec:
  sourceRef:
    kind: GitRepository
    name: app-repo
  path: ./overlays/production
  prune: true
  interval: 5m
  retryInterval: 2m
  timeout: 3m
  postBuild:
    substitute:
      env: production
    substituteFrom:
      - kind: ConfigMap
        name: cluster-vars

Kustomize Controller 会持续对比集群实际状态与 Artifact 中定义的期望状态，自动执行 kubectl apply 或 kubectl delete 操作。

3.3 Helm Controller

Helm Controller 为 Flux 提供了原生的 Helm 发布能力，核心 CRD 是 HelmRelease。它支持：

• Chart 来源：可引用 HelmRepository（标准 Chart 仓库）、OCIRepository（OCI 制品）或 GitRepository（本地 Chart 目录）。
• Values 管理：支持内联 values、ConfigMap/Secret 引用、多值合并。
• 发布策略：支持升级、回滚、测试、卸载等生命周期操作。

apiVersion: helm.toolkit.fluxcd.io/v2
kind: HelmRelease
metadata:
  name: nginx-ingress
spec:
  chart:
    spec:
      chart: nginx-ingress
      sourceRef:
        kind: HelmRepository
        name: ingress-nginx
  interval: 1h
  values:
    controller:
      replicaCount: 3

3.4 Notification Controller

Notification Controller 负责将 Flux 的发布事件、告警和状态变更推送到外部系统。它通过 Provider CRD 定义通知目标，通过 Alert CRD 定义触发条件：

apiVersion: notification.toolkit.fluxcd.io/v1
kind: Provider
metadata:
  name: slack-alerts
spec:
  type: slack
  address: https://hooks.slack.com/services/xxx
---
apiVersion: notification.toolkit.fluxcd.io/v1
kind: Alert
metadata:
  name: deploy-failure
spec:
  providerRef:
    name: slack-alerts
  eventSeverity: error
  eventSources:
    - kind: Kustomization
      name: '*'

4. Flux v2 架构总览

下图展示了 Flux v2 在 Kubernetes 集群中的完整架构，包括 CRD 层级、控制器交互以及外部系统集成：

5. 版本演进与迁移路径

Flux v1 已于 2022 年进入维护模式，Flux v2 成为主要演进方向。从 v1 迁移到 v2 的核心步骤包括：

1. CRD 迁移：将 v1 的 FluxHelmRelease 等自定义资源转换为 v2 的 HelmRelease 和 Kustomization。
2. 同步方式变更：从 SSH 轮询改为 Source Controller 的 webhook 或定时间隔拉取。
3. 多租户重构：利用 v2 的命名空间隔离和 RBAC 实现更细粒度的权限控制。
4. 通知系统升级：从 fluxctl 手动通知改为 Notification Controller 自动推送。