Argo Rollouts 概览与渐进式交付基础

Argo Rollouts 是 Kubernetes 上的渐进式交付控制器。它通过 Rollout 自定义资源替代或补充 Deployment 的发布策略，让新版本先获得有限流量，在指标和人工确认通过后再逐步扩大流量；如果发布失败，则可以暂停、终止或回滚，而不必一次性让所有 Pod 切换到新版本。

它解决的不是“如何构建镜像”，也不是“如何把 YAML 放进 Git”，而是发布过程中的风险控制：新版本如何获得流量、谁来判断它是否健康、失败后如何恢复以及整个过程如何审计。

1. 为什么需要渐进式交付

Kubernetes Deployment 的 RollingUpdate 会按 maxSurge 和 maxUnavailable 替换 Pod。它适合大多数无状态服务的常规升级，但它通常只关心 Pod 是否就绪，不会自动回答以下问题：

• 新版本的 HTTP 5xx 是否明显增加？
• p95 延迟是否超过发布门槛？
• 新版本是否只应该先接收 5% 的真实流量？
• 监控指标异常时，是否应自动停止并恢复旧版本？
• 业务负责人是否需要在 30% 流量阶段人工确认？

渐进式交付把发布拆成一系列可观察、可暂停、可回滚的阶段：

构建镜像 -> 创建新版本 ReplicaSet -> 小比例流量 -> 指标分析
       -> 人工或自动确认 -> 扩大流量 -> 全量完成
       -> 指标失败时暂停或回滚

2. Argo Rollouts 与其他组件的边界

典型链路是：CI 构建不可变镜像并提交部署仓库，Argo CD 同步 Rollout 和相关 Service，Argo Rollouts Controller 按策略创建新 ReplicaSet 并调用流量路由器，AnalysisRun 读取 Prometheus 等监控系统的结果。

3. 核心对象

3.1 Rollout

Rollout 与 Deployment 类似，也包含 replicas、Pod Template 和标签，但在 spec.strategy 中声明 Canary 或 Blue-Green 发布策略。Controller 根据 Rollout 的状态创建和管理 ReplicaSet。

3.2 Stable Service 与 Canary Service

Canary 发布通常准备两个 Service：

• stableService：指向当前稳定版本；
• canaryService：指向正在验证的新版本。

当只使用 Kubernetes Service 而没有额外流量路由时，流量比例不一定能按百分比精确切分；需要 Istio、NGINX Ingress、Gateway API 等流量提供者时，Rollout Controller 才能更新路由权重。

3.3 AnalysisTemplate 与 AnalysisRun

AnalysisTemplate 定义指标查询和成功阈值，AnalysisRun 是一次具体执行。AnalysisRun 可以在发布开始前、某个 setWeight 之后或发布完成后运行。

常见结果包括：

• Successful：指标达到成功条件，可以继续；
• Failed：指标超过失败阈值，Rollout 按策略暂停或回滚；
• Inconclusive：数据不足或无法判断，应由流程决定是否重试或人工处理。

4. Canary 与 Blue-Green 如何选择

选择策略时不要只看“哪种更先进”。如果服务没有可靠的指标、没有可控的路由入口，先把健康检查和监控补齐，通常比直接引入复杂的 Canary 更重要。

5. 学习与落地顺序

建议按以下顺序在测试集群实践：

1. 安装 Controller 和 CLI，确认 CRD、RBAC、Webhook 或流量路由组件正常；
2. 先运行不带流量分析的手工 Canary，理解暂停、晋级和终止；
3. 接入 Prometheus AnalysisTemplate，让指标结果影响发布；
4. 再实践 Blue-Green，验证 Preview Service 和回滚路径；
5. 接入 Argo CD，把 Rollout YAML 纳入 Git，并通过 PR 管理版本；
6. 最后补充发布检查清单、告警、审计和恢复演练。