web

第55章｜Flux 入门：Source、Kustomization、HelmRelease 与自动化

如果把 GitOps 想成“工厂的流水线”，那 Flux 就是把流水线拆成几台专用机器： Source Controller 把原料从 Git 拉进来；Kustomization 做结构化拼装； HelmRelease 负责把 chart 变成可部署的零件；再用自动化控制器让镜像更新自己上岗。 你只需要做一件事：把“应该怎样”写进仓库，然后看它在集群里一次又一次对拍收敛（reconcile）。

Source

Fetch artifacts

  • GitRepository · OCI
  • interval · suspend
  • ref = revision pin
Kustomize

Build & apply

  • prune · wait
  • dependsOn ordering
  • patch layers
Helm

Release & remediate

  • HelmRelease CRD
  • values / valuesFrom
  • install/upgrade remediation

1. Flux 的核心精神：组件化的“持续收敛”

Flux 的世界观和第 54 章的 Argo CD 都是 GitOps，但组件边界不同：Argo CD 以 Application 为中心， Flux 则把交付拆成 多个控制器 与 多类 CRD。你会看到： Source 提供输入；Kustomization 把输入 build 成 manifest 并对集群 apply；HelmRelease 管 chart 的安装与升级； 其他控制器（例如通知与镜像自动化）则把“更新与响应”接上来。 所以你不是在“点一次同步”，而是在让系统按约定的时间间隔与依赖关系，持续回到“期望状态”。

Flux controllers (componentized GitOps) Git manifests · charts revision pin: tag/semver/branch pull interval Source Controller GitRepository / OCIRepository / Bucket artifact fetched ref → sha256 / checksum Kustomize + Helm Kustomization build graph HelmRelease install/upgrade Automation & notifications (optional controllers) Image reflector/controller → ImagePolicy → ImageUpdateAutomation Intervals + retries + remediation ensure convergence
图 1：Flux 把“拉取、构建、发布、修复、自动更新”拆成可单独治理的控制器模块。

2. Source：把 Git 变成“可重复的输入”（不是随手 pull）

Flux 的 Source 通过 CRD 定义“从哪里拉、拉哪个版本、多久检查一次”。常见有 GitRepository（也可配套认证）、HelmRepository、OCIRepository 与 Bucket。 Source Controller 会在指定 interval 内检测变化，渲染成 artifact 并缓存结果； 下游（Kustomization / HelmRelease）通过对接 artifact 来做一致性构建。 这就是为什么 Flux 能更稳定地解释“那天发布的依赖到底是哪一份”。 

# Example: GitRepository (pin version via branch/tag/semver)
apiVersion: source.toolkit.fluxcd.io/v1beta2
kind: GitRepository
metadata:
  name: flux-manifests
  namespace: flux-system
spec:
  interval: 1m0s
  url: https://git.example.com/org/platform-gitops.git
  ref:
    branch: main
  # Optional: credentials / secretRef
Artifact pipeline: ref selection → cached artifact → consumers GitRepository url + ref interval checks resolve → digest Artifact cache checkout + build context immutable-ish inputs passed downstream Consumers Kustomization HelmRelease
图 2：Source 不只是“拉代码”，而是把版本选择与缓存输入变成可追溯的工艺环节。

3. Kustomization：构建与应用的“操作台”（包含依赖排序）

Kustomization 决定如何把仓库中的目录 build 成 manifest。常见关键字段包括： interval（多久 reconcile）、path（要构建的子目录）、 prune（删除 Git 里移除的对象）、wait（等待就绪再判定完成）、 以及 dependsOn（显式依赖顺序，避免先建业务、后建 namespace / CRD）。 在多环境场景里，你会看到“平台 root Kustomization”与“环境 overlay Kustomizations”的层级拼装。 

# Example: Kustomization (ordering + prune + wait)
apiVersion: kustomize.toolkit.fluxcd.io/v1beta2
kind: Kustomization
metadata:
  name: payments-prod
  namespace: flux-system
spec:
  interval: 2m0s
  path: ./deployments/payments/prod
  prune: true
  wait: true
  sourceRef:
    kind: GitRepository
    name: flux-manifests
  dependsOn:
    - name: platform-core
  # Optional: patches / additional parameters
Build graph: dependsOn controls reconcile order platform-core CRDs · namespaces wait: true interval = base payments-prod path + patches dependsOn: platform-core prune: true · wait: true traffic Ingress / Gateway overlay modules prune: true
图 3：`dependsOn` 像“建造顺序”：先把地基（CRD/namespace）打稳，再让业务材料入场。

4. HelmRelease：chart 到集群的“可治理交接单”

HelmRelease 把 Helm chart 安装、升级、回滚所需的策略写成 CRD。关键思想： 你依旧是声明式，但在“失败时如何修复”上，Flux 能提供 install/upgrade remediation。 常见做法是使用 values 或 valuesFrom（从 ConfigMap / Secret 引用 values）， 同时配合 suspend 来临时冻结自动升级窗口。 

# Example: HelmRelease (valuesFrom + remediation)
apiVersion: helm.toolkit.fluxcd.io/v2beta2
kind: HelmRelease
metadata:
  name: payments-api
  namespace: payments-prod
spec:
  interval: 3m0s
  chart:
    spec:
      chart: payments-api
      sourceRef:
        kind: HelmRepository
        name: charts
      version: 1.2.3
  targetNamespace: payments-prod
  valuesFrom:
    - kind: ConfigMap
      name: payments-api-values
      valuesKey: values.yaml
  install:
    remediation:
      retries: 3
  upgrade:
    remediation:
      retries: 5
HelmRelease: chart fetch → render → apply → remediate HelmRepository chart spec + version fetch artifacts digest pinned helm-controller render chart with values / valuesFrom apply + wait + remediation Cluster deployments · svc job hooks (optional) converged state
图 4：HelmRelease 不是“把 chart 安装上去”，而是把安装升级的失败修复策略写进系统。

5. 自动化更新：让镜像升级从“人盯梢”变成“自动授课”

Flux 生态里常用的是 image-reflector-controller 与 image-automation-controller。 它们通过 ImagePolicy 选择“哪些镜像标签值得升级”，再用 ImageUpdateAutomation 把版本回写到仓库（例如更新 values 中的 tag）。 你可以用过滤器做 semver 保守升级，避免把 `latest` 的惊喜当成生产的日常。

Image automation: detect → decide → commit Reflector list registry tags cache tag metadata new tags detected ImagePolicy semver / regex filters select allowed upgrade decision: approved tag Automation update values commit & PR (best) Git change
图 5：自动化更新需要“决策护栏”。ImagePolicy 就像分拣站：只放行符合规则的标签。
# Illustrative: ImageUpdateAutomation updates repo with new tag
# (real manifest omitted for brevity; structure is similar)
kind: ImageUpdateAutomation
spec:
  interval: 1m0s
  sourceRef:
    kind: GitRepository
    name: flux-manifests
  git:
    checkout:
      ref:
        branch: main
    commit:
      author:
        name: flux-bot
        email: flux-bot@example.com
  update:
    path: ./deployments/payments/prod
    strategy: Setters

6. 多环境与层级：把“平台”与“业务”分开

在实际工程里，你通常会把仓库拆成两层：platform（集群基础设施、监控、策略、CRD） 与 apps（业务 workload 与 ingress）。Flux 的 root Kustomization 可以把平台层先收敛， 再让环境 overlay（prod/stage/dev）做依赖对接。 配套的多租户治理包括：为每个团队维护独立的命名空间、限制它们可引用的 ServiceAccount/RBAC 权限， 并用 dependsOn 明确依赖图，避免“某个 chart 先装了，后面的 CRD 又来迟了”。

Repo layering: platform root → environment overlays Git repo layout /platform /apps /environments/prod|stage each overlay references platform platform-core CRDs · monitoring · policy prune: true · wait: true namespace: flux-system or platform ns prod overlay apps/payments dependsOn: platform-core RBAC boundaries
图 6：层级仓库把复杂度“分段封装”。依赖链清晰，集群就能更快收敛，出错也更好定位。

7. Debugging：如何把“收敛失败”讲成可排查的故事

Flux 把控制器状态写进 CRD conditions 与 events 里。排查时优先做三件事： 确认对象处在什么状态（Kustomization/HelmRelease conditions）、 确认它看到了什么输入（Source artifact / revision）、 确认它做了什么动作（reconcile、apply、remediation）。 然后再进入细节：看 build 输出、Helm template 渲染、以及依赖是否满足（例如 CRD/namespace 是否已就绪）。 

# CLI workflow (illustrative)
flux get kustomizations -A
flux get helmreleases -A
flux describe kustomization payments-prod -n flux-system
flux describe helmrelease payments-api -n payments-prod
flux logs -n flux-system deployment/kustomize-controller
flux reconcile kustomization payments-prod -n flux-system
经验底线：不要只看“最后一次 reconcile 失败没”。要读条件（conditions）里的原因， 以及它等待的依赖是否真的存在；否则你会在错误的“时间线”里修错东西。

8. 本章清单

  1. 理解 Flux 的控制器分工：Source / Kustomization / HelmRelease / automation。
  2. 会写一个最小的 GitRepository + Kustomization，并使用 `prune` 与 `wait`。
  3. 能为 HelmRelease 配置 valuesFrom 与 remediation，知道如何 suspend 冻结升级窗口。
  4. 理解 ImagePolicy + ImageUpdateAutomation 的“决策护栏”，避免 latest 惊喜上生产。
  5. 用 dependsOn 设计多环境层级，明确 platform 与 apps 的边界。
  6. 掌握常用 CLI 排查路径：describe / logs / reconcile，并能读 conditions 和 events。
  7. 预告下一章：GitOps 安全——签名验证、策略控制与多团队协作落地。
← 上一章：Argo CD 下一章：GitOps 安全 →