企业官网建设流程全解析

• 文档
• 教程
• DevOps
• 运维

导读

本文基于 devops-exercises 仓库中的 Canary Rollout 练习与解答，完整演示如何在 Kubernetes 集群中安装 Argo Rollouts 控制器，编写一份采用 canary（金丝雀）策略的 Rollout 清单，并通过逐步放量（30% → 60% → 100%）与手动暂停确认的方式发布新版本。读完本文，你将掌握 canary 发布的核心概念、Rollout 资源的关键字段语义、以及配套的kubectl argo rollouts命令族，能够独立完成"低风险灰度发布 + 人工把关"的实战场景。

背景：为什么需要 Argo Rollouts

Kubernetes 原生Deployment提供的滚动更新在发布新版本时缺乏细粒度的流量控制能力。Argo Rollouts 是运行在 Kubernetes 之上、专门用于高级发布策略的控制器。按本仓库 Argo Rollouts 101 问答 的定义：

Argo Rollouts 是 Kubernetes 的一个控制器，用于使用 Blue/Green、Canary 等不同策略执行应用部署，此外还支持 A/B 测试、自动回滚与集成的指标分析。

它引入了一个新的自定义资源Rollout（argoproj.io/v1alpha1），用来替代或补充Deployment的发布流程。需要注意的是，Argo Rollouts 与 ArgoCD 是相互独立的组件——仓库中明确指出这是一个常见的误解：使用 Argo Rollouts 并不需要先安装 ArgoCD，两者可以独立使用，也可以协同工作（详见 README 问答）。

本练习（exercise.md）的目标是：

1. 安装 Argo Rollouts 控制器；
2. 编写一份使用 canary 策略的 Rollout 清单并应用，副本数设为 6，并禁用自动提升（auto-promotion）；
3. 查看 rollout 列表；
4. 发布一个新版本并检查发布状态。

前置条件（Requirements）

根据原文档，动手前需要准备：

1. 一个正在运行的 Kubernetes 集群（可以是 kind、minikube、云厂商托管集群等）；
2. Argo Rollouts CLI 插件（提供kubectl argo rollouts子命令，用于查看与操控 rollout）；
3. 一个已经部署在集群中的、特定版本的应用（本文示例为some/registry/and/image:v1.0）。

第一步：安装 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 create namespace argo-rollouts：为控制器创建专用命名空间，便于资源隔离与清理；
• kubectl apply -n argo-rollouts -f .../install.yaml：从 Argo Rollouts 官方 GitHub Releases 拉取最新的安装清单（包含 Controller Deployment、RBAC、CRD 定义等）并应用到argo-rollouts命名空间。

安装完成后，控制器会监听集群中Rollout类型的自定义资源，并负责驱动 canary/blue-green 发布流程的执行。

第二步：编写 Canary Rollout 清单

以下是原文档提供的完整 Rollout 资源清单。它定义了一个名为some-app的应用，初始镜像为some/registry/and/image:v1.0：

--- apiVersion: argoproj.io/v1alpha1 kind: Rollout metadata: name: some-app spec: replicas: 6 strategy: canary: stableService: k8s-service-stable canaryService: k8s-service-canary trafficRouting: ambassador: mappings: - k8s-mapping steps: - setWeight: 30 - pause: {} - setWeight: 60 - pause: {} - setWeight: 100 - pause: {} selector: matchLabels: app: some-web-app template: metadata: labels: app: some-web-app spec: containers: - name: web-app image: some/registry/and/image:v1.0 ports: - name: http containerPort: 8080 protocol: TCP

逐字段解读

API 版本与类型

• apiVersion: argoproj.io/v1alpha1、kind: Rollout：这是 Argo Rollouts 注册的自定义资源类型，区别于原生apps/v1的Deployment。

副本数与发布策略

• spec.replicas: 6：目标副本数为 6（与练习目标一致）。canary 发布过程中，新旧版本 ReplicaSet 的 Pod 数量分配由控制器根据setWeight自动计算。
• spec.strategy.canary：声明采用 canary 策略。canary 与 blue/green 是 Argo Rollouts 的两大内置策略，仓库中另有一份 Blue/Green Rollout 解答 可对照学习：blue/green 通过autoPromotionEnabled: false控制是否自动切换，而 canary 则是通过流量权重阶梯逐步放量。

Service 与流量路由

• stableService: k8s-service-stable：稳定版本对应的 Service，持续接收部分流量。
• canaryService: k8s-service-canary：金丝雀（新版本）对应的 Service。
• trafficRouting.ambassador.mappings: [k8s-mapping]：指定由 Ambassador/Emissary 作为流量路由网关，通过名为k8s-mapping的 Mapping 资源按权重切分稳定/金丝雀流量。这是 canary 精准控流的关键：没有 trafficRouting 时只能控制副本比例，配置网关后才能真正按百分比切分线上流量。

Steps：发布阶梯

steps: - setWeight: 30 - pause: {} - setWeight: 60 - pause: {} - setWeight: 100 - pause: {}

这 6 步定义了一次完整 canary 发布的节奏：

1. setWeight: 30—— 将 30% 流量切到新版本；
2. pause: {}—— 暂停，等待人工确认；
3. setWeight: 60—— 放量到 60%；
4. pause: {}—— 再次暂停；
5. setWeight: 100—— 全量切换；
6. pause: {}—— 最终暂停，等待完成。

pause: {}正是原文档目标中"禁用自动提升（Disable auto-promotions）"的实现方式：每一步放量后发布流程都会停在暂停点，只有人工执行提升命令后才会进入下一步。这与 blue/green 解答中autoPromotionEnabled: false的意图一致——把关键决策权交给工程师。

Selector 与 Pod 模板

• selector.matchLabels: {app: some-web-app}与template.metadata.labels: {app: some-web-app}：Pod 标签必须与选择器匹配，Argo Rollouts 据此关联新旧 ReplicaSet。
• template.spec.containers：容器名为web-app，镜像some/registry/and/image:v1.0，暴露名为http、端口 8080 的 TCP 端口。后续更新镜像时，命令中的容器名web-app必须与这里保持一致。

第三步：查看 Rollout 列表

应用清单后，使用以下命令确认 Rollout 已被控制器接管：

kubectl argo rollouts list rollouts

该命令会列出集群中所有 Rollout 及其当前状态（Healthy、Progressing 等）。对应地，README 的命令问答 也给出了列出 rollouts 的标准用法。若要查看单个应用的状态，可用：

kubectl argo rollouts get rollout some-app

第四步：发布新版本并监控状态

触发新版本发布

kubectl argo rollouts set image SOME-APP web-app=some/registry/and/image:v2.0

这条命令将some-app的web-app容器镜像从v1.0更新为v2.0，等价于修改清单中的image字段后重新 apply，是触发 canary 流程的标准方式。

观察发布过程

kubectl argo rollouts get rollout some-app --watch

--watch会持续刷新输出，实时显示当前所处的 step、新旧版本 Pod 数量与流量权重变化。按照本仓库 README 的说明，当你对应用执行 rollout 时会发生两件事：

• Argo Rollouts 创建一个新的 ReplicaSet（承载新版本），旧版本仍然存活——这正是 canary 能够随时回退的基础；
• 若与 ArgoCD 集成，应用会被标记为 out-of-sync，等待同步确认。

推进与回退的关键操作

由于清单中每个 step 后都有pause，发布会停在暂停点，你需要手动推进：

kubectl argo rollouts promote SOME-APP

promote用于跳过当前暂停，进入下一个 step（如从 30% 提升到 60%）。这也印证了仓库 Argo Rollouts Commands 问答 中的结论：手动提升新版本正是通过该命令完成的。若在某一暂停点发现新版本异常，可以执行kubectl argo rollouts abort some-app（或使用undo回退）终止发布、让流量回到稳定版本。

纵深扩展：从手动确认到自动回滚

本练习采用的是"暂停 + 人工确认"模式。仓库的问答章节进一步指出，更成熟的方案是把人工把关升级为基于指标的自动化分析——Argo Rollouts 支持 Datadog、NewRelic、Prometheus 等多种指标提供方，可在发布过程中持续采集指标并在条件不满足时自动回滚（详见 README 问答）。

仓库给出的 AnalysisTemplate 示例 展示了这种自动化思路的核心结构：

apiVersion: argoproj.io/v1alpha1 kind: AnalysisTemplate metadata: name: success-rate spec: args: - name: service-name metrics: - name: success-rate interval: 4m count: 3 successCondition: result[0] >= 0.90 provider: prometheus: address: http:/some-prometheus-instance:80 query: sum(response_status{app="{{args.service-name}}",role="canary",status=~"2.*"})/sum(response_status{app="{{args.service-name}}",role="canary"}

该模板每 4 分钟从 Prometheus 查询一次金丝雀版本的成功率：如果result[0] >= 0.90（90% 以上请求成功），发布继续；否则判定金丝雀失败并触发回滚。在实际项目中，可将这份 AnalysisTemplate 关联到 Rollout 的strategy.canary.analysis字段，从而把"何时放量、何时回滚"交给数据而非人工判断。

总结与进一步练习

本文从零完成了"安装控制器 → 编写 canary Rollout → 查看列表 → 升级镜像并监控 → 手动推进"的完整闭环，重点掌握：

• canary 策略通过setWeight+pause实现"阶梯放量 + 人工把关"，pause即禁用自动提升；
• stableService/canaryService/trafficRouting共同决定稳定版与金丝雀版之间的流量切分；
• kubectl argo rollouts命令族（list、get --watch、set image、promote）是日常操控发布的核心工具。

如果你希望对比另一种发布策略，可以继续完成仓库中的 Blue/Green Rollout 练习 并对照其 解答；想系统学习 Rollout 的进阶能力（A/B 测试、自动回滚、指标分析），可通读 Argo 主题目录 中的 Argo Rollouts 问答章节。

• 文档
• 教程
• DevOps
• 运维