Flux v2 核心组件架构深度解析

Flux v2 采用 多控制器、单一职责 的微架构设计，将 GitOps 工作流拆解为 源获取、资源构建、Helm 编排、事件通知 四个独立领域。每个控制器只关注自己的边界，通过自定义资源（CRD）进行状态协调，最终形成一条完整的声明式交付流水线。

2.1 四控制器全景图

下图展示了 Flux v2 的组件拓扑关系以及每个控制器在流水线中的位置：

2.2 各控制器职责与 CRD 映射

每个控制器对应一组核心 CRD，控制器通过调谐（Reconcile）这些 CR 的 spec 与 status 来驱动集群状态。下表列出每个控制器的核心 CRD 及其职责：

2.3 source-controller：制品的守门人

source-controller 是整个流水线的 入口控制器。它负责从 Git 仓库、OCI 镜像仓库或 S3 兼容存储中拉取制品，并执行以下关键操作：

• 制品拉取与校验：支持 SSH、HTTPS、令牌认证；可配置 GPG 签名验证或 OCI 签名验证。
• 本地缓存：将拉取的制品（Git 归档、OCI artifact、bucket 文件）缓存到控制器 Pod 的本地存储中，供下游控制器读取。
• 轮询与 webhook：支持基于间隔的轮询（默认 1 分钟）和 webhook 触发（通过 notification-controller 的 Receiver）。
• 制品版本管理：每个 Source 对象维护一个 Artifact 字段，记录当前制品的 URL、digest、lastUpdateTime。

2.4 kustomize-controller：声明式资源渲染引擎

kustomize-controller 是 Flux 中 最核心的部署控制器。它读取 Kustomization CR，执行以下流水线：

1. 源绑定：通过 spec.sourceRef 引用 source-controller 产出的 GitRepository 或 OCIRepository 制品。
2. Kustomize 构建：在控制器内存中执行 kustomize build，合并所有 overlay、patch、secretGenerator 等。
3. 健康检查与 prune：apply 后等待资源达到 Ready 状态；通过 spec.prune 自动清理不再存在于 Kustomization 中的资源。
4. 依赖排序：支持 dependsOn 字段，确保跨 Kustomization 的部署顺序。

apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: app-prod
spec:
  sourceRef:
    kind: GitRepository
    name: app-repo
  path: ./deploy/overlays/prod
  prune: true
  interval: 5m
  retryInterval: 30s
  timeout: 3m
  postBuild:
    substitute:
      env: prod
      version: "1.2.3"

2.5 helm-controller：Helm Release 生命周期管理

helm-controller 将 Helm chart 的安装、升级、回滚、卸载完全声明化。它与 source-controller 配合，从 HelmRepository 或 OCIRepository 获取 chart 包：

• Chart 依赖解析：自动下载子 chart，构建完整的 chart 依赖树。
• Values 注入：支持从 ConfigMap、Secret 或内联 values 中注入参数。
• Release 状态跟踪：通过 Helm SDK 实时跟踪 release 状态，更新 HelmRelease CR 的 status。
• 自动回滚：当 upgrade 失败时，可配置自动回滚到上一个稳定版本。

2.6 notification-controller：事件中枢与告警分发

notification-controller 不直接参与资源部署，但它负责 串联整个系统的可观测性。它监听所有 Flux 控制器发出的事件，并根据 Alert CR 的配置将事件转发到外部系统：

notification-controller 还提供 Receiver 功能，允许外部系统（如 GitHub webhook）触发 source-controller 的重新拉取，实现事件驱动的 GitOps。

2.7 组件间通信与数据流

Flux v2 的四个控制器之间 不直接通过 API 调用，而是通过 Kubernetes 自定义资源的状态传递信息：

关键数据流路径：

1. source → kustomize/helm：下游控制器通过 spec.sourceRef 引用 Source 对象，从 source-controller 的本地缓存或共享存储中读取制品内容。
2. 所有控制器 → notification：每个控制器在调谐完成后，将事件（成功/失败/进度）写入 Kubernetes Event，notification-controller 监听这些 Event 并转发。
3. Receiver → source：外部 webhook 通过 notification-controller 的 Receiver 触发 source-controller 重新拉取。