DevOps全链路实战 | 第 14 天：Argo Rollouts 安装与基础概念：CRD 与 Rollout 资源定义

第 14/19 天

引言

在前 13 天的系列文章中，我们已经完成了从 Harbor 镜像仓库、GitLab CI 流水线、SonarQube 代码质量检查，到 Argo CD GitOps 持续部署，再到 Prometheus/Grafana 可观测性与 Alertmanager 告警通知的完整链路搭建。至此，一条”代码提交→自动构建→自动部署→全链路监控”的 DevOps 管道已经成型。

然而，这条管道在”部署”环节仍有一个明显短板：Argo CD 的原生同步机制是全量替换式的——新版本镜像一推上去，所有 Pod 立即滚动更新，无法精确控制流量分配比例，更没有基于指标的自动回滚能力。一旦新版本有缺陷，只能靠人工 kubectl rollback 或重新提交 Git 变更来回滚，风险高、响应慢。

Argo Rollouts 正是为此而生。它作为 Argo CD 生态的重要补充，提供了渐进式交付（Progressive Delivery）能力：金丝雀发布（Canary）、蓝绿部署（Blue-Green）、基于 Prometheus 指标的自动分析与回滚。今天我们先从安装与核心概念入手，为后续金丝雀实战打好基础。

核心概念

Rollout vs Deployment

Argo Rollouts 引入了一个新的 CRD——Rollout，它在功能上是 Kubernetes 原生 Deployment 的超集。一个 Rollout 资源的结构与 Deployment 几乎一致，但增加了 strategy 字段来定义渐进式发布策略：

特性	Deployment	Rollout
滚动更新	支持	支持
金丝雀发布	不支持	支持（setWeight 流量分割）
蓝绿部署	不支持	支持（即时切换 + 保留旧版）
基于指标自动回滚	不支持	支持（AnalysisTemplate）
Pause/Resume	手动	内置步骤化控制

将 Deployment 迁移到 Rollout 非常简单——只需将 kind 改为 Rollout，并把 strategy 从 RollingUpdate 改为 Canary 或 BlueGreen 即可。

关键 CRD 与组件

Argo Rollouts 安装后会引入以下 CRD：

Rollout：核心工作负载，替代 Deployment
AnalysisRun / AnalysisTemplate：定义指标分析逻辑，驱动自动推进或回滚
Experiment：用于 A/B 测试场景，可同时运行多个版本进行对比
AnalysisRun：每次分析实际运行的实例

核心组件包括：

rollouts-controller：核心控制器，监听 Rollout 资源变更并协调 Pod 创建、流量切换
argo-rollouts CLI：命令行工具，用于手动 promote/abort/retry 发布

实战步骤

1. 安装 Argo Rollouts Controller

通过官方 manifest 直接安装，它会在 argo-rollouts 命名空间创建控制器及所有 CRD：

💻 代码示例

# 创建命名空间并安装控制器

kubectl create namespace argo-rollouts

# 安装最新稳定版（v1.x）

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

# 验证控制器 Pod 运行状态

kubectl get pods -n argo-rollouts

# 预期输出：

# NAME READY STATUS RESTARTS AGE

# argo-rollouts-5f8c9d6b4-x2y3z 1/1 Running 0 30s

确认所有 CRD 已注册：

💻 代码示例

kubectl get crd | grep argoproj

# 预期输出：

# analysisruns.argoproj.io

# analysistemplates.argoproj.io

# experiments.argoproj.io

# rollouts.argoproj.io

2. 安装 argo-rollouts CLI

CLI 工具用于实时观察发布进度、手动 promote 或 abort，是日常运维必备：

💻 代码示例

# 下载最新版 CLI（请根据实际版本号调整）

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

# 赋予执行权限并安装到 PATH

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

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

# 验证安装

kubectl argo rollouts version

# rollouts controller: version v1.x.x+…

3. 第一个 Rollout 资源定义

下面定义一个简单的 Rollout，使用金丝雀策略，分两步将流量从 20% 逐步切到 100%，中间设置 2 分钟暂停用于人工验证：

💻 代码示例

apiVersion: argoproj.io/v1alpha1

kind: Rollout

metadata:

name: demo-app-rollout

namespace: default

labels:

app: demo-app

spec:

replicas: 4

selector:

matchLabels:

app: demo-app

template:

metadata:

labels:

app: demo-app

spec:

containers:

– name: demo-app

image: registry.stellardata.top/demo/app:v1.0.0

ports:

– containerPort: 8080

resources:

requests:

cpu: 100m

memory: 128Mi

limits:

cpu: 250m

memory: 256Mi

strategy:

canary:

steps:

– setWeight: 20

– pause: { duration: 2m }

– setWeight: 50

– pause: { duration: 2m }

– setWeight: 100

上述配置的含义：更新镜像后，控制器先将 20% 的 Pod 替换为新版本（配合 Istio/NGINX Ingress 做流量分割），暂停 2 分钟供人工观察指标；随后推进到 50%，再暂停；最后全量切到 100%，完成发布。

4. 部署并观察发布过程

💻 代码示例

# 应用 Rollout 资源

kubectl apply -f demo-rollout.yaml

# 查看 Rollout 状态

kubectl argo rollouts get rollout demo-app-rollout –watch

# 输出会实时显示：Canary、Weight、StepIndex 等信息

当更新镜像版本触发新发布时，可看到金丝雀逐步推进的可视化进度。如需手动确认继续（在无限暂停场景），执行：

💻 代码示例

# 手动推进到下一步

kubectl argo rollouts promote demo-app-rollout

# 发现问题，立即中止并回滚

kubectl argo rollouts abort demo-app-rollout

5. 与 Argo CD 集成

Argo Rollouts 与 Argo CD 天然兼容——只需在 Argo CD Application 的 manifest 中直接引用包含 Rollout 资源的 Git 仓库即可。但需要确保 Argo CD 的 resource.customizations 配置中，对 Rollout 的健康检查策略正确：

💻 代码示例

# Argo CD argocd-cm ConfigMap 片段

data:

resource.customizations.health.argoproj.io_Rollout: |

hs = {}

if obj.status ~= nil then

if obj.status.phase == "Healthy" then

hs.status = "Healthy"

hs.message = "Rollout is healthy"

elseif obj.status.phase == "Progressing" then

hs.status = "Progressing"

hs.message = "Rollout is progressing"

elseif obj.status.phase == "Degraded" then

hs.status = "Degraded"

hs.message = "Rollout is degraded"

end

return hs

这样 Argo CD 界面就能正确识别 Rollout 的健康状态，避免在金丝雀推进期间误报同步失败。

常见问题

Q1：Rollout 与 Deployment 能否共存？

不建议对同一应用同时维护 Deployment 和 Rollout。Rollout 会接管 Pod 的创建与更新，若同时存在同名的 Deployment 会产生冲突。迁移时先删除（或缩容到 0）旧 Deployment，再创建 Rollout。

Q2：不使用 Service Mesh 能做金丝雀吗？

可以。Argo Rollouts 支持多种流量路由后端：Istio、NGINX Ingress、ALB（AWS）、SMI 等。如果没有 Service Mesh，可以使用 NGINX Ingress Controller 的 canary annotation 实现基于 HTTP Header 或权重的流量分割，功能略受限但足以满足基本金丝雀需求。

Q3：安装后 Pod 一直 Pending？

通常是因为 install.yaml 中的镜像拉取策略默认为 Always，在内网离线环境下需要先通过 Harbor 中转镜像，并将 manifest 中的镜像地址改写为私有仓库地址。建议用 kustomize 做镜像地址替换：

💻 代码示例

# 使用 kustomize 替换镜像地址后安装

kustomize build overlays/harbor-mirror | kubectl apply -n argo-rollouts -f –

总结

今天我们完成了 Argo Rollouts 的安装部署，理解了 Rollout CRD 的结构与核心概念，并编写了第一个金丝雀策略的 Rollout 资源。Argo Rollouts 的价值在于：它将”发布”从一瞬间的全量替换，变成了可控、可观察、可回滚的渐进过程，为生产环境的安全交付提供了坚实保障。

掌握安装与基础定义后，下一步就是真正跑通一次金丝雀发布流程，结合流量分割与人工/自动决策节点，体会渐进式交付的完整魅力。