6.8 GitOps 进阶——Argo Rollouts + Argo Workflows

预计阅读时间：12 分钟

在前文中我们介绍了 GitOps 的基础概念与 Argo CD 的核心用法。本文进入进阶阶段，围绕 Argo Rollouts（渐进式交付）与 Argo Workflows（DAG 工作流引擎）展开，打通从代码变更到生产发布的完整自动化链路。

学习目标

学完本章后，你将能够：

• 安装 Argo Rollouts 并编写 Canary 与 BlueGreen 两种渐进式发布策略
• 用 AnalysisTemplate 定义金丝雀验证指标（成功率、P99 延迟）与自动回滚规则
• 编排 Argo Workflows DAG 工作流，并用 WorkflowTemplate 复用通用步骤
• 通过 Webhook EventSource 触发 CI/CD 工作流
• 梳理 Argo CD、Rollouts、Workflows 三者职责，搭建从代码到生产的完整发布链路
• 用 kubectl argo rollouts 插件与 AnalysisRun 状态排查发布故障

前置知识

• 6.7：GitOps 入门 GitOps 入门——Argo CD 同步机制与 Git 仓库作为事实来源
• 6.2：Kubernetes 入门 Kubernetes 入门——Deployment、Service、Ingress 等基础对象
• k8s06 K8s：ServiceMesh入门——VirtualService 流量路由概念
• 4.9：CI/CD 持续部署 CI/CD 持续部署——流水线阶段设计与部署触发方式

一、Argo Rollouts 渐进式交付

Argo Rollouts 是 Kubernetes 的自定义控制器，扩展了 Deployment 的能力，提供 Canary 和 BlueGreen 两种渐进式发布策略。它与 Argo CD 深度集成，实现声明式、可观测的发布流程。

1.1 安装与 CRD

# 安装 Argo Rollouts
kubectl create namespace argo-rollouts
kubectl apply -n argo-rollouts -f https://github.com/argoproj/argo-rollouts/releases/latest/download/install.yaml

# 验证安装
kubectl get pods -n argo-rollouts

核心 CRD：Rollout。它替代原生 Deployment，在 spec 中声明发布策略。

1.2 Canary 发布

Canary 策略将新版本流量按比例逐步切到金丝雀实例，观察指标达标后全量推进。

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: my-app
spec:
  replicas: 10
  selector:
    matchLabels:
      app: my-app
  strategy:
    canary:
      canaryService: my-app-canary
      stableService: my-app-stable
      trafficRouting:
        istio:
          virtualServices:
          - name: my-app-vsvc
            routes:
            - primary
      steps:
      - setWeight: 10
      - pause: { duration: 5m }
      - setWeight: 30
      - pause: { duration: 5m }
      - setWeight: 60
      - pause: { duration: 5m }
      - setWeight: 100
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app
        image: my-app:v2.0.0
        ports:
        - containerPort: 8080

1.3 BlueGreen 发布

BlueGreen 同时运行新旧两套环境，通过切换 Service selector 实现零停机切换。

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: my-app
spec:
  replicas: 5
  selector:
    matchLabels:
      app: my-app
  strategy:
    blueGreen:
      activeService: my-app-active
      previewService: my-app-preview
      autoPromotionEnabled: false
      prePromotionAnalysis:
        templates:
        - templateName: smoke-test
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-app
        image: my-app:v2.0.0
        ports:
        - containerPort: 8080

二、Analysis Template（自动化金丝雀验证）

Analysis Template 是 Argo Rollouts 的自动化验证机制，通过查询 Prometheus、Datadog 等监控系统判断金丝雀是否健康，自动决定继续推进还是回滚。

2.1 定义 AnalysisTemplate

apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: success-rate
spec:
  args:
  - name: service-name
  metrics:
  - name: success-rate
    interval: 1m
    count: 5
    successCondition: result[0] >= 0.99
    failureLimit: 2
    provider:
      prometheus:
        address: http://prometheus.monitoring:9090
        query: |
          sum(rate(http_requests_total{service="{{args.service-name}}",code=~"2.."}[2m]))
          /
          sum(rate(http_requests_total{service="{{args.service-name}}"}[2m]))

2.2 在 Rollout 中引用

strategy:
  canary:
    analysis:
      templates:
      - templateName: success-rate
        args:
        - name: service-name
          value: my-app-canary
    steps:
    - setWeight: 20
    - pause: { duration: 3m }
    - setWeight: 50
    - pause: { duration: 3m }

三、Argo Workflows DAG 工作流

Argo Workflows 是 Kubernetes 原生的工作流引擎，支持以 DAG（有向无环图）或 Steps（线性步骤）模式编排多任务流程。

3.1 基本概念

3.2 DAG 工作流示例

apiVersion: argoproj.io/v1alpha1
kind: Workflow
metadata:
  generateName: build-test-deploy-
spec:
  entrypoint: pipeline
  arguments:
    parameters:
    - name: image-tag
      value: "v2.0.0"
  templates:
  - name: pipeline
    dag:
      tasks:
      - name: build
        template: build-image
      - name: lint
        template: run-lint
      - name: unit-test
        template: run-unit-test
      - name: integration-test
        template: run-integration-test
        dependencies: [build]
      - name: deploy-staging
        template: deploy
        dependencies: [lint, unit-test, integration-test]
      - name: e2e-test
        template: run-e2e-test
        dependencies: [deploy-staging]
      - name: deploy-production
        template: deploy-rollout
        dependencies: [e2e-test]

  - name: build-image
    container:
      image: gcr.io/kaniko-project/executor:latest
      args:
      - --context=.
      - --destination=my-registry/my-app:{{workflow.parameters.image-tag}}

  - name: run-lint
    container:
      image: golangci/golangci-lint:latest
      command: [golangci-lint, run, ./...]

  - name: run-unit-test
    container:
      image: golang:1.21
      command: [go, test, ./..., -v]

  - name: run-integration-test
    container:
      image: my-registry/test-runner:latest
      command: [./run-integration-tests.sh]

  - name: deploy
    container:
      image: bitnami/kubectl:latest
      command: [kubectl]
      args: [apply, -f, k8s/{{inputs.parameters.env}}/]

3.3 WorkflowTemplate 复用

apiVersion: argoproj.io/v1alpha1
kind: WorkflowTemplate
metadata:
  name: common-tasks
spec:
  templates:
  - name: notify-slack
    container:
      image: curlimages/curl:latest
      command: [curl]
      args:
      - -X POST
      - $(SLACK_WEBHOOK_URL)
      - -d
      - '{"text":"{{workflow.name}} completed"}'
      env:
      - name: SLACK_WEBHOOK_URL
        valueFrom:
          secretKeyRef:
            name: slack-webhook
            key: url

四、Workflows 与 CI/CD 集成

4.1 从 Webhook 触发

Argo Workflows 可通过 EventSource 接收 GitHub/GitLab 的 Webhook 事件，自动创建工作流实例：

apiVersion: argoproj.io/v1alpha1
kind: EventSource
metadata:
  name: github
spec:
  github:
    webhook:
      endpoint: /push
      port: 12000
      method: POST
    owner: my-org
    repositories:
    - name: my-app
      events: [push]

4.2 推荐的 CI/CD 流水线结构

┌─────────────┐     ┌──────────────┐     ┌──────────────┐
│  Code Push  │────▶│ Argo Workflow │────▶│ Build & Test │
└─────────────┘     └──────────────┘     └──────┬───────┘
                                                │
                                        ┌───────▼───────┐
                                        │  Update Git   │
                                        │  (image tag)  │
                                        └───────┬───────┘
                                                │
                                        ┌───────▼───────┐
                                        │ Argo CD Sync  │
                                        └───────┬───────┘
                                                │
                                        ┌───────▼───────┐
                                        │Argo Rollouts  │
                                        │ Canary Deploy │
                                        └───────────────┘

Argo CD + Rollouts + Workflows 组件版本兼容性

Argo Rollouts 常用命令

# 查看 Rollout 状态
kubectl argo rollouts get rollout my-app

# 手动推进金丝雀
kubectl argo rollouts promote my-app

# 手动回滚
kubectl argo rollouts undo my-app

# 查看 AnalysisRun 结果
kubectl get analysisrun -l rollouts-pod-template-hash=xxx -o yaml

# 重试失败的 Rollout
kubectl argo rollouts retry rollout my-app

# 查看流量分配
kubectl argo rollouts get ingress my-app

GitOps 与传统 CI/CD 对比

GitOps 工具选型建议

GitOps 安全检查清单

五、Argo CD + Rollouts + Workflows 全景

5.1 三者职责划分

5.2 完整部署流程

1. 开发者推送代码到 Git 仓库
2. Argo Workflows 触发 CI：构建镜像 → 单元测试 → 集成测试
3. Workflows 自动更新 Kustomize overlay 中的镜像 tag 并 commit 回 Git
4. Argo CD 检测到 Git 变更，同步到 Kubernetes
5. Argo Rollouts 执行 Canary 发布，逐步切流量
6. Analysis Template 查询 Prometheus 指标验证金丝雀健康
7. 验证通过 → 全量发布；验证失败 → 自动回滚

5.3 监控与可观测性

# 查看 Rollout 状态
kubectl argo rollouts get rollout my-app

# 查看 Workflow 执行
kubectl get workflows -n argo
kubectl logs -l workflows.argoproj.io/workflow=my-app -c main

# 查看 AnalysisRun 结果
kubectl get analysisrun -n default

常见错误

1. Rollout 卡在 Paused 状态不动——通常是 AnalysisRun 未通过或人工审批未执行 kubectl argo rollouts approve rollout my-app。用 kubectl argo rollouts get rollout my-app --analysis 查看 AnalysisRun 的具体失败原因。
2. Canary 切流量后 502/503——Check trafficRouting 配置中的 VirtualService / Ingress 路由是否指向了正确的 Service，确保 canaryService 和 stableService 的端口与 Pod 端口一致。
3. Workflows Pod 处于 Error 但无日志——常见于 initContainer 拉取私有镜像失败。确认 Secret docker-registry 已绑定 ServiceAccount，并检查 imagePullSecrets 配置。
4. EventSource 收不到 Webhook——检查 Argo Events 的 EventSource / Sensor 是否正常运行，确认 Ingress 暴露的端口与 EventSource 中 port 一致，且防火墙放行了 GitHub Webhook IP 段。
5. Argo CD 同步后 Rollout 未触发新发布——可能是因为镜像 tag 未变更（Argo CD 默认以 image 变更为触发点）。在 Rollout template 中使用唯一 tag 而非 latest。

最佳实践

1. 为 Canary 配置自动化 Analysis——至少监控成功率（HTTP 2xx 比例）和 P99 延迟两项指标，设定合理的 failureLimit（建议 1-2），让系统在指标异常时自动回滚而非人工介入。
2. Workflows 使用 WorkflowTemplate 复用——将通用步骤（构建镜像、Slack 通知、数据库迁移）抽象为 WorkflowTemplate，各流水线通过 templates[].arguments.parameters 注入差异参数，避免重复维护。
3. 渐进式发布先在 staging 验证——正式 production Canary 前，先对 staging 集群执行完整灰度流程，确认 Analysis 指标阈值合理后再推广到生产。
4. Git 仓库结构分离代码与部署配置——源码仓库放代码，独立的 GitOps 仓库放 Kubernetes manifest / Kustomize overlay，避免 CI 修改 manifest 与业务代码混在同一 commit 中。
5. 为所有组件配置 RBAC 最小权限——Argo Workflows 的 SA 只授予所需 Namespace 的 Deployment / ConfigMap 权限，Argo CD 的 RBAC 策略限制镜像来源仓库，避免过度授权。

故障排查案例：Canary 发布后 502 错误激增

现象：Argo Rollouts 执行 Canary 发布，流量切到 10% 后，Prometheus 监控显示 5xx 错误率从 0.1% 飙升到 15%，AnalysisRun 判定失败触发自动回滚。

排查：检查 Rollout 的 trafficRouting 配置，发现 canaryService 指向了一个不存在的 Service；查看 Istio VirtualService 路由规则，发现 canary 路由的 subset 名称与 Rollout 配置不匹配。

根因：Rollout 通过 trafficRouting 更新的 VirtualService 路由中 subset 名称与 Istio DestinationRule 中的 subset 定义不一致，导致流量被路由到后端不存在的实例。

修复：① 检查 Rollout 中 trafficRouting.istio.virtualServices 的 routes 配置是否与 VirtualService 的路由名称一致；② 确认 Istio DestinationRule 中定义了 canary 和 stable 两个 subset；③ 执行 kubectl argo rollouts status my-app 确认 Rollout 控制器状态正常。

# 排查 Rollout 状态
kubectl argo rollouts get rollout my-app --analysis
kubectl get virtualservice my-app-vsvc -o yaml
kubectl get destinationrule my-app-dr -o yaml

# 检查 Istio 路由规则
istioctl analyze
istioctl proxy-config routes deploy/my-app

Argo Workflows 常用调试命令

# 查看 Workflow 执行状态
kubectl get workflows -n argo -o wide

# 查看某个步骤的日志（按容器名过滤）
kubectl logs -l workflows.argoproj.io/workflow=build-test-deploy-xxxxx \
  -c build-image --tail=50

# 查看 WorkflowTemplate 定义
kubectl get workflowtemplate common-tasks -o yaml

# 手动重试失败的 Workflow
kubectl argo workflows retry build-test-deploy-xxxxx --restart-failed

# 查看 EventSource 和 Sensor 状态
kubectl get eventsources,sensors -n argo

练习题

1. 基于本文的 Canary 示例，编写一个 Rollout 与 AnalysisTemplate：金丝雀先切 10% 流量暂停 3 分钟，然后切 50% 暂停 5 分钟，Analysis 检查 Prometheus 中 http_request_duration_seconds 的 P99 延迟是否小于 200ms，超过 2 次失败自动回滚。写出完整 YAML 并说明各字段含义。
2. 设计一个 Argo Workflows DAG，包含以下步骤：① 从 Git 拉取代码 ② 并行执行 lint 和单元测试 ③ 构建 Docker 镜像（依赖 lint 和测试通过）④ 更新 GitOps 仓库中的 image tag（依赖构建完成）⑤ 通过 Slack 通知部署结果。画出 DAG 依赖图并写出 Workflow YAML。
3. 讨论 BlueGreen 与 Canary 两种策略的适用场景：如果你的服务需要零停机切换且能承受双倍资源开销，应该选哪种？如果 GPU 推理服务资源有限只能运行一组副本，又该选哪种？分析原因。

学习检查点

学完本章后，请检验自己是否掌握以下内容：

本章总结

Argo Rollouts 用 Canary / BlueGreen 策略将发布从"一键切换"升级为可观测、可回滚的渐进式交付，配合 AnalysisTemplate 在指标异常时自动中止灰度并回滚。Argo Workflows 以 DAG 编排构建、测试、部署等步骤，与 Argo CD、Rollouts 组合，形成 Git 驱动的完整自动化发布链路。

延伸阅读