Flux 核心概念回顾
在深入节点池配置迁移与版本回滚巡检流程之前，必须牢固掌握 Flux 的核心架构与设计原则。本章将系统梳理 Flux 的架构组件、GitOps 原则、Kustomize/Helm 集成方式以及节点池（Cluster）概念，为后续章节的实操奠定理论基础。
2.1 Flux 架构
Flux 采用 Controller 模式 运行在 Kubernetes 集群内，通过一组相互协作的控制器实现声明式持续交付。其核心架构包含以下组件：
| 组件 | 职责 | 关键行为 |
|---|---|---|
| source-controller | 从 Git、Helm 仓库、Bucket 等源拉取配置 | 定期轮询源，将制品缓存为 Artifact |
| kustomize-controller | 应用 Kustomize 覆盖并同步资源到集群 | 读取 Kustomization 对象，执行 kustomize build |
| helm-controller | 管理 Helm Chart 的发布与升级 | 支持 HelmRelease 对象，执行 helm upgrade |
| notification-controller | 处理事件通知与告警 | 将状态变更推送到 Slack、Webhook 等 |
| image-automation-controller | 自动更新镜像标签并提交回 Git | 基于 ImagePolicy 自动修改 YAML 中的镜像版本 |
架构要点： Flux 的所有控制器均通过 Custom Resource Definitions (CRDs) 暴露配置接口，用户只需声明 GitRepository、Kustomization、HelmRelease 等资源对象，控制器即自动调和至期望状态。
2.2 GitOps 原则
Flux 严格遵循 GitOps 四大原则，确保集群状态与 Git 仓库完全一致：
- 声明式描述：整个系统的期望状态通过 YAML 清单声明，存储在 Git 仓库中。
- 不可变制品：所有配置变更必须通过 Git 提交，不可直接修改集群资源。
- 自动调和：Flux 控制器持续对比 Git 中的期望状态与集群实际状态，自动修复偏差。
- 可审计回滚：每次变更都有 Git 提交记录，支持快速回滚到任意历史版本。
实践提示： 在节点池配置迁移场景中，GitOps 原则意味着所有节点池的 Cluster 对象、Kustomization 覆盖、HelmRelease 参数都必须先提交到 Git，再由 Flux 自动同步到目标集群，避免手动 kubectl apply 导致的配置漂移。
2.3 Kustomize 与 Helm 集成
Flux 同时支持 Kustomize 和 Helm 两种配置管理方式，用户可根据场景灵活选择或组合使用：
| 特性 | Kustomize 集成 | Helm 集成 |
|---|---|---|
| 配置来源 | Git 仓库中的 YAML 文件 | Helm Chart（OCI 或 Git 仓库） |
| 覆盖方式 | patches / overlays / bases | values.yaml / --set 参数 |
| Flux CRD | Kustomization | HelmRelease |
| 版本管理 | Git 提交历史 | Chart 版本 + Git 提交历史 |
| 适用场景 | 纯 Kubernetes 原生资源、环境差异化 | 第三方应用、复杂依赖、版本语义化 |
集成最佳实践： 在节点池配置迁移中，通常使用 Kustomize 管理基础设施层（如 Cluster API 对象、网络策略），使用 Helm 管理应用层（如监控、日志、Ingress Controller），两者通过 Flux 的 dependsOn 机制编排执行顺序。
2.4 节点池（Cluster）概念
在 Flux 生态中，节点池（Cluster） 并非 Flux 原生 CRD，而是指通过 Cluster API (CAPI) 或 Crossplane 等基础设施即代码工具管理的 Kubernetes 集群集合。Flux 通过以下方式与节点池交互：
- Cluster 对象：声明一个 Kubernetes 集群的期望状态，包括控制平面、工作节点、网络配置等。
- MachineDeployment / MachineSet：定义节点池的扩缩容策略、实例类型、可用区分布。
- Flux 多集群管理：通过 Flux 的 Cluster 资源集（Cluster Resource Set）将相同的配置批量应用到多个节点池。
关键区别： 节点池的 生命周期管理（创建、升级、销毁）由 Cluster API 控制器负责，而 配置持续交付（应用部署、策略更新）由 Flux 控制器负责。两者通过 Git 仓库中的 YAML 清单解耦，实现基础设施与应用的独立演进。
在后续章节的 配置迁移 场景中，节点池概念将具体化为：
- 源节点池（旧版本集群，如 Kubernetes 1.24）
- 目标节点池（新版本集群，如 Kubernetes 1.27）
- Flux 配置集（Kustomization + HelmRelease 清单）
迁移流程的核心就是确保 Flux 配置集在源节点池与目标节点池之间平滑切换，同时保持 Git 仓库作为单一事实来源。