K8S - 蓝绿发布实战 - Argo Rollouts 零停机方案解析

一、蓝绿发布原理

1.1 蓝绿发布：零停机部署的核心范式

蓝绿发布（Blue-Green Deployment）是一种通过双版本并行和原子化流量切换实现零停机更新的部署策略，其核心逻辑如下：

1.双环境共存

蓝色环境（Blue）：当前生产环境，承载全部用户流量，镜像版本为 v1。

绿色环境（Green）：新版本环境，镜像版本为 v2，部署后处于待验证状态。

2.流量切换

验证通过后，将流量从蓝色环境瞬时切换至绿色环境。

3.快速回退

若新版本异常，直接回切流量至蓝色环境，无需重建旧实例。

技术价值

零业务中断：避免滚动更新中请求被新旧版本混合处理的风险

版本强隔离：双环境完全独立，规避配置污染或依赖冲突

回滚效率高：秒级切换，无需重新构建或拉取镜像

1.2 蓝绿发布与 K8S 原生方案的差异

二、Argo Rollouts 简介

Argo Rollouts 是 Kubernetes 的自定义控制器，它扩展了原生 Deployment 的能力，专注于增强部署流程的可控性与可观测性。

2.1 核心能力

• 多策略支持：内建蓝绿发布、金丝雀发布、A/B 测试等多种发布模式，适配不同上线需求。

• 自动化决策：可接入 Prometheus 等监控系统，基于指标自动推进或回滚，提升部署可靠性。

• 可视化监控：配套提供 Dashboard，可实时查看发布进度、版本状态与流量分配，降低操作复杂度。

• CLI 插件支持：通过 kubectl argo rollouts插件，快速执行版本切换、暂停发布、强制回滚等关键操作，提升命令行执行效率。

补充：Argo Rollouts Dashboard 是Argo Rollouts 配套的可视化界面，支持展示 Rollout 状态、历史版本、流量分布等信息，常与 Prometheus 和分析工具联动使用。

2.2 架构解析

graph TD
  A[Rollout CRD] --> B[控制器]
  B -->|创建/扩缩容| C[ReplicaSet]
  C -->|生成 Pod| D[Pod]
  B -->|更新 Selector| E[Service]
  E -->|流量路由| C
  E -->|流量路由| F[新 ReplicaSet]
  B -->|拉取指标| G[Prometheus]

说明：

• Rollout CRD：定义部署策略、版本历史、健康检查规则

• 控制器：协调 ReplicaSet 生命周期，管理流量切换

• ReplicaSet：每个版本对应独立副本集，通过 pod-template-hash标识

• Service：流量入口，通过 Selector 的原子更新实现版本切换

三、基于Argo Rollouts 蓝绿发布实战

场景：对 argoproj/rollouts-demo:green 镜像 进行蓝绿发布。
3.1 环境准备
1.安装k8s基础环境（Mac/Linux ）

# 安装 Docker 并启动服务
brew install --cask docker
open /Applications/Docker.app

# 安装 kubectl 命令行工具
brew install kubectl

# 安装 Kind（本地K8S集群工具）
brew install kind

# 验证安装
docker --version          # 预期输出: Docker version 24.x+
kubectl version --client  # 预期输出: Client Version: v1.28.x
kind version              # 预期输出: kind v0.20.x

2.创建本地 Kubernetes 集群

使用自定义kind-config.yaml 创建集群

# 创建集群（命名为 k8s-lab）
kind create cluster --name k8s-lab --config kind-config.yaml

# 验证集群状态
kubectl cluster-info
# 预期输出：Kubernetes control plane is running at https://127.0.0.1:xxxxx

在项目根目录下创建如下 kind-config.yaml 。

kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
nodes:
- role: control-plane
  kubeadmConfigPatches:
  - |
    kind: InitConfiguration
    nodeRegistration:
      kubeletExtraArgs:
        node-labels: "ingress-ready=true"  
  extraPortMappings:    
  - containerPort: 80
    hostPort: 80
    protocol: TCP
  - containerPort: 443
    hostPort: 443
    protocol: TCP

3.安装 Argo Rollouts

(1) 部署 Argo Rollouts 控制器（含 Dashboard）：

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

(2) 等待组件就绪：

kubectl wait --for=condition=Ready pods --all -n argo-rollouts --timeout=300s

(3) 安装 Argo Rollouts CLI 插件：

# macOS（Homebrew）
brew install argoproj/tap/kubectl-argo-rollouts

# Linux 用户
curl -LO https://github.com/argoproj/argo-rollouts/releases/latest/download/kubectl-argo-rollouts-linux-amd64
chmod +x kubectl-argo-rollouts-linux-amd64
sudo mv kubectl-argo-rollouts-linux-amd64 /usr/local/bin/kubectl-argo-rollouts

(4) 启动 Dashboard（推荐）：

kubectl argo rollouts dashboard
或手动方式访问 Dashboard：

kubectl -n argo-rollouts port-forward deployment/argo-rollouts-dashboard 3100:3100
# 访问地址：http://localhost:3100

4.安装 Ingress（蓝绿发布流量切换依赖）

# 安装适用于Kind的Ingress-Nginx控制器
kubectl apply -f https://raw.githubusercontent.com/kubernetes/ingress-nginx/main/deploy/static/provider/kind/deploy.yaml

# 等待Ingress控制器就绪
kubectl wait --namespace ingress-nginx \
  --for=condition=ready pod \
  --selector=app.kubernetes.io/component=controller \
  --timeout=90s

# 验证Ingress控制器Pod是否正常运行
kubectl get pods -n ingress-nginx

# 检查Ingress控制器服务是否正常
kubectl get svc -n ingress-nginx

3.2 项目结构
项目文件结构如下：

bluegreen-rollout/
├── blue-green-rollout.yaml     # Rollout 配置
├── blue-green-service.yaml     # Service 定义
├── blue-green-ingress.yaml     # Ingress 配置
└── kind-config.yaml            # Kind 集群配置

文件解析

1.blue-green-rollout.yaml
作用：定义蓝绿发布策略、Pod 模板、镜像版本及自动切换规则。

2.blue-green-service.yaml
作用：定义 Kubernetes Service，通过动态选择器（selector）关联 Rollout 的 Pod。

3.blue-green-ingress.yaml
作用：定义外部访问入口，将流量路由到 Service。

3.3 配置文件

(1) Rollout 配置

blue-green-rollout.yaml
apiVersion: argoproj.io/v1alpha1  # Argo Rollouts 的 API 版本
kind: Rollout                     # 使用 Rollout 资源类型替代传统的 Deployment，用于实现高级发布策略（如蓝绿、金丝雀）
metadata:
  name: bluegreen-demo           # Rollout 的名称
  labels:
    app: bluegreen-demo
spec:
  replicas: 3                    # 副本数量，与 Deployment 相同，控制 Pod 数量
  revisionHistoryLimit: 1       # 保留的历史版本数，用于回滚
  selector:                     # 标签选择器，选择需要管理的 Pod
    matchLabels:
      app: bluegreen-demo
  template:                     # Pod 模板定义，与 Deployment 的模板结构一致
    metadata:
      labels:
        app: bluegreen-demo
    spec:
      containers:
        - name: bluegreen-demo
          image: argoproj/rollouts-demo:blue  # 初始镜像为 blue（用于演示蓝绿部署）
          imagePullPolicy: Always
          ports:
            - name: http
              containerPort: 8080
  strategy:                      # 定义发布策略，这里使用的是蓝绿部署（blueGreen）
    blueGreen:
      autoPromotionEnabled: true         # 自动将新版本标记为 active
      activeService: bluegreen-demo      # 指定代表“生产流量入口”的 Service 名称

配置说明：

• kind: Rollout：Rollout 是 Argo Rollouts 提供的替代 Deployment 的自定义资源。

• blueGreen策略：创建新版本 Pod 后，验证通过即可切换生产流量。

• autoPromotionEnabled: true：启用自动切换，无需手动执行 promote。

• activeService：指定接收流量的 Service，Rollout 会根据其 selector 自动切换版本。

(2) Service 配置

blue-green-service.yaml

apiVersion: v1
kind: Service
metadata:
  name: bluegreen-demo
spec:
  selector:
    app: bluegreen-demo
  ports:
    - port: 80
      targetPort: http
      name: http

(3) Ingress 配置

blue-green-ingress.yaml

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: bluegreen-demo
spec:
  rules:
    - host: bluegreen.auto
      http:
        paths:
          - path: /
            pathType: Prefix
            backend:
              service:
                name: bluegreen-demo
                port:
                  number: 80

3.4 部署与验证

步骤1：应用配置

kubectl apply -f blue-green-rollout.yaml  
kubectl apply -f blue-green-service.yaml  
kubectl apply -f blue-green-ingress.yaml

步骤2：访问网页

配置本地 hosts 文件：
127.0.0.1 bluegreen.auto
浏览器访问：

http://bluegreen.auto
初始页面为蓝色版本。类似如下

步骤3： 触发蓝绿发布

修改 blue-green-rollout.yaml文件中的镜像为 green。

spec:
  template:
    spec:
      containers:
      - name: bluegreen-demo
        image: argoproj/rollouts-demo:green  # 修改此处

重新应用配置：

kubectl apply -f blue-green-rollout.yaml

观察 Argo Rollouts 状态：

kubectl argo rollouts get rollout bluegreen-demo --watch

输出显示流量自动切换到绿色版本：

Name:            bluegreen-demo
Namespace:       default
Status:          ✔ Healthy
Strategy:        BlueGreen
Images:          argoproj/rollouts-demo:green (active)
                 argoproj/rollouts-demo:blue

步骤4：验证绿色流量版本

刷新浏览器 http://bluegreen.auto ，页面应为绿色版本，如下截图。

步骤5：Argo Rollouts Dashboard 监控

启动 Dashboard：(如未启动）

kubectl argo rollouts dashboard

浏览器 访问 Dashboard：

http://localhost:3100/rollouts
在页面中选择 Rollout 示例 bluegreen-demo，可查看以下信息：

Active Revision：当前活跃版本（绿色版本）

ReplicaSets：新旧版本的副本状态及数量

可直观观察版本切换状态与副本变更过程

步骤6：回滚验证

手动回滚到蓝色版本

kubectl argo rollouts undo bluegreen-demo

刷新浏览器：页面应恢复为蓝色背景。

3.5 扩展：多环境配置

若需支持多环境（如开发、生产），可使用 Kustomize 管理：

blue-green-demo/
├── base/                     # 基础配置
│   ├── rollout.yaml
│   ├── service.yaml
│   ├── ingress.yaml
│   └── kustomization.yaml    # 聚合资源
└── overlays/
    ├── dev/                  # 开发环境
    │   ├── kustomization.yaml
    │   └── replica-patch.yaml  # 调整副本数等
    └── prod/                 # 生产环境
        ├── kustomization.yaml
        └── resource-patch.yaml  # 调整资源限制

四、Argo Rollouts 原理解析

4.1 流量切换原理详解

核心机制：Argo Rollouts 通过动态修改 Service 的标签选择器（Label Selector）实现流量切换，同时管理多个 ReplicaSet 的生命周期。

以下是对蓝绿发布分步解析：

1.初始状态（蓝色环境）

Rollout 对象：定义镜像为 argoproj/rollouts-demo:blue。

ReplicaSet（蓝色）：控制器创建名为 bluegreen-demo-abc123的 ReplicaSet，其 Pod 携带标签：

labels:
  app: bluegreen-demo
  rollouts-pod-template-hash: abc123  # 唯一哈希标签
Service：selector 指向蓝色 Pod 的哈希标签：

selector:
  app: bluegreen-demo
  rollouts-pod-template-hash: abc123

流量链路：Ingress → Service → 蓝色 ReplicaSet → 蓝色 Pod

2.触发更新（修改镜像为 green）

新 ReplicaSet（绿色）：控制器创建 bluegreen-demo-def456ReplicaSet，Pod 标签为：

labels:
  app: bluegreen-demo
  rollouts-pod-template-hash: def456  # 新哈希标签

Pod 状态：

蓝色 Pod：继续接收流量。

绿色 Pod：启动但不接收流量（等待就绪）。

3.流量切换（绿色就绪后）

Service 更新：控制器修改 Service 的 selector：

selector:
  app: bluegreen-demo
  rollouts-pod-template-hash: def456  # 指向绿色哈希

ReplicaSet 调整：

蓝色 ReplicaSet：缩容至 0 副本（保留历史版本）。

绿色 ReplicaSet：扩容至 3 副本。

流量链路：Ingress → Service → 绿色 ReplicaSet → 绿色 Pod

4.回滚机制（秒级恢复）

回滚命令：执行 kubectl argo rollouts undo。

Service 回退：控制器将 selector 切回旧哈希标签（如 abc123）。

ReplicaSet 调整：

蓝色 ReplicaSet：扩容至 3 副本。

绿色 ReplicaSet：缩容至 0 副本。

4.2 动态流量切换示意图

 participant Ingress
  participant Service
  participant Blue_RS as 蓝色 ReplicaSet
  participant Green_RS as 绿色 ReplicaSet
  participant Blue_Pod as 蓝色 Pod
  participant Green_Pod as 绿色 Pod

    Note over Ingress,Green_Pod: 初始状态（蓝色版本）
  Ingress->>Service: 请求流量
  Service->>Blue_RS: 路由到蓝色 ReplicaSet
  Blue_RS->>Blue_Pod: 分发到蓝色 Pod

    Note over Ingress,Green_Pod: 触发更新（镜像改为 green）
  Green_RS->>Green_Pod: 创建绿色 Pod（未就绪）
  Green_Pod-->>Green_RS: Pod 就绪
  Green_RS-->>Service: 通知控制器

    Note over Ingress,Green_Pod: 流量切换（绿色就绪）
  Service->>Green_RS: 更新 selector 至绿色哈希
  Ingress->>Service: 新请求流量
  Service->>Green_RS: 路由到绿色 ReplicaSet
  Green_RS->>Green_Pod: 分发到绿色 Pod
  Blue_RS->>Blue_Pod: 缩容至 0 副本（保留）

关键交互解析

1.版本共存

新旧 ReplicaSet 同时存在：旧版本仅被缩容并保留，用于随时回滚；新版本完成就绪后接管全部流量。

2.原子化切换

流量切换通过更新 Service 的 Selector 完成，该操作为原子级别，确保切换瞬时生效、不中断。

3.快速回滚机制

如需回滚，只需将 Service 的 Selector 切回旧标签，Kubernetes 会自动扩容旧 ReplicaSet，实现秒级恢复。

4.4 与原生 Deployment 的深度对比

4.5 设计哲学与最佳实践

1.版本标签管理

唯一哈希标签：Argo Rollouts 会自动为每个版本的 Pod 添加 rollouts-pod-template-hash标签，确保 Service 的选择器精准指向目标 Pod。

自定义标签扩展：可附加业务标签（如 env: prod），实现多维度流量路由策略。

2.资源保留策略

revisionHistoryLimit：用于控制保留的旧 ReplicaSet 数量（默认 10），在资源占用和版本回滚之间取得平衡。

缩容而非删除：旧版本 ReplicaSet 不直接删除，而是将副本数缩容为 0，保留元数据以支持秒级回滚。

3.零信任流量切换

就绪检查（Readiness Probe）：新版本 Pod 需完全就绪，才允许切换流量，保障稳定性。

预发布验证：借助 previewService提供独立访问入口，可支持人工或自动化验收新版本。

4.6 适用场景与局限性

适用场景

关键业务系统：如金融交易、电商大促等对稳定性和可控性要求极高的场景。

大规模微服务：适合需要秒级回滚和多版本并存的复杂架构。

合规性要求：便于保留完整历史版本，满足审计需求。

局限性

资源开销：更新期间双版本共存，会占用更多计算资源。

切流粒度限制：要么全部切流，要么完全不切，无法支持部分用户或请求的局部验证。

五、总结

5.1 核心重点
在蓝绿发布过程中，Argo Rollouts 提供了一系列增强能力：

原子化流量切换

通过 Service Selector 的瞬时更新实现零业务中断，规避滚动更新的混合流量风险。

版本保留与秒级回滚

旧 ReplicaSet 缩容至 0 副本但保留元数据，回滚无需重建 Pod。

自动化验证闭环

集成健康检查与 Prometheus 指标分析，实现“部署-验证-决策”全流程自动化。