多集群环境怎么用 GitOps 管发布

多集群发布最常见的误区，是把单集群的做法复制 N 份：每个集群一套流水线、一套权限、一套 YAML。半年后，没人说得清生产集群实际运行的是哪个提交。问题不在有没有用 Git，而在于集群身份、配置版本、制品版本和发布审批没有连成同一条可追溯链路。GitFox 把代码评审、流水线和制品库放在同一条链路上，能先把“构建出哪个版本”固定下来；至于版本如何进入多个集群，仍要交给 GitOps 控制器。

多集群环境怎么用 GitOps 管发布？OpenGitOps 在 GitOps 原则 v1.0.0 中强调声明式、版本化且不可变、自动拉取、持续协调；落到多集群，可以把职责拆成四段：CI 只构建并产出不可变制品，Git 保存每个环境的期望状态，GitOps 控制器持续协调，发布推进通过修改 Git 中的声明完成。选 GitOps 工具之前，先把下面三个设计问题定下来。

一、先把“多集群”拆成三种问题

多集群不等于多环境。先把问题分开，后面的仓库和权限才不会混。

场景	核心差异	建议的发布边界
多环境	镜像版本、副本数、域名和配置不同	按环境目录逐级推进
多地域	同一版本分发，地域参数和数据位置不同	同版本分发，地域配置覆盖
多租户或异构集群	权限、网络、CRD 差异较大	分层基座，集群级覆盖，严控共享范围

多环境重点在版本和配置差异；多地域重点在同一版本如何安全分发；多租户或异构集群则要先处理权限与网络边界。三类场景可以共用一套 GitOps 控制面，但不建议共用同一个发布单元。

判断标准很直接：如果两个集群的审批人、故障影响面或网络边界不同，就应当被视为两个发布域，而不是一个域里的两个目录。

二、控制器放哪里：集中式还是分布式

控制器放在哪里，是第一个架构决策，不是工具偏好。

拓扑	工作方式	更适合	需要接受的代价
中心控制	一个控制面纳管多个集群，由中心下发或协调	集群数量可控、网络稳定、平台团队集中运维	中心持有较高权限，故障影响面更集中
每集群控制	各集群从 Git 拉取并本地协调	生产隔离强、跨云跨网络、集群较多	版本、状态汇总和升级更复杂

红帽关于 Argo CD Push 和 Pull 模型的说明指出，集中式由中心直接向受管集群下发，分布式由各集群本地控制器从 Git 拉取。后者能降低中心控制面的压力，但会增加状态回传和请求管理。

如果生产集群不允许中心控制面长期持有高权限凭证，优先考虑每集群拉取。如果集群数量不多、网络稳定、平台团队集中，中心控制更省人力。关键是让生产拥有独立边界，而不是把所有集群塞进一个高权限账号。

选 GitOps 工具时，也要确认它能否清楚展示每个集群的同步状态、健康状态和失败原因，而不只是支持“多集群”这个词。

三、仓库分层：应用、环境、集群各管什么

仓库建议至少分三层，而不是把所有 YAML 放在一个目录里。

应用基座：Deployment、Service、HPA、Ingress 等可复用清单。
环境覆盖：开发、预发、生产的副本数、域名、资源和地域参数。
集群登记：环境、地域、租户、负责人和发布域标签。

集群登记必须准确。Argo CD 的 Cluster generator会从注册集群的 Secret 读取参数，并可用标签选择器缩小目标范围。标签一旦混乱，批量发布就可能把变更带到错误的集群。

ApplicationSet 适合集群多、模板一致的场景；集群少或差异大时，显式 Application 反而更容易审查。更细的目录拆分可以参考GitOps 配置仓库怎么组织。

密钥不要以明文进入 Git。可以用 SOPS 加密、Sealed Secrets，或把密文留在外部密钥系统，由 External Secrets 同步。重点是轮换、审计和恢复路径清楚，而不是把解密密钥放进同一个仓库。

四、发布链路：CI 产制品，GitOps 管落地

发布链路只做一件事：把经过验证的不可变版本，逐级写进对应环境。

CI 负责构建、测试、扫描和产出制品。镜像要使用内容摘要，避免用 latest 这类可变标签。发布时也不要在流水线里保存每套集群的凭证，正确动作是提交一个修改镜像摘要或 values 的 PR，评审通过后让控制器协调。

多集群并没有取消 CI，反而要求 CI 和制品管理更稳定。GitFox 是禅道 DevOps 的内置核心组件与自研底层引擎，无海外开源内核依赖；禅道负责需求、任务和缺陷，GitFox 负责代码托管、评审、流水线、代码扫描与制品库，两者分工清晰。对 50～300 人研发中心、中大型组织，或需要私有化、信创适配的团队，它适合先收敛代码到制品这一段；集群侧的声明式协调仍由所选 GitOps 控制器完成。

环境推进建议采用“同一主干 + 环境目录或 overlay”。用长期环境分支承载差异，会让合并、审计和回滚变复杂。开发环境可以自动同步，预发环境在自动同步后执行冒烟测试，生产环境则加上人工审批与分批窗口。

多集群 GitOps 发布链路示意图

图 1：CI 产出制品，Git 保存声明，控制器将期望状态协调到各集群。

五、验证与回滚：Synced 不等于业务可用

判断一次发布是否完成，不要只看界面上的 Synced。至少要一起看四个信号：

同步状态：目标集群是否已经应用了 Git 中的版本。
健康状态：Deployment、Pod、Service 等资源是否真正可用。
冒烟结果：登录、核心接口、关键页面是否通过。
业务指标：错误率、延迟、吞吐和关键转化是否在可接受范围。

前三项正常，第四项异常，仍然不能算发布成功。 漂移检测也应当纳入告警：控制器能自动修复，不代表团队不需要知道有人绕过 Git 改了集群。

生产开启自动 prune 前尤其要谨慎。Git 中移除资源后，自动 prune 会删除集群中的对应对象；对 CRD、PVC、命名空间这类影响较大的资源，应设置独立策略、归属标签和备份。

回滚要以 Git 中已知可用的提交为基准，用 revert 恢复完整声明，而不是只执行 kubectl rollout undo。后者通常只覆盖工作负载的一部分，不会恢复 ConfigMap、Secret、Ingress 等对象。数据库 schema、外部配置和消息格式不一定能随应用一起回退，这类变更要提前拆分并验证兼容性。

多集群 GitOps 发布推进与回滚流程图

图 2：变更逐级推进，异常时通过 Git 回退恢复声明状态。

六、常见坑与落地顺序

多集群 GitOps 的坑，大多不是控制器不会用，而是边界没定。

所有集群共用一个高权限凭证，出问题时无法判断影响范围。
用 latest 标签发布，Git 中记录的版本和集群实际运行的镜像对不上。
密钥明文入库，或把解密密钥放在同一仓库。
用一个 Application 管理整个集群，任何资源变化都触发大面积 diff。
只看同步状态，不看健康、冒烟和业务指标。

落地时先小范围跑通。选两个非生产集群和一条低频应用，先确认目录分层、集群标签、制品摘要、同步状态和回滚路径，再扩到预发和生产。每增加一个发布域，就复核一次权限、网络和告警，而不是只复制一份配置。

GitOps工具只是执行层。真正决定多集群发布是否可控的，是发布域、制品版本和验证闭环是否清楚。

七、常见问题

多集群一定要用 ApplicationSet 吗？

不一定。ApplicationSet 解决批量生成和集群选择，适合集群多、模板一致的场景；集群少或差异大时，显式 Application 更容易审查。

GitOps 能替代 CI 吗？

不能。CI 负责构建、测试、扫描和产出制品；GitOps 负责把已发布的期望状态持续协调到集群。两者边界越清楚，排障越容易。

生产集群断网，GitOps 还能工作吗？

要看模型。每集群拉取模式在本地控制器和缓存可用时，可以继续按最后一次拉取状态协调；中心推送模式更依赖网络和中心控制面。无论哪种，都要准备本地应急流程。

回滚只改 Git 就够吗？

应用清单通常可以，数据库 schema、外部配置和消息格式不一定。把不可逆变更拆成独立步骤，回滚前先确认数据兼容。

多集群环境怎么用 GitOps 管发布，落点不是多装几个控制器，而是把发布域、仓库、制品和验证连成一条可追溯链路。先用两个非生产集群跑通，再扩大到生产，往往比一次性接管所有集群更能暴露权限、网络和回滚问题。若正在做 PoC，也可以先在 GitFox 的私有化环境验证代码、流水线和制品链路，再由所选 GitOps 控制器负责集群侧协调。