Argo Rollouts

Argo Rollouts #

Kubernetes Progressive Delivery Controller — 提供蓝绿部署、金丝雀发布、流量管理和自动化分析能力。CNCF Graduated 项目。

WebsiteDocGithubDemoComment
Argo RolloutsDocGithubDemoCNCF 毕业项目,K8s 原生渐进式交付控制器

Read First #

Docs, Github, CNCF

Concepts

Architecture

Getting Started

Rollout Specification

Killercoda Argo Rollouts Labs — 在线实验环境


核心概念 #

Progressive Delivery(渐进式交付) #

渐进式交付是持续交付的演进,通过限制新版本的暴露范围观察分析行为逐步扩大范围持续验证正确性,降低发布风险:

  • 控制爆炸半径(Blast Radius):新版本仅暴露给少量用户
  • 自动化推广/回滚:基于指标分析结果自动决策
  • 细粒度流量控制:按百分比、Header、镜像流量等方式分流

Rollout CRD #

Rollout 是 Argo Rollouts 的核心 CRD,等价于 Kubernetes Deployment 但具备更高级的部署策略:

特性DeploymentRollout
滚动更新✅ RollingUpdate✅ 支持(canary 无 steps 时等同)
蓝绿部署
金丝雀发布✅ 多阶段百分比控制
流量精细控制✅ 配合 Service Mesh/Ingress
自动化分析✅ AnalysisTemplate/AnalysisRun
自动回滚✅ 基于指标自动回滚
人工审批✅ pause 步骤

支持的部署策略 #

策略说明流量切换需要流量管理器
Blue-Green新旧版本同时运行,仅旧版本接收流量,验证后一键切换全量切换(0%→100%)
Canary(基础)按副本数比例分配流量粗粒度百分比
Canary + Traffic Routing通过 Service Mesh/Ingress 精细控制流量细粒度百分比 + Header + 镜像

策略选择指南

维度Blue-Green基础 CanaryCanary + 流量管理
采用复杂度
灵活性最高
需要流量管理器
适用队列 Worker
适用共享/锁资源
失败爆炸半径大(全量切换)

架构 #

┌──────────────────────────────────────────────────────────────────┐
│                    Argo Rollouts Controller                       │
│                                                                  │
│  ┌───────────────────────────────────────────────────────────┐   │
│  │            Rollout Reconciler (核心控制器)                  │   │
│  │   Watch Rollout CRD → 管理 ReplicaSet → Reconcile 状态     │   │
│  └──────────┬────────────────────────────────┬───────────────┘   │
│             │                                │                    │
│  ┌──────────┴──────────┐   ┌────────────────┴──────────────┐    │
│  │ Traffic Router      │   │ Analysis Controller           │    │
│  │ (操作 Ingress/Mesh) │   │ (创建/监控 AnalysisRun)       │    │
│  └──────────┬──────────┘   └────────────────┬──────────────┘    │
│             │                                │                    │
└─────────────┼────────────────────────────────┼────────────────────┘
              │                                │
    ┌─────────┴─────────┐           ┌──────────┴──────────┐
    │ Ingress/Mesh      │           │ Metric Provider     │
    │ (Istio/NGINX/ALB) │           │ (Prometheus/Datadog)│
    └─────────┬─────────┘           └─────────────────────┘
              │
    ┌─────────┴──────────────────────────────────────┐
    │          K8s 集群 (工作负载层)                    │
    │                                                  │
    │  ┌──────────────┐    ┌──────────────────────┐   │
    │  │ Stable RS    │    │ Canary/New RS        │   │
    │  │ (当前稳定版)  │    │ (新版本/预览版)       │   │
    │  └──────┬───────┘    └──────────┬───────────┘   │
    │         │                       │                │
    │  ┌──────┴───────┐    ┌──────────┴───────────┐   │
    │  │ Stable Svc   │    │ Canary/Preview Svc   │   │
    │  └──────────────┘    └──────────────────────┘   │
    └──────────────────────────────────────────────────┘

核心组件 #

组件职责
Rollout Controller主控制器,Watch Rollout CRD,管理 ReplicaSet 的创建/扩缩/删除,驱动状态 Reconcile
Traffic Router操作 Ingress Controller 或 Service Mesh 资源,实现精细流量分割
Analysis Controller创建 AnalysisRun,查询指标,判断成功/失败/不确定,驱动自动推广或回滚
Dashboard (UI)可选的 Web UI,可视化 Rollout 进度和状态
kubectl Plugin可选的 CLI 工具,管理 Rollout 操作(pause/promote/abort 等)

核心 CRD #

CRD说明
Rollout替代 Deployment 的工作负载资源,定义部署策略(canary/blueGreen)、步骤和分析
AnalysisTemplate定义指标查询模板(PromQL/SQL/Web),可被多个 Rollout 引用
ClusterAnalysisTemplate集群级别的分析模板,跨 namespace 共享
AnalysisRunAnalysisTemplate 的一次具体执行实例,记录查询结果和状态
ExperimentA/B 测试实验资源,支持多版本同时运行并对比分析

快速开始 #

1. 安装 Controller #

kubectl create namespace argo-rollouts
kubectl apply -n argo-rollouts \
  -f https://github.com/argoproj/argo-rollouts/releases/latest/download/install.yaml

2. 安装 kubectl Plugin(CLI) #

# macOS
brew install argo-rollouts

# 或从 GitHub Releases 下载
# https://github.com/argoproj/argo-rollouts/releases/latest

# 验证安装
kubectl argo rollouts version

3. 访问 Dashboard #

# 启动 Dashboard
kubectl argo rollouts dashboard

# 默认监听 http://localhost:3100

4. 创建第一个 Rollout #

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: rollouts-demo
spec:
  replicas: 5
  strategy:
    canary:
      steps:
        - setWeight: 20
        - pause: {}
        - setWeight: 40
        - pause: { duration: 10s }
        - setWeight: 60
        - pause: { duration: 10s }
        - setWeight: 80
        - pause: { duration: 10s }
  selector:
    matchLabels:
      app: rollouts-demo
  template:
    metadata:
      labels:
        app: rollouts-demo
    spec:
      containers:
        - name: rollouts-demo
          image: argoproj/rollouts-demo:blue
          ports:
            - containerPort: 8080

5. 常用操作 #

# 查看 Rollout 状态
kubectl argo rollouts get rollout rollouts-demo --watch

# 更新镜像触发滚动
kubectl argo rollouts set image rollouts-demo \
  rollouts-demo=argoproj/rollouts-demo:yellow

# 手动推广(解除 pause)
kubectl argo rollouts promote rollouts-demo

# 中止并回滚
kubectl argo rollouts abort rollouts-demo

# 重试已中止的 Rollout
kubectl argo rollouts retry rollouts-demo

# 重启所有 Pod
kubectl argo rollouts restart rollouts-demo

Blue-Green 策略 #

蓝绿部署同时运行新旧版本,新版本就绪后一次性切换流量:

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: bluegreen-demo
spec:
  replicas: 3
  strategy:
    blueGreen:
      activeService: active-service        # 生产流量 Service
      previewService: preview-service      # 预览 Service(仅测试用)
      autoPromotionEnabled: false          # 禁用自动推广(需手动审批)
      autoPromotionSeconds: 30             # 或:就绪后 30s 自动推广
      previewReplicaCount: 1               # 预览阶段只运行 1 个副本
      scaleDownDelaySeconds: 30            # 切换后延迟 30s 缩容旧版本
      prePromotionAnalysis:                # 切换前分析
        templates:
          - templateName: smoke-tests
      postPromotionAnalysis:               # 切换后分析
        templates:
          - templateName: success-rate
  selector:
    matchLabels:
      app: bluegreen-demo
  template:
    metadata:
      labels:
        app: bluegreen-demo
    spec:
      containers:
        - name: app
          image: myapp:v1

Blue-Green 流程

1. 新版本 ReplicaSet 创建(Preview Service 指向新版本)
   ┌─────────┐     ┌─────────┐
   │ Active  │     │ Preview │
   │  (v1)   │     │  (v2)   │
   │ ← 流量  │     │ ← 测试  │
   └─────────┘     └─────────┘

2. Pre-Promotion Analysis 通过(或手动 Promote)

3. Active Service 切换到 v2
   ┌─────────┐     ┌─────────┐
   │ Active  │     │ Preview │
   │  (v2)   │     │  (v1)   │
   │ ← 流量  │     │ (缩容中) │
   └─────────┘     └─────────┘

4. Post-Promotion Analysis → 确认成功 → 缩容旧版本

关键配置

字段说明
activeService指向当前生产版本的 Service(必需)
previewService指向新版本的预览 Service(可选)
autoPromotionEnabled是否自动推广(默认 true
autoPromotionSeconds就绪后延迟 N 秒自动推广
previewReplicaCount预览阶段运行的副本数
scaleDownDelaySeconds切换后旧版本延迟缩容(默认 30s,确保 IP 表传播)
prePromotionAnalysis切换前执行的自动分析
postPromotionAnalysis切换后执行的自动分析

Canary 策略 #

基础 Canary(无流量管理器) #

通过 ReplicaSet 副本数比例分配流量:

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: canary-demo
spec:
  replicas: 10
  strategy:
    canary:
      steps:
        - setWeight: 10        # 10% 流量 → canary (1/10 pods)
        - pause: {}             # 等待人工审批
        - setWeight: 30        # 30% 流量 → canary (3/10 pods)
        - pause: { duration: 5m }  # 等待 5 分钟
        - setWeight: 50        # 50%
        - pause: { duration: 5m }
        - setWeight: 100       # 全量
  selector:
    matchLabels:
      app: canary-demo
  template:
    metadata:
      labels:
        app: canary-demo
    spec:
      containers:
        - name: app
          image: myapp:v2

Canary + Traffic Routing(精细流量控制) #

配合 Service Mesh/Ingress 实现精细流量分割:

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: canary-traffic-demo
spec:
  replicas: 5
  strategy:
    canary:
      canaryService: canary-service     # Canary Service
      stableService: stable-service     # Stable Service
      trafficRouting:
        istio:                          # 使用 Istio 流量管理
          virtualService:
            name: myapp-vsvc
            routes:
              - primary
      steps:
        - setWeight: 5
        - pause: {}
        - setWeight: 20
        - analysis:                     # 步骤间插入分析
            templates:
              - templateName: success-rate
        - setWeight: 50
        - pause: { duration: 10m }
        - setWeight: 100
  selector:
    matchLabels:
      app: canary-traffic-demo
  template:
    metadata:
      labels:
        app: canary-traffic-demo
    spec:
      containers:
        - name: app
          image: myapp:v2

Canary Steps 全部类型 #

Step说明
setWeight: <0-100>设置 canary 流量百分比
pause: {}无限期暂停,等待手动 promote
pause: { duration: 5m }暂停指定时间后自动继续
setCanaryScale: { replicas: 3 }设置 canary 副本数(不影响流量权重)
setCanaryScale: { weight: 25 }按比例设置 canary 副本数
setCanaryScale: { matchTrafficWeight: true }canary 副本数匹配流量权重
analysis: { templates: [...] }执行内联分析
experiment: { ... }执行内联实验
setHeaderRoute: { ... }设置基于 Header 的路由(仅 Istio)
setMirrorRoute: { ... }设置流量镜像路由(仅 Istio)
plugin: { name: ..., config: ... }执行自定义插件

流量管理 #

Argo Rollouts 通过操纵 Ingress Controller 或 Service Mesh 资源实现精细流量控制:

支持的流量管理器 #

类型提供者说明
Service MeshIstio最完整支持(Header/Mirror/权重)
Service MeshSMIService Mesh Interface(Linkerd 等)
IngressNGINXNGINX Ingress Controller
IngressAWS ALBAWS ALB Ingress Controller
IngressApache APISIXApache APISIX 网关
IngressKongKong Ingress
IngressTraefikTraefik Proxy
IngressAmbassadorAmbassador Edge Stack
IngressGoogle CloudGoogle Cloud Load Balancer
PluginGateway API通过 Plugin 支持 Gateway API

支持同时使用多个流量管理器(如 Istio + NGINX),实现更复杂的流量路由场景。

流量管理配置示例(Istio) #

strategy:
  canary:
    canaryService: canary-service
    stableService: stable-service
    trafficRouting:
      managedRoutes:              # 管理路由的优先级
        - name: set-header-1
        - name: mirror-route
      istio:
        virtualService:
          name: myapp-vsvc
          routes:
            - primary
    steps:
      # 1. 设置权重
      - setWeight: 20
      # 2. Header 路由(带特定 Header 的请求全部路由到 canary)
      - setHeaderRoute:
          name: set-header-1
          match:
            - headerName: X-Canary
              headerValue:
                exact: "true"
      - pause: {}
      # 3. 流量镜像(将匹配流量镜像到 canary)
      - setMirrorRoute:
          name: mirror-route
          percentage: 35
          match:
            - method:
                exact: GET
              path:
                prefix: /api
      - pause: { duration: 10m }
      # 4. 清理路由
      - setHeaderRoute:
          name: set-header-1      # 仅 name = 删除路由
      - setMirrorRoute:
          name: mirror-route
      - setWeight: 100

Analysis(自动化分析) #

Analysis 是 Argo Rollouts 的核心差异化能力——通过查询指标自动判断新版本是否成功:

分析结果 #

结果含义行为
Successful指标符合预期自动推广到下一阶段
Failed指标不符合预期自动中止并回滚
Inconclusive无法判断暂停 Rollout,等待人工介入

AnalysisTemplate 示例 #

apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: success-rate
spec:
  args:
    - name: service-name
    - name: stable-hash
    - name: latest-hash
  metrics:
    - name: success-rate
      interval: 5m                    # 每 5 分钟查询一次
      provider:
        prometheus:
          address: http://prometheus:9090
          query: |
            sum(rate(
              requests_total{service="{{args.service-name}}", status=~"2.."}[5m]
            )) / sum(rate(
              requests_total{service="{{args.service-name}}"}[5m]
            ))
      successCondition: result[0] >= 0.95    # 成功率 >= 95% 则成功
      failureLimit: 3                         # 连续 3 次失败则回滚
      consecutiveErrorLimit: 2              # 连续 2 次查询错误则暂停

支持的指标提供者 #

Provider说明
Prometheus最常用的开源监控方案
DatadogSaaS 监控平台
New RelicAPM 平台
WavefrontVMware Tanzu 监控
InfluxDB时序数据库
Graphite轻量级监控
KayentaNetflix 金丝雀分析引擎
WebHTTP Webhook 调用
JobKubernetes Job(自定义检查逻辑)
CloudWatchAWS CloudWatch Metrics

Analysis 触发时机 #

触发方式适用策略说明
Background AnalysisCanary在整个 canary 过程中持续运行
Inline AnalysisCanary Steps作为 canary step 在特定阶段执行
Pre-Promotion AnalysisBlue-Green在流量切换前执行
Post-Promotion AnalysisBlue-Green在流量切换后执行
# Background Analysis(canary 过程中持续监控)
strategy:
  canary:
    analysis:
      templates:
        - templateName: success-rate
      args:
        - name: service-name
          value: myapp-svc

# Inline Analysis(作为 canary step 执行)
steps:
  - setWeight: 20
  - analysis:
      templates:
        - templateName: smoke-tests
  - setWeight: 50

Experiments(实验/A-B 测试) #

Experiment 允许在不影响生产流量的情况下,同时运行多个版本并进行对比分析:

apiVersion: argoproj.io/v1alpha1
kind: Experiment
metadata:
  name: my-experiment
spec:
  duration: 1h                  # 实验持续 1 小时
  templates:
    - name: baseline
      specRef: stable           # 基于稳定版本 ReplicaSet 模板
    - name: canary
      specRef: canary           # 基于新版本 ReplicaSet 模板
      weight: 10                # 分配 10% 流量
  analyses:
    - name: compare
      templateName: mann-whitney    # 对比分析模板

Experiment 也可嵌入 Canary Steps

steps:
  - setWeight: 20
  - experiment:
      duration: 1h
      templates:
        - name: baseline
          specRef: stable
        - name: canary
          specRef: canary
          weight: 10
      analyses:
        - name: mann-whitney
          templateName: mann-whitney

Rollout Spec 关键字段 #

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: my-rollout
spec:
  replicas: 5                          # 期望副本数
  revisionHistoryLimit: 3              # 保留历史 ReplicaSet 数量(默认 10)
  minReadySeconds: 30                  # Pod 就绪后等待时间
  progressDeadlineSeconds: 600         # 更新超时时间(默认 600s)
  progressDeadlineAbort: false         # 超时是否自动中止
  rollbackWindow:
    revisions: 3                       # 快速回滚窗口(跳过 analysis)

  # Pod 模板(与 Deployment 一致)
  selector:
    matchLabels:
      app: myapp
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
        - name: app
          image: myapp:v1

  # 或使用 workloadRef 引用现有 Deployment
  workloadRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-deployment
    scaleDown: onsuccess              # never | onsuccess | progressively

  strategy:
    canary: { ... }                   # 或 blueGreen: { ... }

WorkloadRef(引用已有 Deployment) #

允许不修改现有 Deployment spec 的情况下,将其迁移到 Rollout 管理:

spec:
  workloadRef:
    apiVersion: apps/v1
    kind: Deployment
    name: existing-deployment
    scaleDown: progressively     # 逐步缩容原 Deployment
scaleDown 模式说明
never不缩容原 Deployment(并行运行)
onsuccessRollout 健康后缩容原 Deployment
progressivelyRollout 扩缩时同步缩容原 Deployment

与 Argo CD 集成 #

Argo Rollouts 与 Argo CD 配合实现完整的 GitOps 渐进式交付:

# Argo CD Application 管理 Rollout 定义
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: myapp
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/org/myapp-config
    path: kustomize/production
    targetRevision: main
  destination:
    server: https://kubernetes.default.svc
    namespace: myapp
  syncPolicy:
    automated:
      selfHeal: true
      prune: true

工作流

1. CI 构建镜像 → 推送到 Registry
2. CI 更新 Git 中的镜像 tag(kustomize edit set image ...)
3. Argo CD 检测 Git 变更 → 同步 Rollout YAML 到集群
4. Argo Rollouts Controller 检测 Rollout spec 变更
5. 执行 Canary/BlueGreen 策略 → Analysis 自动分析
6. 成功 → 自动推广 / 失败 → 自动回滚

重要:Argo CD 的 syncPolicy.automated 与 Rollout 的 strategy 不冲突。Argo CD 负责将 Rollout YAML 同步到集群(声明式管理),Rollout Controller 负责执行部署策略(渐进式交付)。


常用 CLI 命令 #

# 状态查看
kubectl argo rollouts get rollout <name>              # 查看 Rollout 状态
kubectl argo rollouts get rollout <name> --watch       # 实时观察
kubectl argo rollouts list rollouts                    # 列出所有 Rollout
kubectl argo rollouts history <name>                   # 查看历史版本

# 部署操作
kubectl argo rollouts set image <rollout> <container>=<image>  # 更新镜像
kubectl argo rollouts promote <name>                   # 手动推广
kubectl argo rollouts promote <name> --full            # 跳过所有步骤直接全量
kubectl argo rollouts abort <name>                     # 中止(回滚)
kubectl argo rollouts retry <name>                     # 重试已中止的 Rollout
kubectl argo rollouts restart <name>                   # 重启所有 Pod
kubectl argo rollouts pause <name>                     # 手动暂停
kubectl argo rollouts undo <name>                      # 回滚到上一版本

# 流量管理
kubectl argo rollouts set-weight <name> <weight>       # 手动设置流量权重
kubectl argo rollouts set-mirror <name> <percentage>   # 设置流量镜像

# Analysis
kubectl argo rollouts get analysisrun <name>           # 查看分析运行
kubectl argo rollouts terminate <name>                 # 终止分析运行

# Dashboard
kubectl argo rollouts dashboard                        # 启动 Web UI

# 版本
kubectl argo rollouts version                          # 查看 CLI 版本

最佳实践 #

实践说明
从 Blue-Green 开始入门简单,不需要流量管理器,适合初期采用
逐步迁移到 Canary建立信心后切换到 Canary + Traffic Routing 获得更细粒度控制
使用 Analysis 自动化避免纯人工审批,通过指标分析自动推广/回滚
配合 HPARollout 与 HPA 兼容,支持根据流量自动扩缩容
配合 VPA支持 VPA 自动调整资源请求/限制
Rollback Window设置 rollbackWindow.revisions 实现快速回滚(跳过 Analysis)
Ephemeral Metadata使用 canaryMetadata/stableMetadata 给不同版本 Pod 打标签(用于监控区分)
scaleDownDelaySecondsBlue-Green 切换后保留旧版本至少 30s,确保 IP 表传播完成
progressDeadlineSeconds设置合理超时,防止 Rollout 无限卡住
与 Argo CD 集成Argo CD 管理 Rollout YAML,Rollout Controller 管理实际部署

从 Deployment 迁移 #

# 1. 安装 Argo Rollouts Controller
# 2. 将 Deployment 改为 Rollout(apiVersion: argoproj.io/v1alpha1, kind: Rollout)
# 3. 添加 strategy 字段(canary 或 blueGreen)
# 4. kubectl apply 即可

# 或使用 workloadRef 渐进迁移(不修改现有 Deployment)

Question #

基础概念 #

#问题参考答案
1Argo Rollouts 解决了 Kubernetes Deployment 的什么问题?Deployment 的 RollingUpdate 策略缺乏:(1) 精细流量控制;(2) 外部指标验证;(3) 自动回滚能力;(4) 人工审批机制。Rollout 提供蓝绿/金丝雀部署 + 自动分析 + 流量管理的完整渐进式交付方案。
2Blue-Green 和 Canary 策略的核心区别是什么?Blue-Green 是全量切换(0%→100%),新旧版本同时运行但流量只走一个;Canary 是渐进式发布(5%→20%→50%→100%),两个版本同时接收流量。Blue-Green 更简单但爆炸半径大,Canary 更灵活但需要流量管理器才能发挥最大价值。
3Argo Rollouts 的核心 CRD 有哪些?Rollout(替代 Deployment 的工作负载)、AnalysisTemplate(指标查询模板)、AnalysisRun(分析执行实例)、Experiment(A/B 测试实验)、ClusterAnalysisTemplate(集群级分析模板)。

部署策略 #

#问题参考答案
4Canary 的 setWeight 在无 Traffic Routing 时如何实现流量分割?通过调整 ReplicaSet 副本数比例。例如 10 个副本 setWeight: 20 → canary RS 运行 2 个 Pod,stable RS 运行 8 个 Pod。Service 的负载均衡按 Pod 数量分配流量,实现粗粒度百分比控制。
5Blue-Green 的 prePromotionAnalysis 和 postPromotionAnalysis 分别何时执行?prePromotionAnalysis 在新版本 ReplicaSet 就绪后、Active Service 切换前执行——用于验证新版本功能正确性;postPromotionAnalysis 在 Active Service 切换后执行——用于验证生产流量下新版本的表现。
6什么是 setCanaryScale?和 setWeight 有什么区别?setWeight 控制流量百分比(通过 Traffic Router 或副本数),setCanaryScale 仅控制 canary 的副本数而不改变流量权重。适用于需要先扩容 canary Pod(如配合 HPA 预热)再逐步增加流量的场景。

流量管理与分析 #

#问题参考答案
7Argo Rollouts 支持哪些流量管理器?Istio、SMI(Linkerd)、NGINX Ingress、AWS ALB、Apache APISIX、Kong、Traefik、Ambassador、Google Cloud、Gateway API(Plugin)。支持同时使用多个流量管理器。
8Analysis 的三种结果(Successful/Failed/Inconclusive)分别触发什么行为?Successful → 自动推进到下一阶段;Failed → 自动中止并回滚到稳定版本;Inconclusive → 暂停 Rollout 等待人工介入。这使得发布过程可以基于客观指标自动化决策。
9AnalysisTemplate 和 AnalysisRun 的关系是什么?AnalysisTemplate 是可复用的"模板",定义要查询什么指标和判断条件;AnalysisRun 是一次具体"执行",绑定到特定 Rollout 并记录查询结果。类似 Deployment(模板)和 ReplicaSet(实例)的关系。

生产实践 #

#问题参考答案
10Argo Rollouts 如何与 Argo CD 配合?Argo CD 负责 GitOps(将 Rollout YAML 从 Git 同步到集群),Rollout Controller 负责渐进式交付(执行 canary/blueGreen 策略)。两者职责分离,互不冲突。Argo CD 管理"声明式状态",Rollout 管理"实际部署过程"。
11什么是 Rollback Window?为什么需要它?rollbackWindow.revisions: N 定义最近 N 个版本为快速回滚窗口。当回滚到窗口内的版本时,Rollout 跳过 Analysis 直接切换——因为这些版本之前已经通过分析验证,无需重复检查,加速回滚过程。
12Ephemeral Metadata 的用途是什么?canaryMetadata/stableMetadata 在部署期间给不同版本的 Pod 注入临时 labels/annotations,用于:(1) Prometheus 按版本区分指标;(2) 日志系统按版本过滤;(3) Istio 路由规则匹配。部署结束后自动清除。

Reference #

Argo Rollouts Official Documentation

Argo Rollouts GitHub Repository

Argo Rollouts Examples

Argo Rollouts Demo Application

Killercoda Argo Rollouts Labs

CNCF Argo Rollouts Project Page

Awesome Argo

Argo Blog