---

argo-rollouts

什么是argo-rollouts

Argo-Rollout是一个Kubernetes Controller和对应一系列的CRD（自定义资源类型），提供更强大的Deployment能力。
包括灰度发布、蓝绿部署、更新测试(experimentation)、渐进式交付(progressive delivery)等特性。

主要功能

主要功能
1.蓝绿部署（Blue-Green Deployment）：
描述：同时运行两个版本的应用程序，一个是当前版本（蓝），另一个是新版本（绿）。流量从旧版本切换到新版本时，可以进行全面的测试和验证。
优势：减少停机时间和发布风险，能够快速回滚到旧版本。

2.金丝雀部署（Canary Deployment）：
描述：逐步将流量分配给新版本，开始时只分配一小部分流量，然后逐步增加。如果新版本稳定，最终分配全部流量。
优势：能够逐步验证新版本，降低发布风险。

3.渐进式流量转移（Progressive Traffic Shifting）：
描述：在一段时间内逐步将流量从旧版本转移到新版本，可以结合监控和自动化策略进行控制。
优势：细粒度的控制流量转移，进一步减少风险。

4.自动化和监控集成：
描述：与 Prometheus、Datadog 等监控系统集成，自动根据监控指标进行调整和回滚。
优势：提高部署的自动化程度，实时监控并做出响应。

核心组件

1.Rollout CRD：
定义了如何进行蓝绿部署和金丝雀部署的策略和步骤。

2.Analysis CRD：
用于定义和执行部署期间的分析任务，如基于监控数据的健康检查。

3.Experiments CRD：
允许同时运行多个版本的应用程序，并进行对比测试。

常用命令

查看 Rollout 状态：

kubectl argo rollouts get rollout <rollout-name>

查看 Rollout 历史：

kubectl argo rollouts history <rollout-name>

手动推进 Rollout：

kubectl argo rollouts promote <rollout-name>

回滚 Rollout：

kubectl argo rollouts rollback <rollout-name>

应用

环境

虚拟机

Ip	主机名	cpu	内存	硬盘
192.168.10.11	master01	2cpu双核	4G	100G
192.168.10.12	worker01	2cpu双核	4G	100G
192.168.10.13	worker02	2cpu双核	4G	100G

版本 centos7.9
已部署k8s-1.27

一、Argo rollouts安装

均在master节点操作

1. 在Kubernetes集群中安装argo rollouts

kubectl create namespace argo-rollouts
wget https://github.com/argoproj/argo-rollouts/releases/latest/download/install.yaml
kubectl -n argo-rollouts apply -f install.yaml 
kubectl -n argo-rollouts get all

2.安装argo rollouts的kubectl plugin

还可以安装一个 kubectl 插件，对于命令行管理和可视化发布非常方便。使用 curl 安装 Argo Rollouts kubectl 插件

curl -LO 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

3. Argo-Rollouts Dashboard

Argo Rollouts Kubectl 插件可以提供一个本地 Dashboard，来可视化你的 Rollouts。
要启动这个 Dashboard，需要在包含 Rollouts 资源对象的命名空间中运行 kubectl argo rollouts dashboard 命令，然后访问localhost:3100 即可。

kubectl argo rollouts dashboard &

windows浏览器访问:192.168.10.11:3100

过程比较漫长，可以先做下面部分

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

二、负载均衡器metallb部署

1. 修改kube-proxy代理模式

kubectl get configmaps -n kube-system

kubectl edit configmap kube-proxy -n kube-system

修改两处
strictARP 由原来的flase修改为true
mode 添加ipvs

kubectl rollout restart daemonset kube-proxy -n kube-system

2. metallb部署

服务器连接不了时，可在vpn连接后，Windows浏览器中访问

https://raw.githubusercontent.com/metallb/metallb/v0.14.5/config/manifests/metallb-native.yaml

看到内容后复制创建文件

vim metallb-native.yaml

使用创建的文件metallb-native.yaml进行部署

kubectl apply -f metallb-native.yaml
 kubectl -n metallb-system get pod

等待一会，可通过查看描述信息跟踪pod的运行状态，长时间无法完成下载时，各节点重启docker
查看描述信息

kubectl describe pod pod名称

3.IP地址池准备

vim ippool.yaml

apiVersion: metallb.io/v1beta1
kind: IPAddressPool
metadata:
  name: ippool
  namespace: metallb-system
spec:
  addresses:
  - 192.168.10.240-192.168.10.250

kubectl apply -f ippool.yaml

查看地址池信息：

kubectl -n metallb-system get ipaddresspool

4.开启二层通告

vim L2.yaml

apiVersion: metallb.io/v1beta1
kind: L2Advertisement
metadata:
  name: example
  namespace: metallb-system

kubectl apply -f L2.yaml

三、通过argo-rollouts实现金丝雀发布

1.金丝雀发布过程分类

金丝雀发布包含Replica Shifting和Traffic Shifting两个过程。

• Replica Shifting：版本替换

• Traffic Shifting：流量接入

2.Replica Shifting 版本替换

(1).部署应用

mkdir rsdir
cd rsdir

浏览器复制
https://raw.githubusercontent.com/argoproj/argo-rollouts/master/docs/getting-started/basic/rollout.yaml

创建rollout.yaml

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: rollouts-demo
spec:
  replicas: 5
  strategy:
    canary:
      steps:
      - setWeight: 20
      - pause: {}
      - setWeight: 40
      - pause: {duration: 10}
      - setWeight: 60
      - pause: {duration: 10}
      - setWeight: 80
      - pause: {duration: 10}
  revisionHistoryLimit: 2
  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

说明：
可以看到除了apiVersion，kind以及strategy之外，其他和Deployment无异。
strategy字段定义的是发布策略，其中：
setWeight：设置流量的权重
pause：暂停，如果里面没有跟duration: 10则表示需要手动更新，如果跟了表示等待多长时间会自动更新。

浏览器复制
https://raw.githubusercontent.com/argoproj/argo-rollouts/master/docs/getting-started/basic/service.yaml

创建service.yaml文件
vim service.yaml

apiVersion: v1
kind: Service
metadata:
  name: rollouts-demo
spec:
  ports:
  - port: 80
    targetPort: http
    protocol: TCP
    name: http
  selector:
    app: rollouts-demo

说明：
service.yaml文件定义的就是普通的service

部署YAML文件

 kubectl apply -f rollout.yaml

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

kubectl get pods

Argo Rollouts 的 kubectl 插件允许我们可视化 Rollout 以及相关资源对象，并展示实时状态变化。

查看部署状态

 kubectl-argo-rollouts get rollout rollouts-demo

可以看到该版本被标记为stable，而且STATUS为healthy。还可以在命令后面加一个–watch来实时监控服务状态，完整命令为kubectl argo rollouts get rollout rollouts-demo --watch,默认为1秒间隔。

kubectl apply -f service.yaml 
kubectl get svc

(2).更新应用

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

 kubectl argo rollouts set image rollouts-demo rollouts-demo=argoproj/rollouts-demo:yellow

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

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

kubectl argo rollouts get rollout rollouts-demo

说明：
可以看到多了一个revision:2，而且该版本被标记为canary，而且状态是Status: Paused，canary接入流量为20%。

(3).手动持续更新

部署之所以处于Paused阶段，是因为我们在rollout.yaml中定义了发布第一个版本后会暂停，这时候需要手动接入接下来的更新。
argo rollouts提供了promote来进行后续的更新，命令如下：

kubectl argo rollouts promote rollouts-demo
kubectl argo rollouts get rollout rollouts-demo

因为后续的更新在pause阶段只暂停10s，所以会依次自动更新完，不需要手动介入
如果查看的快的话应该能看到更新过程

可以看到第一个版本已经下线，第二个版本的状态为Healthy，而且镜像被标记为stable

(4).终止更新应用

如果在更新应用的过程中，最新的应用有问题，需要终止更新需要怎么做呢？
我们先使用下面命令发布新版本应用，如下：

kubectl argo rollouts set image rollouts-demo rollouts-demo=argoproj/rollouts-demo:red

然后更新动作会在第一次更新的时候处于Paused状态，现在我们可以用abort来终止发布，如下：

kubectl argo rollouts get rollout rollouts-demo

kubectl argo rollouts abort rollouts-demo
kubectl  argo rollouts get rollout rollouts-demo

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

但是我们可以看到Status是Degraded状态而并非Healthy状态，我们有必须要将其变成Healthy状态。最简单的办法就是执行如下命令重新发布一下版本：

kubectl argo rollouts set image rollouts-demo rollouts-demo=argoproj/rollouts-demo:yellow

执行过后，可以看到其状态立即变成Healthy，并且没有创建新的副本、新的版本，如下：

kubectl argo rollouts get rollout rollouts-demo

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

(5).应用回退

有时候在应用上线过后，有些BUG并没有发现，这时候要回退怎么办呢？argo rollouts有一个undo命令，可以进行回退。
比如我们要将版本回退到第一个版本，则执行一下命令：

kubectl-argo-rollouts undo rollouts-demo --to-revision=1

然后通过命令可以看到如下信息：

kubectl argo rollouts get rollout rollouts-demo

首先revision为1的版本标记没有，重新创建了一个为5的标记，而且第一步处于暂停状态，然后我们执行promote命令继续后续的更新，如下：

kubectl argo rollouts promote rollouts-demo

然后我们可以看到如下信息：

kubectl argo rollouts get rollout rollouts-demo

从Images可以看到回退到我们最初版本为blue的镜像了。