跳到主要内容

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

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

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

Argo Rollouts 渐进式交付总体架构图

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

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

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

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

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

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

组件负责什么不负责什么
CI（GitLab CI、Jenkins）编译、测试、构建镜像、生成部署变更长期管理生产流量和发布状态
Argo CD从 Git 渲染并同步 Kubernetes 期望状态依据业务指标决定是否放量
Argo Rollouts管理 Rollout、ReplicaSet、暂停、晋级、回滚替代 Git 仓库和镜像构建系统
Service / Ingress / Istio把请求路由到稳定版本或金丝雀版本解释指标是否达标
Prometheus / APM提供错误率、延迟、业务指标执行版本切换

典型链路是：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 与 Blue-Green 发布策略对比图

策略流量特点适用场景主要代价
Canary新旧版本同时运行，按权重逐步放量高流量服务、希望用真实流量验证需要流量路由与稳定指标
Blue-Green新版本先在 Preview 环境完整启动，确认后一次切换需要快速切换或完整预览环境发布期间需要两套副本容量

选择策略时不要只看“哪种更先进”。如果服务没有可靠的指标、没有可控的路由入口，先把健康检查和监控补齐，通常比直接引入复杂的 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. 最后补充发布检查清单、告警、审计和恢复演练。
不要把 Rollout 当成自动修复系统

Rollout 只能根据已声明的步骤和指标执行动作。业务指标不完整、ReadinessProbe 不可靠或流量没有真正经过路由器时，自动晋级可能只是“自动放大风险”。