用 Argo Rollouts 自动化金丝雀分析与回退

目标

盯着仪表盘的人的反应时间以分钟计、注意力以小时计，而坏金丝雀需要秒级裁决。Argo Rollouts 把裁决搬进集群：AnalysisTemplate 查询按版本拆分的错误率与延迟，每次放量都以结果为门禁，连续两次失败就中止回滚、在任何人醒来之前把流量还给稳定版。

步骤要点

1. 编写 AnalysisTemplate：每分钟查询 canary 版本 5xx 比率，result<0.02 为成功，failureLimit 2 连续失败即判死。
2. 把 analysis 挂进 Rollout 步骤：5%→5 分钟→门禁→25%→5 分钟→门禁→50%→100%。
3. 故意 set image 到 broken 版本并 –watch：第一次失败评估即中止，流量自动回到稳定版。
4. 补充 p99 延迟第二道护栏：功能正确但慢一倍的版本同样过不了门禁。
5. 确认 RolloutAborted 事件会推给值班，让“部署失败且已回退”在睡着时也能传达。

排错提示

分析拿不到数据通常是查询里的 version 标签与 rollout 注入的不一致，先在 Prometheus 里手跑查询对齐；结果来回翻转就改用计数型成功条件并调 failureLimit，让瞬时毛刺不误杀健康版本；Prometheus 挂掉时 provider 报错计为不确定，应显式设 errorLimit 让基础设施故障阻断晋级而非悄悄放行。

适用边界

自动分析的上限就是指标本身，没有按版本标签的服务无法对比；统计门禁需要每步有足够流量，低流量服务的 5% 可能样本太少而无法裁决。

代码示例

metrics:
  - name: error-rate
    interval: 1m
    successCondition: result[0] < 0.02
    failureLimit: 2
    provider:
      prometheus:
        address: http://prometheus:9090
        query: |
          sum(rate(http_requests_total{version="canary",code=~"5.."}[2m]))
          / sum(rate(http_requests_total{version="canary"}[2m]))