Kubernetes 渐进式交付：Argo Rollouts、金丝雀/蓝绿与流量治理实战

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  replicas: 10
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 2
      maxUnavailable: 1   # 每次最多下线 1 个旧副本

Deployment 的滚动更新能力：
  - 按 maxSurge/maxUnavailable 分批替换 Pod
  - 新版 Pod Ready 才算替换成功
  - 回滚改回旧镜像即可

但三大瓶颈：
  1. 没有"流量分阶段"：替换的是 Pod，但没有把"流量"按比例切到新版本
  2. 没有"验证阶段"：无法在新版拿小流量后观察指标再决定放量
  3. 回滚靠人工：没有"指标异常自动回滚"的机制
  → 这三点正是渐进式交付要补的

一个完整的渐进式发布周期：
  阶段一：发布新版（少量流量）
    - 蓝绿：切到独立的绿版本，权重可随时调整/回拨
    - 金丝雀：10% 流量先给新版
  阶段二：验证（指标观察）
    - 观察新版 POD 的错误率、延迟、CPU
    - 与基准 SLA 对比
  阶段三：决策
    - 指标健康 → 逐步放量（25% → 50% → 100%）
    - 指标异常 → 自动/手动回滚到旧版

Argo Rollouts 帮你把"放量 → 验证 → 决策"编排成声明式控制器。

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: api
spec:
  replicas: 10
  revisionHistoryLimit: 5
  selector:
    matchLabels: { app: api }
  template:
    metadata:
      labels: { app: api }
    spec:
      containers:
        - name: api
          image: registry/app:v2
  strategy:
    canary:
      steps:
        - setWeight: 10      # 先给新版 10% 流量
        - pause: { duration: 5m }          # 停 5 分钟观察
        - setWeight: 50
        - pause: { duration: 5m }
        - setWeight: 100
    # 或 blueGreen: 见下一节

Argo Rollouts 组成：
  - Rollout 控制器（replacement 部署 + 流量管理）
  - 支持多种流量提供方（Ingress Controller / Service Mesh）
  - 内建 Analysis（指标分析，自动代理）
  - 通过 CLI kubectl argo rollouts 可视化进度与 AB 对比

a. 先安装：kubectl create ns argo-rollouts
  kubectl apply -n argo-rollouts \
    -f https://github.com/argoproj/argo-rollouts/releases/latest/download/install.yaml
  # 视角
  kubectl argo rollouts -n ns get rollout api

strategy:
  blueGreen:
    activeService: api-active      # 承接流量的 Service
    previewService: api-preview    # 新版本预热
    autoPromotionEnabled: true
    scaleDownDelaySeconds: 30      # 切换后旧版保留多久（可回滚）

蓝绿语义：
  - 新版本先在"绿"整套部署好、Ready（previewService）
  - 验证 OK → 把 activeService 的 selector 切到新版本（切换流量）
  - 切错/出问题 → 立刻切回 activeService（秒级回滚）
  - 新旧两套同时存在 → 资源成本 2x（适合对停机/切换要求高场景）

注意：蓝绿调整的是"切流"而非"渐进"，切换是"瞬时"而非"平滑"。
  若想从 0% 平滑放到 100% 而不间断，适合金丝雀。

# 开始发布（自动切换到 activeService）
kubectl argo rollouts promote -n ns api
# 若 autoPromotionEnabled=false，手动切换/全量
kubectl argo rollouts promote api -n ns --full
# 回滚
kubectl argo rollouts undo api -n ns

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: api
spec:
  strategy:
    canary:
      canaryService: api-canary        # 新版 Service（如需要）
      stableService: api-stable        # 旧版 Service
      analysis:                        # 可选：自动放量的分析
        templates:
          - templateName: error-rate
      steps:
        - setWeight: 10
        - pause: { duration: 2m }
        - analysis: { templates: [ { templateName: error-rate } ] }
        - setWeight: 25
        - pause: { duration: 2m }
        - setWeight: 50
        - pause: {}                    # 无限暂停，人工批准后放量
        - setWeight: 100

金丝雀优点：
  - 渐进、平滑，从 10% → 25% → 50% → 100%
  - 任一步骤可中止/回滚，用户影响面可控
  - 结合 Analysis（下一节）：每步前自动验证指标

两种流量切分：
  - Ingress/Service Mesh 权重切分（推荐）
  - 副本比例（无网络切分时退而求其次）

# 观察重述当前进度与权重
kubectl argo rollouts get rollout api -n ns
# Status: Deployment Target ... | Canary Weight: 25%
# 推进到下一步（含人工批准步骤）
kubectl argo rollouts promote api -n ns
# 紧急回滚
kubectl argo rollouts abort api -n ns

方式一：Ingress Controller（如 Nginx/Traefik/ALB）
  在 Ingress/SVC 层按 weight 把请求分到 canary/stable Service

方式二：Service Mesh（Istio / Linkerd）
  用 VirtualService + weighted 路由精确切分
  更精细：还能按 header/cookie 做"会话粘性金丝雀"

没有网络切分歧施时：
  用副本比例近似（canary set s replicas 占 10% 副本 → 近似 10% 流量）
  但不精确（长连接/不均衡），适合兜底

# 安装 Rollouts 时指定 nginx ingress 提供方
# 部署一个带 canary 注解的 Ingress
# Argo Rollouts 自动按 weight 切换
spec:
  strategy:
    canary:
      trafficRouting:
        nginx:
          stableIngress: nginx-ingress-canary
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: api
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"

流量百分比正确性：
  - Ingress/Mesh 的权重切分要"可验证"
  - 建议：发布时监控 canary 副本的真实请求比例（服务端 metrics）
  - 用请求总数 / 请求标签确认权重确实生效（而非空转）

apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: error-rate
spec:
  metrics:
    - name: error-rate
      interval: 1m
      count: 5              # 取 5 个点（5 分钟）
      failureLimit: 2
      provider:
        prometheus:
          address: http://prometheus.monitoring:9090
          query: |
            sum(rate(http_requests_total{weight_route="canary", status=~"5.."}[1m]))
            /
            sum(rate(http_requests_total{weight_route="canary"}[1m]))
      failureCondition: "result >= 0.01"   # 错误率 >= 1% → 失败

Analysis 自动行为：
  - 每步 pause 期间对金丝雀指标跑 Analysis
  - 指标健康 → 继续放量
  - 指标异常 → 触发中止 / 自动回滚到 stable

关键配置：
  window/count：评估窗口与样本数
  failureThreshold：容忍的失败样本数（防抖动）
  failureCondition：失败阈值
  successCondition：成功阈值（可双设）

有了 Analysis，放量就不需要人工盯着——指标替你把关。

选对指标：
  - 看金丝雀的真实业务（错误率、延迟 p95、成功率）
  - 不要只盯 CPU/内存（业务误报少，但也漏慢）
使用 goldpilot（Argo 提供的预分析）：SLO/错误预算自动构建

回滚的灰色地带：
  - 要"足够快"：金丝雀样本太少连 noisy 时就暂停
  - 要"足够稳"：failureThreshold 设 2~3 次避免误杀

Argo Rollouts 清单应纳入 GitOps（ArgoCD/Flux）：
  - Rollout CR 版本化、可回滚、同 GitOps 同步
  - 版本回滚 = 回滚 Git 里的 manifest → 换用 Git 的 revision 概念
  - 渐进放量的 step 定义在 Git 里，审计清楚
注意：GitOps 与渐进发布的配合要点：
  - 把"放量进度"当状态而非"要 sync 的终态"
  - 用 Argo Rollouts + ArgoCD 的组合来做渐进发布的最佳实践

渐进式交付 vs Feature Flags（功能开关）：
  - 渐进式：按版本/层级（不同版本）放量
  - Feature Flag：按人/按用户群"瞬时"开合功能

配合：
  - 发布了新版本 → 用渐进式发布防患未然、随时可回滚
  - 业务功能逐步开放 → 用 Feature Flag 定向放
  - 想要"先小流量验证 + 再开放给认知" → 两者结合
  补充：Rollouts 与 ArgoCD 不同时刻、统一用 CR 声明

□ 明确用蓝绿还是金丝雀（高风险/高可用用金丝雀渐进）
□ 有指标可验证（error-rate / latency）可自动，否则 manual 审批
□ AnalysisTemplate 有充分 delay 避免误杀
□ 流量切分要可验证（监控各副本比例）
□ 版本在 GitOps 中管理，回滚 = Git 版本回退
□ 金丝雀步骤含人工 gate（重要变更还手动批准）
□ 设置放量超时/人工批准门禁，防卡死或失控
□ 新版本先在小流量跑至少 24h 再全量（逐步）

渐进是尺度、验证见血、回滚要当"一等公民"来设计。