DevOps全链路实战 | 第 15 天：金丝雀发布实战：setWeight 流量分割与 pause 步骤

第 15/19 天。在上一篇中我们完成了 Argo Rollouts 的安装与 CRD 概念解析，理解了 Rollout 资源如何替代原生 Deployment 实现金丝雀、蓝绿等高级发布策略。今天我们进入实战环节——动手配置一套完整的金丝雀发布流水线，重点掌握 setWeight 流量分割与 pause 暂停步骤的编排技巧，让每一次版本升级都能在真实流量验证下安全推进。

一、为什么需要金丝雀发布

传统的 kubectl rollout 依赖 Kubernetes 原生 Deployment 的 RollingUpdate 策略，新 Pod 就绪后立即接管全部流量，一旦新版本存在缺陷，故障会在瞬间扩散到整个服务。金丝雀发布（Canary Release）的核心思想是：先将一小部分真实流量导向新版本，观察指标表现与用户反馈，确认无异常后再逐步放大流量比例，最终完成全量切换。任何阶段发现问题都可立即回滚，将影响范围控制在最小。

Argo Rollouts 在 Kubernetes 之上实现了这一能力，其优势在于：

与 Service、Ingress、ServiceMesh 深度集成，支持基于权重的精确流量分割
内置 setWeight、pause、analysis 等步骤原语，发布过程完全声明式可审计
可对接 Prometheus 等指标系统，实现指标驱动的自动推进与回滚（明天详解）

二、实验环境准备

2.1 确认 Argo Rollouts 已安装

💻 代码示例

# 检查 Rollouts 控制器运行状态

kubectl get pods -n argo-rollouts -l app.kubernetes.io/name=argo-rollouts

# 确认 CRD 已注册

kubectl get crd | grep argoproj.io

# 预期输出：

# rollouts.argoproj.io

# analysisruns.argoproj.io

# experiments.argoproj.io

2.2 安装 kubectl 插件

💻 代码示例

# 下载 argo-rollouts kubectl 插件

curl -sLO https://github.com/argoproj/argo-rollouts/releases/latest/download/kubectl-argo-rollouts-linux-amd64

chmod +x kubectl-argo-rollouts-linux-amd64

mv kubectl-argo-rollouts-linux-amd64 /usr/local/bin/kubectl-argo-rollouts

# 验证安装

kubectl argo rollouts version

插件安装后，我们就可以用 kubectl argo rollouts 子命令实时观察发布进度、手动推进或中止金丝雀。

三、金丝雀 Rollout 资源编写

下面是一个完整的 Rollout 资源定义，包含四个关键步骤：先切 20% 流量到新版本并暂停观察，再放大到 50% 暂停，然后 80% 暂停，最后全量切换。

💻 代码示例

apiVersion: argoproj.io/v1alpha1

kind: Rollout

metadata:

namespace: production

spec:

replicas: 5

selector:

matchLabels:

app: canary-demo

template:

metadata:

labels:

app: canary-demo

spec:

containers:

– name: webapp

image: registry.stellardata.top/devops/webapp:v2.0.0

ports:

– name: http

containerPort: 8080

resources:

requests:

cpu: 100m

memory: 128Mi

limits:

cpu: 200m

memory: 256Mi

strategy:

canary:

canaryService: canary-demo-canary # 金丝雀 Service

stableService: canary-demo-stable # 稳定 Service

trafficRouting:

nginx:

stableIngress: canary-demo-ingress # 主 Ingress 名称

steps:

– setWeight: 20

– pause: { duration: 2m } # 暂停 2 分钟观察

– setWeight: 50

– pause: { duration: 3m }

– setWeight: 80

– pause: { duration: 3m }

– setWeight: 100

这里有几个核心字段需要重点理解：

canaryService / stableService：Argo Rollouts 会自动维护两个 Service，分别指向稳定版本和金丝雀版本的 Pod。上层 Ingress/网格通过这两个 Service 做流量权重切分。
trafficRouting：声明流量切分的实现方式。这里使用 nginx Ingress Controller，也可替换为 Istio、SMI、Ambassador 等。
steps：发布步骤序列，setWeight 设置金丝雀流量百分比，pause 控制每个阶段停留时间。duration 设为 0s 或省略时表示无限期暂停，需要人工 promote 才能继续。

四、配套 Service 与 Ingress

金丝雀流量切分依赖 stable/canary 两个 Service 和一个稳定 Ingress，Argo Rollouts 会在发布过程中动态更新它们的后端 Pod 选择器与权重注解。

💻 代码示例

apiVersion: v1

kind: Service

metadata:

namespace: production

spec:

selector:

app: canary-demo

ports:

– port: 80

targetPort: http

—

apiVersion: v1

kind: Service

metadata:

namespace: production

spec:

selector:

app: canary-demo

ports:

– port: 80

targetPort: http

—

apiVersion: networking.k8s.io/v1

kind: Ingress

metadata:

namespace: production

annotations:

kubernetes.io/ingress.class: nginx

spec:

rules:

– host: webapp.stellardata.top

http:

paths:

– path: /

pathType: Prefix

backend:

service:

port:

number: 80

注意 Ingress 只需指向 stableService，Argo Rollouts 在发布期间会自动注入 nginx.ingress.kubernetes.io/canary 等注解实现按权重切流。

五、发起金丝雀发布

5.1 部署初始稳定版本

💻 代码示例

# 先用 v1 镜像创建初始 Rollout（首次部署即稳定版）

kubectl argo rollouts set image canary-demo

webapp=registry.stellardata.top/devops/webapp:v1.0.0

-n production

# 等待 Rollout 达到 Healthy 状态

kubectl argo rollouts get rollout canary-demo -n production –watch

5.2 触发版本升级

💻 代码示例

# 将镜像升级到 v2，触发金丝雀流程

kubectl argo rollouts set image canary-demo

webapp=registry.stellardata.top/devops/webapp:v2.0.0

-n production

5.3 实时观察发布进度

💻 代码示例

# 实时查看金丝雀发布状态（图形化进度条）

kubectl argo rollouts get rollout canary-demo -n production –watch

# 查看 Pod 级别状态

kubectl get pods -n production -l app=canary-demo -L pod-template-hash

输出中会清晰展示当前所处步骤、流量权重、已用时长等信息。当进入 pause 步骤时，状态显示为 Paused，等待 duration 到期后自动推进。

5.4 手动控制发布

💻 代码示例

# 在 pause 步骤中手动立即推进到下一步

kubectl argo rollouts promote canary-demo -n production

# 发现问题，立即全量回滚到稳定版本

kubectl argo rollouts abort canary-demo -n production

# 回到上一版本镜像

kubectl argo rollouts undo canary-demo -n production

promote 在人工审核场景下非常实用——将 pause 的 duration 设为空表示无限等待，运维人员确认监控指标正常后手动执行 promote 推进。

六、pause 步骤的两种模式

💻 代码示例

strategy:

canary:

steps:

– setWeight: 10

– pause: {} # 无限期暂停，需人工 promote

– setWeight: 30

– pause: { duration: 5m } # 定时 5 分钟后自动推进

– setWeight: 100

无限期 pause：pause: {}，适用于核心生产服务，需人工确认后推进，最大程度保障安全。
定时 pause：pause: { duration: 5m }，适用于常规迭代发布，自动推进提高效率。duration 支持 s（秒）、m（分钟）、h（小时）单位。

两种模式可混合使用：关键阶段用无限期 pause，中间过渡阶段用定时 pause。

七、流量切分原理与 Nginx 注解

当使用 nginx Ingress 做 trafficRouting 时，Argo Rollouts 会动态创建一个 canary Ingress 并注入以下注解实现权重切分：

💻 代码示例

{

"annotations": {

"kubernetes.io/ingress.class": "nginx",

"nginx.ingress.kubernetes.io/canary": "true",

"nginx.ingress.kubernetes.io/canary-weight": "20"

}

canary-weight 的值随 setWeight 步骤动态更新。Nginx Ingress Controller 读取该注解后，按比例将请求路由到 canary Service 后的 Pod。整个过程对上层调用方完全透明，无需修改应用代码。

八、常见问题与排查

Q1：发布卡在 Pause 不推进

💻 代码示例

# 查看当前步骤详情

kubectl argo rollouts get rollout canary-demo -n production

# 查看控制器日志

kubectl logs -n argo-rollouts -l app.kubernetes.io/name=argo-rollouts –tail=50

常见原因：pause 未设 duration 导致等待人工 promote；或 Rollout 控制器未正确识别 trafficRouting 配置。

Q2：流量权重不生效

确认 Nginx Ingress Controller 版本 ≥ 0.20（支持 canary 注解），并检查 stable/canary Service 的 Endpoints 是否就绪：

💻 代码示例

kubectl get endpoints canary-demo-stable canary-demo-canary -n production

Q3：回滚后 Pod 未清理

Argo Rollouts 默认保留最近若干历史版本的 ReplicaSet 用于快速回滚。如需手动清理：

💻 代码示例

kubectl delete replicaset -l app=canary-demo

-n production –field-selector=status.replicas=0

九、总结

今天我们完成了金丝雀发布的完整实战：编写 Rollout 资源定义、配置 stable/canary 双 Service 与 Ingress、通过 setWeight 按比例切分流量、用 pause 步骤在关键节点暂停观察，并掌握了 promote/abort/undo 等手动控制命令。这套机制让版本升级从”一刀切”变成”逐步放量、随时可退”的安全流程，是生产环境高可用发布的基础设施。

但目前的 pause 仍依赖人工判断，理想状态应该让系统根据指标自动决定推进还是回滚。明天的 AnalysisTemplate 就是解决这个问题的利器。