@TOC
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
创建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则表示需要手动更新,如果跟了表示等待多长时间会自动更新。
创建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的镜像了。