Argo Rollouts灰度发布的关键，不是把流量切成 10%、50%、100%，而是每个阶段如何判断“继续、暂停、回滚或人工介入”。Argo Rollouts 支持 canary、blue-green、analysis、experiments 等高级发布能力[1]，但工具只提供执行框架，发布标准仍需要团队自己定义。
本文把重点放在指标闸门、暂停审批和回滚决策，而不是泛讲金丝雀与蓝绿概念。如果你还在建立 Kubernetes 发布基础，可以先阅读 Kubernetes容器 分类入口；如果关注 GitOps 发布审计，可结合 GitOps回滚与变更审计 设计仓库状态与线上状态的一致性。
图1：Argo Rollouts 通过排查决策树判断继续放量、
发布闸门先于放量步骤
灰度发布最常见的问题，是只有放量步骤，没有退出条件。10% 阶段看什么？观察多久？谁有权批准继续？哪类异常自动回滚？如果这些问题没有提前定义，灰度只是在延长发布过程。
一个发布阶段至少要有四个条件：
- 继续条件：错误率、延迟、业务成功率在阈值内。
- 暂停条件：指标轻微异常、样本量不足或依赖波动。
- 回滚条件：用户可见错误、关键链路失败或错误率持续超阈。
- 人工介入条件：指标冲突、上游异常或自动分析无法判断。
Argo Rollouts 的 Analysis 能在发布过程中运行指标检查，并根据成功或失败条件影响 Rollout 状态[2]。因此，指标闸门应该先于 YAML 编写完成，而不是上线后临时补。
金丝雀与蓝绿：按风险暴露方式选择
金丝雀发布适合逐步放量，能让异常先暴露在小流量范围。蓝绿发布适合新旧版本整体切换，回退路径更直接，但需要同时保留两套环境和入口切换能力。
| 决策维度 | 金丝雀更适合 | 蓝绿更适合 |
|---|---|---|
| 风险暴露 | 逐步扩大影响面 | 切换前集中验证 |
| 资源占用 | 可按比例增加 | 需要完整保留新旧版本 |
| 回退方式 | 降低新版本权重或 abort | 切回旧 Service 或环境 |
| 指标要求 | 每阶段都要可观测 | 切换前后健康检查更关键 |
| 典型场景 | API、微服务、灰度人群 | 前后端整体版本、入口切换 |
比例不是策略，指标才是策略
“10%—50%—100%”只是流量动作。真正的策略是：这些阶段分别验证哪些指标、需要多少样本、允许多长时间波动，以及异常后如何止损。
Rollout 配置要服务决策链
Rollout 类似 Deployment，但增加了发布策略、步骤、暂停和分析。下面示例只展示 canary 步骤结构，实际字段应以 Argo Rollouts 规范为准[3]。
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
name: payment-api
spec:
replicas: 6
strategy:
canary:
steps:
- setWeight: 10
- pause: {duration: 10m}
- analysis:
templates:
- templateName: payment-api-slo
- setWeight: 50
- pause: {}
- setWeight: 100
selector:
matchLabels:
app: payment-api
template:
metadata:
labels:
app: payment-api
spec:
containers:
- name: app
image: registry.example.com/payment-api:v2这个示例不能直接当作生产模板。生产配置还要考虑 Service、流量路由、探针、AnalysisTemplate、指标窗口、通知和回滚策略。
图2：金丝雀发布按流量阶段、指标观察和人工暂停点逐步推进
AnalysisTemplate固化判断
AnalysisTemplate 适合把发布判断固化为查询和阈值。常见指标包括 5xx 比例、P95/P99 延迟、业务成功率、队列积压、错误日志速率和关键接口成功率[2]。
指标设计要避免三类误判：
- 只看基础设施指标：CPU 正常不代表业务正确。
- 窗口太短：瞬时抖动容易触发误回滚。
- 窗口太长：异常暴露慢，止损不及时。
更稳妥的做法是分层：
- 硬阻断指标：关键接口 5xx、支付/登录等核心成功率。
- 观察指标：P95 延迟、队列积压、依赖错误。
- 解释指标：CPU、内存、GC、连接池、下游限流。
自动回滚要保留人工兜底
自动分析适合明确阈值，不适合处理所有复杂异常。指标冲突、上游依赖波动、数据迁移兼容和缓存异常，往往需要人工暂停后再判断。
回滚决策：先定义证据，再定义命令
回滚不是发布失败后的临时动作。发布前就应明确：触发回滚的证据是什么、谁确认、回滚到哪个版本、GitOps 仓库是否同步、数据库和配置是否兼容。
上线前至少检查：
- 旧版本镜像、配置和 Secret 仍可用。
- 数据库变更兼容新旧版本。
- Rollout abort、pause、undo 命令经过测试。
- 指标告警能关联到具体 Rollout revision。
- GitOps 仓库期望状态与线上回滚动作不会互相覆盖。
Argo Rollouts CLI 的查看、暂停、终止和回滚命令应以官方 kubectl plugin 文档为准[1]，并纳入发布窗口和权限控制。
kubectl argo rollouts get rollout payment-api -n prod
kubectl argo rollouts pause payment-api -n prod
kubectl argo rollouts abort payment-api -n prod
kubectl argo rollouts undo payment-api -n prod这些命令可能影响生产发布状态，真实执行前应确认发布窗口、责任人和影响范围。
图3：Argo Rollouts 发布异常时从指标、暂停、终止
发布后复盘：把闸门调优而不是只归档结果
每次灰度结束后，都应回看指标闸门是否合适。误回滚说明阈值、窗口或样本量可能过敏；漏报说明指标覆盖不够；人工反复介入说明自动判断条件不清晰。
复盘重点不是“发布成功了吗”，而是：
- 哪个指标最早发现异常。
- 哪个指标没有解释价值，可以降级或删除。
- 哪个阶段样本量不足。
- 哪些回滚动作仍依赖人工记忆。
- GitOps 仓库和线上 revision 是否一致。
小结
Argo Rollouts灰度发布把 Kubernetes 发布从“副本替换”推进到“按证据决策”。金丝雀和蓝绿只是风险暴露方式，真正决定质量的是指标闸门、暂停点、回滚证据和 GitOps 状态一致性。
落地时不要只追求自动化。可解释的暂停和可验证的回滚，比无条件自动放量更重要。
参考资料
常见问题
1. Rollouts 和 Deployment 有何区别？
Deployment rolling update 主要负责逐步替换副本；Argo Rollouts 增加了金丝雀、蓝绿、Analysis、暂停和回滚等决策能力，更适合需要分阶段观察和止损的生产发布。
2. 金丝雀发布一定比蓝绿发布更安全吗？
不一定。金丝雀能逐步暴露风险，但依赖细粒度流量控制和指标判断；蓝绿切换快、回退路径清晰，但资源成本更高，也可能一次暴露较大影响面。
3. AnalysisTemplate 应该先从哪些指标开始？
建议优先选择用户可见指标，例如 5xx、关键接口成功率、P95/P99 延迟和核心业务成功率。CPU、内存更适合作为解释指标，而不是唯一放行依据。
4. 自动回滚会不会误伤正常发布？
会有可能。阈值过敏、样本量不足或上游依赖抖动都可能触发误回滚。建议设置观察窗口、最小样本量和人工暂停点，关键业务不要完全依赖单一指标自动判断。
5. GitOps 场景下手动 undo 后还要改仓库吗？
通常需要让 Git 仓库期望状态与线上状态重新对齐，否则控制器可能再次把线上状态同步回问题版本。具体流程应由发布平台或 GitOps 规范定义。
