2. Flux 核心概念回顾：GitOps、Source、Kustomize、HelmRelease、OCIRepository 基础

在深入节点池自动同步与一致性验证之前，必须重新锚定 Flux 的五大核心概念。这些概念构成了整个 GitOps 工作流的骨架，也是后续章节中所有自动化策略的基石。本章将逐一拆解 GitOps 范式、Source 资源、Kustomize 控制器、HelmRelease 以及 OCIRepository 的角色与交互关系。

2.1 GitOps：声明式状态与持续协调

GitOps 不仅仅是一种工具，更是一种运维模式。其核心思想是将 Git 仓库作为整个集群状态的“唯一事实来源”（Single Source of Truth）。Flux 作为集群内的 Operator，持续监控 Git 仓库中的期望状态，并与集群实际运行状态进行比对，一旦发现偏差，立即执行协调（Reconciliation）操作，将集群拉回期望状态。

2.2 Source：配置的源头与版本管理

Source 是 Flux 中定义“从哪里获取配置”的 CRD（Custom Resource Definition）。它抽象了 Git 仓库、Helm 仓库、Bucket 和 OCI 制品等不同来源。Source 控制器负责拉取、校验并缓存这些资源，生成一个不可变的 Artifact（通常是一个 tar.gz 包），供下游的 Kustomize 或 HelmRelease 消费。

2.3 Kustomize：覆盖层与环境差异化

Kustomize 是 Flux 内置的配置管理引擎，它不依赖模板引擎，而是通过“覆盖层”（Overlay）机制实现环境差异化。Flux 的 Kustomization CRD 负责从 Source 中读取 YAML 清单，执行 Kustomize 构建，并将最终产物应用到集群。

Kustomize 在节点池场景中的核心价值在于：

• Base + Overlay 模式：将节点池的通用配置（如 DaemonSet、NodeSelector）放在 Base 层，将不同可用区或实例规格的差异放在 Overlay 层。
• Patches 策略：使用 patchesStrategicMerge 或 patchesJson6902 对节点池的特定字段进行微调，无需复制整个 YAML 文件。
• 依赖管理：通过 dependsOn 字段确保节点池的基础设施（如 VPC、子网）先于应用层部署。

# 示例：Kustomization 引用 Git 仓库中的节点池配置
apiVersion: kustomize.toolkit.fluxcd.io/v1
kind: Kustomization
metadata:
  name: node-pool-config
  namespace: flux-system
spec:
  interval: 3m
  path: ./clusters/production/node-pools/
  prune: true
  sourceRef:
    kind: GitRepository
    name: cluster-config
  postBuild:
    substitute:
      region: "us-east-1"
      instance_type: "m5.large"

2.4 HelmRelease：Chart 驱动的应用交付

对于使用 Helm Chart 管理的应用（如 Prometheus、Ingress Controller），Flux 提供了 HelmRelease CRD。它结合 HelmRepository 或 OCIRepository 作为 Source，通过 values 或 valuesFrom 注入配置，实现声明式的 Helm 发布管理。

在节点池一致性验证中，HelmRelease 常用于部署节点级别的监控 Agent 或日志采集器。其关键字段包括：

• chart.spec.chart：指定 Chart 名称。
• chart.spec.sourceRef：指向 HelmRepository 或 OCIRepository。
• values：内联的 values 覆盖，或通过 valuesFrom 引用 ConfigMap/Secret。
• install.crds：控制是否安装 CRD，对于节点池中的 Operator 至关重要。

2.5 OCIRepository：面向制品的 GitOps 新范式

OCIRepository 是 Flux 2.x 引入的重要扩展，它允许将 YAML 清单或 Helm Chart 打包为 OCI 镜像，存储在容器镜像仓库中。这种方式天然支持版本化、签名验证和不可变性，特别适合需要严格供应链安全的场景。

OCIRepository 与 GitRepository 的核心区别：

2.6 核心概念交互关系图

下图展示了 Flux 核心组件之间的数据流与协调关系。Source 控制器负责拉取配置，Kustomize 和 HelmRelease 控制器负责构建并应用，最终由 Flux 主控制器确保集群状态与 Source 一致。

2.7 节点池场景下的概念映射

将上述概念映射到节点池自动同步场景中，可以更清晰地理解每个组件的作用：

• GitRepository / OCIRepository：存储节点池的期望配置，如节点标签、污点、资源预留、DaemonSet 清单。
• Kustomization：根据节点池的可用区或实例类型，通过 Overlay 生成差异化的 DaemonSet 或 ConfigMap。
• HelmRelease：部署节点池级别的监控 Agent（如 Node Exporter），通过 values 注入节点池名称标签。
• Source 缓存：确保 Flux 在协调时使用一致的配置快照，避免因 Git 仓库并发写入导致的不一致。