k8s灰度发布神器之argo-rollouts

k8s灰度发布工具之argo-rollouts #

Kubernetes默认的Deployment资源支持两种发布策略:RollingUpdateRecreate,这两个恶略可以满足大部分发布场景;但是针对于各种大规模的生产场景,需要额外的发布策略,比如蓝绿部署或者金丝雀部署。为了满足改需求,argo-rollouts应运而生。

背景 #

Recreate策略毫无平滑可言,通常用于仅可运行单副本的有状态应用/job。

RollingUpdate策略,在完善的Pod生命周期前提下,能做到平滑。

在生产持续部署过程中,多多少少会因为一些纰漏,导致新上线的应用出现问题;如果使用RollingUpdate,一旦下发指令,不可中断,直接影响全部流量,影响过大。

要解决/缓解该问题,有几个努力方向:

  • 尽可能完善的测试,减少问题
  • 使用蓝绿部署,在新版本集中进行完善的测试;确认没问题后,切换流量到新版本
  • 使用金丝雀部署,先更新部分副本,然后使用生产小流量(比如1%)进行验证,确认没问题之后,再缓慢放开,5% 20% 50% 100%

argo-rollouts咋工作的 #

跟Deployment对象类似,Rollout对象管理ReplicaSets。Rollout的spec.strategy字段决定发布如何从老的replicaSet变为新的replicaSet,期间可暂停,可继续,可发布更新的版本。假设三个阶段,分别对应三个replicaSets:stable、new、newer,当stable -> new时,当前处于desiredWeight/Paused状态:

  • 如果newer发布,那么new -> 0,newer -> desiredWeight,stable -> newer
  • 如果abort操作,那么new -> 0,stable -> max
  • 如果promote操作,那么new -> max, stable ->0

argo-rollouts使用场景 #

  • 用户想在生产环境基于新版本做最后一分钟的功能测试,那么可以使用蓝绿部署。本质就是两个Service的切换
  • 用户想在线上流量进来之前,需要做一系列准备,比如预热,初始化等操作,那么可以使用蓝绿部署。在绿版本上完成相应的操作,然后再切换接收线上流量
  • 用户想在生产环境使用小流量验证一段时间,确认稳定运行,没有Bug之后,再全量发布,那么可以使用金丝雀部署。小流量发布后,暂停验证,查看日志,观测应用指标,然后决定是回滚还是继续推进
  • 用户想慢慢的放进生产流量,那么可以使用金丝雀部署。定义多steps,慢慢调大权重
  • 用户任性,说我不想用任何策略,就想滚动更新,那么也可以使用Rollout,将steps置空即可。

部署 #

集群级别部署argo rollouts #

$ kubectl apply -n argo-rollouts -f https://raw.githubusercontent.com/argoproj/argo-rollouts/stable/manifests/install.yaml
官方文档讲得挺详细的,自行摸索吧

安装kubectl插件 #

curl -LO https://github.com/argoproj/argo-rollouts/releases/latest/download/kubectl-argo-rollouts-darwin-amd64
chmod +x ./kubectl-argo-rollouts-darwin-amd64
sudo mv ./kubectl-argo-rollouts-darwin-amd64 /usr/local/bin/kubectl-argo-rollouts
kubectl argo rollouts version

附录 #

常用命令 #

kubectl argo rollouts list rollouts
kubectl argo rollouts abort app-rollout
kubectl argo rollouts promote app-rollout