k8s灰度发布神器之argo-rollouts

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

Kubernetes默认的Deployment资源支持两种发布策略：RollingUpdate和Recreate，这两个恶略可以满足大部分发布场景；但是针对于各种大规模的生产场景，需要额外的发布策略，比如蓝绿部署或者金丝雀部署。为了满足改需求，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