Argo CD 渐进式发布能力怎样接入 GitOps 流程

把渐进式发布接入 Argo CD 的 GitOps 流程，通常是由 Git 保存发布声明，Argo CD 同步 Rollout 等资源，再由独立的 Argo Rollouts 控制器执行金丝雀或蓝绿策略。Argo CD 的 ApplicationSet Progressive Syncs 则解决多 Application 分批同步，两者不能当作同一个流量控制功能。

Argo CD 官方文档：https://argo-cd.readthedocs.io/en/stable/；Argo Rollouts 官方文档：https://argoproj.github.io/argo-rollouts/。本文是基于现有官方能力的工程解读，不是一条新版本公告。以下订单服务为设计场景，指标和门槛用于解释取舍，没有真实部署或压测结果。

先用指标定义一次小流量发布要证明什么

如果要给一个已有 GitOps 的订单服务增加灰度，我会先问：希望减少一次失败影响的请求量，还是希望发布更快？这两个目标不能用“启用渐进式发布”一句话替代。对我来说，优先目标应是限制暴露面，并给停止发布留下可靠依据。

我会在试点前准备稳定版本的基线：相同路由下的请求量、5xx 比例、p95 延迟，以及业务成功率。指标要能区分稳定版本和候选版本，否则全站平均值可能把少量候选流量的异常稀释掉。

表中 1% 和 1.2 倍只是待评审的示例，不是 Argo 默认值，也不是生产通用标准。最小样本数、窗口长度和业务护栏应按服务负载预先确定。报告里的“结果”要保留实际观测值，不能只写绿灯。

把声明同步与灰度控制分给不同组件

最初容易混淆的地方，是把同步成功当成业务发布成功。Git 中的资源已被同步，只能说明声明交付到了集群；候选版本能否继续放量，还需要发布控制器及观测依据。

Argo CD 负责声明同步；Rollout 资源描述单应用发布策略；Argo Rollouts 管理相应 ReplicaSet，并可结合支持的流量组件控制金丝雀；AnalysisTemplate 描述分析定义，AnalysisRun 保存一次分析执行的状态与测量。Git 不应承担每次观测采样的运行时状态存储。

因此，接入前要确认 Rollouts 的 CRD 和控制器已安装，Argo CD 有权限管理目标命名空间，所需 Service、路由及观测服务可用。仅安装 Argo CD 不会自动安装 Rollouts，也不会把普通 Deployment 变成完整的金丝雀方案。

在 Git 中提交发布策略而不是临时改副本

我的取舍会是先试一个可回退的单应用，再考虑跨集群编排。把镜像固定到受控的不可变版本，在代码评审中一起提交策略修改。既有 Deployment 的迁移还涉及资源选择器、Service 选择器、容量和接管方式，不能只把 kind 改成 Rollout 就直接上线。

下面仅是已有 Rollout 的 spec.strategy 配置片段，用来解释暂停点；它不是可独立部署的完整清单，也未包含自动指标分析：

strategy:
  canary:
    # 示例权重与暂停点，完整资源仍需匹配实际服务配置
    steps:
      - setWeight: 20
      # 不指定时长会保持暂停，等待明确的继续决策
      - pause: {}
      - setWeight: 50
      - pause: {}
      - setWeight: 100

没有流量管理组件时，setWeight 主要通过新旧副本数量尽力接近比例，不保证请求恰好按 20% 分配。长连接、会话粘性和负载分配都会影响实际请求分布。若要求细粒度流量比例，应选用 Rollouts 支持且团队能够运维的流量路由集成，并配置其必需资源。

另一个容易漏掉的边界是首次创建：没有已知稳定版本时，不能假设能像后续升级一样比较新旧版本。应先建立可用基线，再讨论候选版本的灰度发布。

让观测门槛决定继续、暂停或中止

手动暂停适合梳理最初的观测职责，却不会自动读取表里的阈值。要自动化，需定义 AnalysisTemplate，配置指标提供方、查询、判定条件、测量间隔与失败容忍，并在 Rollout 中引用。模板要随 Git 管理，执行结果则记录在 AnalysisRun 等运行态对象中。

我更看重这类设计留下的解释能力：候选版本、观测窗口、请求数量、错误率与延迟应能关联到同一次发布。查询应隔离候选流量；没有样本、返回空集合、超时和指标提供方错误，都要有明确处理策略，而不是被转成“错误率为零”。

官方分析机制区分测量失败、执行错误以及不能明确下结论等情况，具体如何影响发布，取决于分析挂载方式和对应配置。不要把“暂停等待人判断”与“分析判定失败”混为一谈。想中止新版本时，应按既定处置方式操作，同时记录导致中止的证据。

对于试点，我会同时比较稳定与候选在匹配窗口下的数据，并在报告中留出“尚未取得结果”状态。只有真实观察后，才填写放量前后的差异；本文没有执行这些试验，因此不提供看似精确的改善百分比。

把回退和多应用扩展留在同一份交付记录里

Argo Rollouts 不会因回退而自动改写 Git。发布失败后，它可以按机制回到稳定版本的副本或流量安排，但 Rollout 的期望声明仍可能指向失败版本，资源健康状态也会反映发布未成功。不能简单推断 Argo CD 会因此无限重复发布：Rollouts 管理的运行状态与 Git 中的声明不是同一层。

后续应通过受控提交修复并向前发布，或按团队策略在 Git 中明确恢复已知可用声明。数据库迁移、外部消息及已经发生的业务写入并不会随容器回退自动撤销。我会把这些外部兼容条件写入发布评审，而不是交给一个回退按钮承担。

扩展到多个 Application 时，再考虑 ApplicationSet 的 RollingSync：它按标签选择应用分组，以健康状态和 maxUpdate 等条件限制同步推进；它不是单应用请求的流量百分比。官方文档还说明 RollingSync 会关闭生成应用的 autosync，使用前必须按部署版本确认能力状态、启用条件和现有同步策略的相容性。

适合这套组合的，是已有 GitOps 基础、能区分版本指标、能够维护流量组件与回退流程的团队。对暂时没有可信指标的小服务，我会先保留人工暂停，把观测与职责补齐，而不是直接给它套一层自动放量。这是工程判断，不是实测证明自动化一定降低事故率。

Argo CD 的 Synced 是否代表金丝雀已成功？

不是。还要看 Rollout 健康、分析状态、业务指标与发布是否完成。资源声明相符不能替代业务验收。

只用 sync waves 能否做到请求级灰度？

不能把同步顺序当成流量策略。sync waves 管理同步次序，单应用的副本与流量控制需要相应发布控制器和路由能力。

发生回退后是否必须让控制器提交 Git？

不是 Rollouts 的内置职责。应按团队的 GitOps 变更流程记录修复或恢复意图，避免让未经授权的控制器拥有仓库写权限。

官方参考：Rollouts 与 Argo CD 的集成和回退职责、金丝雀策略、指标分析机制、ApplicationSet Progressive Syncs。