生产最佳实践与检查清单
Argo Rollouts 的可靠性来自完整的发布闭环，而不是某一个 YAML 字段。生产环境应同时管理应用健康、流量路由、指标可信度、资源容量、权限和回滚路径。
1. 发布策略
- 低风险内部服务可以从 Blue-Green 开始，先验证 Preview 环境和回滚路径；
- 高流量服务可使用 5% → 10% → 25% → 50% → 100% 的 Canary 阶梯；
- 每次提高权重后应留出足够的指标采样窗口；
- 发布步骤中明确哪些阶段自动推进，哪些阶段必须人工确认；
- 小流量服务不要机械套用百分比，应通过时间窗口、合成流量或离线测试补充样本。
2. 指标与门禁
至少准备以下几类指标：
| 指标 | 用途 | 注意事项 |
|---|---|---|
| HTTP 5xx 比例 | 判断服务端错误 | 排除健康检查和已知客户端错误 |
| p95/p99 延迟 | 判断性能回归 | 固定统计窗口和请求量下限 |
| 请求成功率 | 判断业务接口是否可用 | 按关键接口或业务动作拆分 |
| Pod 重启/Ready | 判断工作负载稳定性 | 不能替代业务指标 |
| 订单、支付等业务指标 | 判断核心功能 | 需要脱敏、隔离和明确阈值 |
阈值应经过历史基线验证。先观察旧版本在正常高峰期的分布，再设置新版本的相对变化门槛；不要只凭一次发布经验设置固定数字。
3. 时间、容量与回滚
pause时间应覆盖指标采样、缓存预热和业务高峰验证；scaleDownDelaySeconds要覆盖连接排空、异步任务完成和快速回滚窗口；- Canary 和 Blue-Green 都可能同时运行多个 ReplicaSet，节点和 Namespace 必须预留容量；
- 设置
revisionHistoryLimit，避免历史 ReplicaSet 无限积累； - PDB、HPA、Cluster Autoscaler 与 Rollout 的副本变更要联合验证；
- 发布前确认旧版本镜像仍可拉取，回滚不应依赖已经删除的镜像。
4. 数据库与消息队列
应用发布通常比数据库发布容易回滚。建议采用 expand → migrate → contract 的兼容迁移方式：
- 先增加新旧版本都能理解的字段或索引；
- 发布应用，让新旧版本并存时都能正常读写；
- 完成数据回填和验证；
- 最后在确认不再需要旧字段后再清理。
消息格式也应保持向后兼容，避免 Canary 消费者读取无法解析的消息导致整批发布失败。
5. GitOps 集成
推荐由 CI 更新不可变镜像 tag 或 digest，Argo CD 同步 Rollout YAML，Argo Rollouts 执行渐进式发布：
代码提交
-> CI 测试并构建 image:<git-sha>
-> 更新部署仓库中的 image digest
-> Argo CD 同步 Rollout
-> Rollouts 按权重发布并执行 AnalysisRun
-> Synced + Healthy + 业务验证
紧急 CLI 操作可以作为止血手段，但最终状态必须回写 Git。否则下次 Argo CD 同步会把现场状态覆盖，审计记录也无法解释为什么发生了版本变化。
6. 安全与权限
- Rollout Controller 使用官方或经过审计的 ServiceAccount；
- 发布机器人仅获得目标 Namespace 和必要资源的最小权限；
- Prometheus、Git、Registry 和 Kubernetes API 的凭据放入 Secret 或外部密钥系统；
- Analysis 查询不要泄露用户标识、订单信息或 Token；
- Dashboard、CLI API 和流量入口都需要 TLS、认证和网络访问控制；
abort、promote、retry等操作应写入审计日志。
7. 发布前检查清单
- 镜像使用不可变 tag 或 digest，旧版本镜像仍可拉取；
- Rollout 的 Service、Ingress、VirtualService 或 HTTPRoute 名称正确；
- 稳定和金丝雀版本的标签、selector、subset 已验证；
- ReadinessProbe、StartupProbe 和业务健康检查可用；
- AnalysisTemplate 查询能返回数据，阈值有历史基线；
-
pause、promote、abort和回滚负责人明确； - 发布期间有足够节点、Pod、PDB 和 HPA 容量；
- 数据库迁移和消息格式兼容旧版本；
- Argo CD、Rollouts Controller、流量入口和监控组件版本兼容；
- 变更单、Git commit、镜像 digest 和发布窗口一致。