Argo Rollouts 结合 Linkerd 实现金丝雀发布的流量管理实践-优快云博客

本文链接：https://blog.youkuaiyun.com/gitblog_00144/article/details/148755564

Argo Rollouts 结合 Linkerd 实现金丝雀发布的流量管理实践

argo-rollouts Progressive Delivery for Kubernetes 项目地址: https://gitcode.com/gh_mirrors/ar/argo-rollouts

概述

本文将通过一个具体示例，深入讲解如何使用 Argo Rollouts 项目结合 Linkerd 服务网格实现精细化的金丝雀发布流程。我们将分析一个完整的 Rollout 配置，展示如何通过 SMI (Service Mesh Interface) 规范控制流量分配，实现渐进式的应用部署。

核心组件解析

1. Rollout 资源定义

Rollout 是 Argo Rollouts 的核心资源，它扩展了 Kubernetes 原生 Deployment 的功能，提供了更丰富的部署策略：

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: rollout-linkerd
spec:
  replicas: 5
  strategy:
    canary:
      stableService: rollout-linkerd-stable
      canaryService: rollout-linkerd-canary
      trafficRouting:
        smi:
          rootService: rollout-linkerd
      steps:
      - setWeight: 5
      - pause: {}

关键配置说明：

replicas: 5：定义了应用运行的副本数
canary 策略：启用了金丝雀发布模式
trafficRouting.smi：使用 SMI 规范进行流量管理
steps：定义了发布流程步骤，先设置 5% 流量到新版本，然后暂停等待人工确认

2. Linkerd 集成

通过 Pod 注解 linkerd.io/inject: enabled 实现 Linkerd 自动注入：

template:
  metadata:
    annotations:
      linkerd.io/inject: enabled

这确保了所有 Pod 都会被自动注入 Linkerd sidecar 代理，获得服务网格能力。

3. 服务定义

配置中定义了三个关键服务：

根服务 (rollout-linkerd)：作为入口点，Linkerd 将通过它进行流量拆分
稳定版本服务 (rollout-linkerd-stable)：指向当前稳定版本的 Pod
金丝雀版本服务 (rollout-linkerd-canary)：指向新版本的 Pod

这种服务分离的设计使得流量管理更加清晰和可控。

金丝雀发布流程详解

初始阶段：控制器创建 Rollout 资源，部署 5 个 Pod 副本
更新触发：当 Rollout 的镜像版本变更时（如从 blue 改为 green），触发金丝雀流程
流量分配：
- 控制器创建 TrafficSplit 资源
- 95% 流量流向稳定版本
- 5% 流量流向金丝雀版本
暂停等待：流程在 5% 流量阶段暂停，等待人工确认
人工干预：运维人员通过命令手动继续发布流程

高级特性：自动化分析

示例中还包含了一个 AnalysisTemplate，可用于自动化测试：

metrics:
  - name: pass
    provider:
      job:
        spec:
          containers:
            - name: load-tester
              args:
                - wrk -t10 -c40 -d45s http://rollout-linkerd.{{ args.namespace }}.svc/color
                - jq -e '.errors_ratio <= 0.35 and .latency_avg_ms < 100'

这个负载测试会：