2. Flux CD 简介：项目背景、架构组件与版本演进
2.1 项目背景：从 CI 到 CD 的 GitOps 桥梁
Flux CD 由 Weaveworks 于 2016 年开源，是首批将 GitOps 理念落地的 Kubernetes 持续交付工具。在传统 CI/CD 流水线中，部署阶段往往依赖 Jenkins、GitLab CI 等工具通过 kubectl 或 Helm 直接操作集群，这种方式存在三个核心痛点：
- 配置漂移：手动 kubectl apply 或 CI 脚本执行后，集群状态与 Git 仓库容易失步。
- 权限扩散：CI 系统需要持有集群凭证，一旦被攻破，攻击者可获得集群控制权。
- 回滚复杂：需要重新触发 CI 流水线，无法通过 Git revert 快速恢复。
Flux CD 的核心理念是“声明式同步”：集群中运行一个 Operator，持续监听 Git 仓库中的期望状态，自动将集群实际状态拉齐到期望状态。开发者只需修改 Git 仓库中的 YAML 文件，Flux 会自动完成剩余工作。
1. 整个系统状态用声明式配置描述（Kubernetes YAML / Helm Chart）。
2. 配置存储在 Git 仓库中，作为唯一事实来源（Single Source of Truth）。
3. 自动同步 Agent（Flux）确保集群状态与 Git 仓库一致。
4. 所有变更通过 Pull Request 审查，拒绝直接修改集群。
2.2 架构组件：四控制器协作模型
Flux CD v2 采用多控制器架构，每个控制器负责一个独立领域，通过 Kubernetes CRD 和自定义资源进行协作。整体架构如下图所示：
2.3 核心组件详解
2.3.1 Source Controller
Source Controller 是 Flux 的数据入口，负责从外部源拉取配置并缓存到集群内。它定义了四种 CRD：
| CRD 名称 | 源类型 | 典型用途 |
|---|---|---|
| GitRepository | Git 仓库（HTTPS / SSH） | 存储应用 Kustomize 覆盖层、基础 YAML |
| OCIRepository | OCI 兼容仓库（Docker Registry） | 存储 Helm Chart 或预构建的 Kustomize 制品 |
| HelmRepository | Helm Chart 仓库（index.yaml） | 引用 Bitnami / 官方 Helm 仓库 |
| Bucket | S3 / GCS / MinIO 对象存储 | 存储大型二进制配置或 Terraform 状态 |
Source Controller 支持自动轮询（默认 1 分钟）和Webhook 触发两种更新方式。拉取后的内容被压缩为 Artifact 存储在控制器 Pod 的内存或 PVC 中，供下游控制器消费。
2.3.2 Kustomize Controller
Kustomize Controller 负责渲染并应用原生 Kubernetes YAML。它读取 Source Controller 提供的 GitRepository 或 OCIRepository 中的 Kustomize 覆盖层，执行 kustomize build 后通过 Server-Side Apply 将资源推送到集群。
• 支持
patches、patchesStrategicMerge、patchesJson6902 等 Kustomize 原生功能。• 内置 Health Assessment：等待 Deployment/StatefulSet 达到 Ready 状态后才标记同步成功。
• 支持 Prune：自动删除 Git 仓库中已移除的资源，防止残留。
2.3.3 Helm Controller
Helm Controller 是 Flux 的Helm 操作引擎，它替代了传统的 helm install/upgrade 命令。核心 CRD 包括：
- HelmRelease：声明一个 Helm Release 的期望状态，引用 Source Controller 提供的 Chart。
- HelmChart：自动从 HelmRepository 或 OCIRepository 中拉取 Chart 并缓存。
Helm Controller 支持values 覆盖（通过 ConfigMap / Secret 引用）、依赖管理（等待依赖 Release 就绪）、回滚（自动回滚到上一个成功版本）。
2.3.4 Notification Controller
Notification Controller 负责事件路由与告警。它监听所有 Flux 控制器发出的事件（同步成功、失败、进度），并根据 Alert 和 Provider CRD 的配置将事件转发到外部系统。
| Provider 类型 | 支持的服务 |
|---|---|
| Slack / Discord / Telegram | 即时消息通知 |
| GitHub / GitLab / Bitbucket | Commit Status 更新 |
| Webhook | 自定义 HTTP 回调 |
| PagerDuty / OpsGenie | 事件告警与值班调度 |
2.4 版本演进：从 Flux v1 到 Flux v2
Flux 经历了两次重大架构重构，理解版本演进有助于选择正确的部署策略：
| 维度 | Flux v1（旧版） | Flux v2（当前） |
|---|---|---|
| 架构 | 单体二进制，所有功能集成在一个 Pod 中 | 多控制器，每个控制器独立部署、独立升级 |
| Helm 支持 | 通过 fluxctl 命令间接支持，功能有限 |
原生 Helm Controller，支持完整 Helm 生命周期 |
| OCI 支持 | 不支持 | 原生 OCIRepository，可直接拉取 OCI 制品 |
| 多租户 | 无原生支持，需手动隔离 | 通过 Kustomization.spec.targetNamespace 和 RBAC 实现 |
| 依赖管理 | 无 | 支持 dependsOn 字段，可定义资源部署顺序 |
| 健康检查 | 仅检查 Deployment 是否 Running | 支持自定义 HealthChecks，可检查 CRD 状态 |
| 升级路径 | — | 提供 flux bootstrap 命令，支持从 v1 迁移 |
flux bootstrap 的迁移模式逐步切换。
2.5 核心工作流：一次完整的 GitOps 同步
以下是一个典型的多环境部署流程，展示四个控制器如何协作：
- 开发者提交 PR 修改
apps/production/deployment.yaml，合并到 main 分支。 - Source Controller 轮询到 Git 仓库有新的 Commit，拉取最新内容并生成新的 Artifact。
- Kustomize Controller 检测到
GitRepository的 Artifact 更新，重新执行kustomize build，生成最终的 Kubernetes 资源清单。 - Kustomize Controller 通过 Server-Side Apply 将资源应用到集群，并等待 Deployment 达到 Ready 状态。
- Notification Controller 捕获同步成功事件，发送 Slack 消息通知团队。
- 如果 Deployment 在 5 分钟内未就绪，Kustomize Controller 将同步状态标记为
Failed，Notification Controller 发送告警。