安装 argo rollouts

1
2
3
4
5
kubectl create namespace argo-rollouts
kubectl apply -n argo-rollouts -f https://github.com/argoproj/argo-rollouts/releases/download/v1.2.2/install.yaml

# 验证
kubectl get pods -n argo-rollouts

安装插件

1
2
3
4
5
6
7
8
9
10
11
12
# https://github.91chi.fun/https://github.com//argoproj/argo-rollouts/releases/download/v1.2.2/kubectl-argo-rollouts-linux-amd64

curl -LO https://github.com/argoproj/argo-rollouts/releases/download/v1.2.2/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

使用 Rollout

部署 Rollout

首先部署一个 Rollout 资源和一个针对该资源的 Kubernetes Service 对象,这里我们示例中的 Rollout 采用了金丝雀的更新策略,将 20% 的流量发送到金丝雀上,然后手动发布,最后在升级的剩余时间内逐渐自动增大流量,可以通过如下所示的 Rollout 来描述这个策略:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
# basic-rollout.yaml
apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
name: rollouts-demo
spec:
replicas: 5 # 定义5个副本
strategy: # 定义升级策略
canary: # 金丝雀发布
steps: # 发布的节奏
- setWeight: 20
- pause: {} # 会一直暂停
- setWeight: 40
- pause: { duration: 10 } # 暂停10s
- setWeight: 60
- pause: { duration: 10 }
- setWeight: 80
- pause: { duration: 10 }
revisionHistoryLimit: 2 # 下面部分其实是和 Deployment 兼容的
selector:
matchLabels:
app: rollouts-demo
template:
metadata:
labels:
app: rollouts-demo
spec:
containers:
- name: rollouts-demo
image: argoproj/rollouts-demo:blue
ports:
- name: http
containerPort: 8080
protocol: TCP
resources:
requests:
memory: 32Mi
cpu: 5m

还包括一个如下所示的 Service 资源对象:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
# basic-service.yaml
apiVersion: v1
kind: Service
metadata:
name: rollouts-demo
spec:
ports:
- port: 80
targetPort: http
protocol: TCP
name: http
selector:
app: rollouts-demo

直接创建上面的两个资源对象:

1
2
kubectl apply -f basic-rollout.yaml
kubectl apply -f basic-service.yaml

任何 Rollout 的初始创建都会立即将副本扩展到 100%(跳过任何金丝雀升级步骤、分析等…),因为还没有发生升级。

1
2
3
4
5
6
7
$ kubectl get pods -l app=rollouts-demo
NAME READY STATUS RESTARTS AGE
rollouts-demo-687d76d795-6ppnh 1/1 Running 0 53s
rollouts-demo-687d76d795-8swrk 1/1 Running 0 53s
rollouts-demo-687d76d795-fnt2w 1/1 Running 0 53s
rollouts-demo-687d76d795-mtvtw 1/1 Running 0 53s
rollouts-demo-687d76d795-sh56l 1/1 Running 0 53s

Argo Rollouts 的 kubectl 插件允许我们可视化 Rollout 以及相关资源对象,并展示实时状态变化,要在部署过程中观察 Rollout,可以通过运行插件的 get rollout --watch 命令,比如:

1
kubectl argo rollouts get rollout rollouts-demo --watch

更新 Rollout

上面已经部署完成,接下来就需要执行更新了,和 Deployment 类似,对 Pod 模板字段的任何变更都会导致新的版本(即 ReplicaSet)被部署,更新 Rollout 通常是修改容器镜像的版本,然后执行 kubectl apply ,为了方便,rollouts 插件还单独提供了一个 set image 的命令,比如这里我们运行以下所示命令,用 yellow 版本的容器更新上面的 Rollout:

1
2
3
4
$ kubectl argo rollouts set image rollouts-demo \
rollouts-demo=argoproj/rollouts-demo:yellow

rollout "rollouts-demo" image updated

在 rollout 更新期间,控制器将通过 Rollout 更新策略中定义的步骤进行。这个示例的 rollout 为金丝雀设置了 20% 的流量权重,并一直暂停 rollout,直到用户取消或促进发布。在更新镜像后,再次观察 rollout,直到它达到暂停状态。

1
$ kubectl argo rollouts get rollout rollouts-demo --watch

当 demo rollout 到达第二步时,我们可以从插件中看到,Rollout 处于暂停状态,现在有 5 个副本中的 1 个运行新版本的 pod,其余 4 个仍然运行旧版本,这相当于 setWeight: 20 步骤所定义的 20%的金丝雀权重。

Promote Rollout

经过上面的更新后,Rollout 现在处于暂停状态,当一个 Rollout 到达一个没有持续时间的暂停步骤时,它将一直保持在暂停状态,直到它被恢复/提升。要手动将 Rollout 切换到下一个步骤,请运行插件的 promotion 命令。

1
2
3
$ kubectl argo rollouts promote rollouts-demo

rollout 'rollouts-demo' promoted

切换后 Rollout 将继续执行剩余的步骤。在我们的例子中,剩余的步骤是完全自动化的,所以 Rollout 最终会完成步骤,直到它已经完全过渡到新版本。再次观察 Rollout,直到它完成所有步骤。

1
$ kubectl argo rollouts get rollout rollouts-demo --watch

promote 命令还支持用 --full 标志跳过所有剩余步骤和分析。

可以看到 stable 版本已经切换到 revision:2 这个 ReplicaSet 了。在更新过程中,无论何时,无论是通过失败的金丝雀分析自动中止,还是由用户手动中止,Rollout 都会退回到 stable 版本。

中断 Rollout

如何在更新过程中手动中止 Rollout,首先,使用 set image 命令部署一个新的 red 版本的容器,并等待 rollout 再次达到暂停的步骤。

1
2
3
4
$ kubectl argo rollouts set image rollouts-demo \
rollouts-demo=argoproj/rollouts-demo:red

rollout "rollouts-demo" image updated

这一次中止更新,而不是将滚动切换到下一步,这样它就回到了 stable 版本,该插件同样提供了一个 abort 命令,可以在更新过程中的任何时候手动中止 Rollout。

1
$ kubectl argo rollouts abort rollouts-demo

当中止滚动时,它将扩大 ReplicaSet 的 stable 版本(在本例中是 yellow 版本),并缩小任何其他版本。尽管 ReplicaSet 的稳定版本可能正在运行,并且是健康的,但整个 Rollout 仍然被认为是退化的,因为期望的版本(red 版本)不是实际运行的版本。

1
$ kubectl argo rollouts get rollout rollouts-demo --watch

为了使 Rollout 再次被认为是健康的而不是有问题的版本,有必要将所需的状态改回以前的稳定版本。在我们的例子中,我们可以简单地使用之前的 yellow 镜像重新运行 set image 命令即可。

1
2
$ kubectl argo rollouts set image rollouts-demo \
rollouts-demo=argoproj/rollouts-demo:yellow

运行这个命令后,可以看到 Rollout 立即变成了 health 状态,而且没有任何关于创建新 ReplicaSets 的动态。

1
$ kubectl argo rollouts get rollout rollouts-demo --watch

当 Rollout 还没有达到预期状态(例如,它被中止了,或者正在更新中),而稳定版本的资源清单被重新应用,Rollout 检测到这是一个回滚,而不是一个更新,并将通过跳过分析和步骤快速部署稳定的 ReplicaSet。

上面例子中的 Rollout 没有使用 Ingress 控制器或服务网格来控制流量。相反,它使用正常的 Kubernetes Service 来实现近似的金丝雀权重,基于新旧副本数量的比例来实现。所以,这个 Rollout 有一个限制,即它只能实现 20% 的最小加权,通过扩展 5 个 pod 中的一个来运行新版本。为了实现更细粒度的金丝雀,这就需要一个 Ingress 控制器或服务网格了。

Dashboard

Argo Rollouts Kubectl 插件可以提供一个本地 Dashboard,来可视化你的 Rollouts。

要启动这个 Dashboard,需要在包含 Rollouts 资源对象的命名空间中运行 kubectl argo rollouts dashboard 命令,然后访问localhost:3100 即可

点击 Rollout 可以进行详细页面,在详细页面可以看到 Rollout 的配置信息,还可以直接在 UI 界面上执行一些常用的操作,比如重启、重启、中断等。