Flux 镜像自动化如何连接发布流程

镜像已经推送到仓库，为什么集群还没更新？在 GitOps 中，镜像发布和部署声明是两个不同对象。Flux 的 Image Automation 解决的是“把符合策略的镜像写回 Git”，不是包办构建、审批和上线验收。本文依据现有官方能力说明接入方式，不将其描述为某次新版本公告。官方入口：https://fluxcd.io/flux/guides/image-update/。

触发场景：把“有新镜像”变成可追踪的变更

假设团队已经由 CI 构建应用，并使用不可变版本标签。当前缺口是工程师反复手工修改部署目录里的镜像引用。这时可让镜像自动化维护声明，仍由原有发布制度决定哪些变更能够进入生产。

先约定三个结果：候选版本可解释，Git 修改范围可控制，部署结果独立确认。测试通过、漏洞扫描、业务指标等门禁应明确交给具体系统，不能因为接入 Flux 就默认已经具备。

权限配置：读镜像与写 Git 分开授权

接入前确认 image-reflector-controller 与 image-automation-controller 已部署，并具备匹配的自定义资源定义。镜像仓库需要的读取凭据和 Git 仓库写入凭据应分别管理；只读 Git 凭据无法承担自动提交。不要把令牌或私钥写进文章示例、提交消息或排障截图。

在我选择接入范围时，会先把测试环境目录独立出来，再考虑扩大权限。这个取舍不是 Flux 强制要求，而是为了降低首次接入的影响面。多环境共仓时，尤其要明确自动化对象负责哪个目录、哪条分支，避免一个写入器修改所有环境。

流水线阶段：三个资源与一个字段标记

ImageRepository提供镜像元数据，ImagePolicy选择候选版本，ImageUpdateAutomation修改 Git 中被标记的字段。负责部署的协调器随后消费其跟踪的 Git 内容。这些职责不能互相替代。

下面是策略示例，假定同命名空间已存在名为 demo 的 ImageRepository。它只展示候选规则，不是可直接上线的完整部署文件。

# 示例：限制候选为一系列稳定版本，不开放跨主版本升级
apiVersion: image.toolkit.fluxcd.io/v1
kind: ImagePolicy
metadata:
  name: demo
  namespace: flux-system
spec:
  imageRepositoryRef:
    name: demo
  policy:
    semver:
      range: '>=1.0.0 

规则含义是选择满足约束的最高语义版本，不是按推送时间取最后一个标签。团队仍需让标签命名与发布制度一致：如果镜像存在却不满足约束，不发生更新可能正是预期行为。策略参考：https://fluxcd.io/flux/components/image/imagepolicies/。

部署文件中，需在希望被维护的值后写入 Setter 标记。以下只是容器条目片段，省略 Deployment 外层；示例镜像地址必须换成团队自己的真实仓库。

# 放在已有 Deployment 的 containers 列表中；不单独提交为完整资源
- name: demo
  image: registry.example.invalid/team/demo:1.0.0 # {"$imagepolicy": "flux-system:demo"}

标记里的命名空间和策略名必须对应实际资源；自动化的更新目录也必须包含这份文件。镜像候选已改变而 Git 没有差异时，优先检查这两处连接，不要立即放宽版本范围。

门禁规则：直接提交还是审核分支

直接写入部署所跟踪的分支，适合团队已经接受自动升级的受控环境。它减少人工步骤，但也意味着不能指望一个不存在的人工审批点阻止变更。

需要审核时，可让自动化从主分支取内容，把修改推到专用分支。以下同样是 ImageUpdateAutomation 的配置片段，需要并入已有对象，补齐 sourceRef、interval、commit.author 等必要配置。

# 自动化专用分支，不作为人工长期开发分支
spec:
  git:
    checkout:
      ref:
        branch: main
    push:
      branch: flux-image-updates
  update:
    path: ./clusters/staging
    strategy: Setters

在常见 GitHub 审核模式中，创建 PR、执行 CI、批准并合并仍需另行接入；设置 push.branch 本身不等于完成审批。同时要让部署源继续跟踪受保护的主分支，否则若部署源直接读取自动化分支，审核设计就失去意义。

专用分支还有协作边界：官方说明涉及已有推送分支的覆盖行为，以及关闭强推后的陈旧分支问题。因此不要在同一分支混入人工长期提交，分支保护也要与机器人的实际推送权限配套。相关配置参考：https://fluxcd.io/flux/components/image/imageupdateautomations/。

失败处理：按证据所在层定位

排障时我会先问“最后一个已确认结果是什么”，再决定检查范围。没有候选时，查镜像读取、标签与策略约束；候选存在但没有文件变化，查目录和标记；文件已改变但推送失败，查写权限及分支规则；提交已进入目标分支而部署没更新，查部署源跟踪关系和部署协调器状态。

这些是建议的排查顺序，不是本文执行过的测试记录。错误重试也不能替代权限修正。若回退镜像，须同步考虑仍在运行的自动化策略；仅手改旧标签，而策略仍选中较新版本，可能再次被自动改回。先按团队变更制度暂停对应自动化或收紧策略，再提交回退声明，恢复前确认候选规则。

通知复盘：提交成功不等于上线成功

通知最好分别表达“候选选定”“声明已提交”“审批已合并”“部署状态已确认”，并关联策略对象、Git 提交和环境，而不是统一写成“发布成功”。一次 Git 推送回执只能证明声明写入阶段的结果，不能证明业务健康。

接入后的复盘重点是：版本规则是否符合团队预期，机器人有没有越界修改，审核是否真正位于部署读取之前，失败是否通知到负责该层的人。Flux 让镜像变更进入 Git 的过程更自动化；可靠发布还取决于权限、审批与部署验收之间是否保持清晰边界。