【argo-rollout】介绍

文章目录

  • Argo Rollout - Kubernetes渐进式交付控制器
    • 什么是Argo Rollouts?
    • 为什么使用Argo Rollouts?
    • 控制器的特性
    • Quick Start
    • 他是怎么工作的
    • ArgoRollout的使用案例

Argo Rollout - Kubernetes渐进式交付控制器

什么是Argo Rollouts?

  • Argo Rollouts是K8S控制器和一套CRD
    • 他为K8S提供先蓝绿、金丝雀(灰度)、金丝雀分析的渐进式交付功能
  • Argo Rollouts与ingress controller和服务网格整合,利用其流量整形能力在更新期间将流量逐步转移到新版本
    • 此外Rollout可以获取指标来验证关键api,然后在更新期间自动推进更新或回滚
https://youtu.be/hIL0E2gLkf8  # 演示视频

为什么使用Argo Rollouts?

  • 原生的k8s deployment支持滚动更新,并且通过就绪探针做了基本的安全保障。然而滚动更新策略面临许多限制
    • 对发布速度的控制很少
    • 无法控制流向新版本的流量
    • 就绪探针不适用于更深层次的压力测试和一次性测试
    • 没有能力查询外部指标来验证更新
    • 可以停止进程,但无法自动中止和回滚更新
  • 由于这些原因,在大规模、高容量的生产环境中,滚动更新被认为是风险过大的更新程序,因为他没有提供对爆炸半径(SRE的一些概念)的控制,可能过于激进地推进更新、并且在失败时没有提供自动回滚

控制器的特性

  • 蓝绿发布策略
  • 金丝雀发布策略
  • 细粒度加权流量转移
  • 自动回滚和推进发布
  • 手动评估
  • 可定制的指标查询,业务关键KPI分析
  • Ingress 控制器集成,NGINX、ALB、Apache APISIX
  • 服务网格集成,Isito,Linkerd,SMI
  • 同时使用多个提供者: SMI + NGINX,Istio + ALB,等等
  • Metric provider integration: Prometheus, Wavefront, Kayenta, Web, Kubernetes Jobs, Datadog, New Relic, Graphite, InfluxDB

Quick Start

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

他是怎么工作的

  • 与deployment相似,ArgoRollout 控制器会管理的副本集的创建、扩缩容、删除
    • 这些副本集(ReplicasSet)资源内的sepc.template字段定义,它适用与部署对象相同的Pod模板
  • 当spec.template改变了,他会向Argo Rollout控制器发出信号,引入一个新的ReplicaSet。
    • 控制器将使用spec.strategy字段中设定的策略,以决定如何从旧RS(ReplicaSet)扩展到新RS
    • 一旦这个新的ReplicaSet被扩展(可以选择通过分析),控制器将把他标记为“稳定”
  • 如果从稳定的RS过渡到新的RS过程中,spec.template发生了变化(即渐进更新时改变了应用程序版本),那么值钱的新RS将被缩减,控制器将尝试渐进发布更新的spec.template字段的RS

ArgoRollout的使用案例

  • 一个用户希望新版本开始产生流量进行服务之前,对其进行最后一分钟的功能测试
    • 通过蓝绿部署策略,ArgoRollout允许用户指定一个预览服务和一个活动服务
    • Rollout将配置预览服务来发送流量到新版本,而活动服务继续接受生产流量
    • 一旦用户满意,他可以将预览服务提升为新的活动服务
  • 在新版本开始接收实时流量之前,需要事先执行一套通用的步骤
    • 通过蓝绿部署策略,用户可以在不接收活动服务的流量的情况下调出新的版本
    • 一旦这些步骤执行完毕,rollout就可以将流量切到新版本
  • 一个用户想把一小部分生产流量给他们的应用程序的一个新版本使用几个小时。之后,他们想缩小新版本的规模并查看一些指标,以确定新版本和旧版本相比是否更具性能。然后决定是否为所有的生产流量推出新的版本,或者坚持使用当前的版本
    • 通过金丝雀策略,rollout可以用新版本扩大RS的规模,以接受指定百分比的流量,等待指定的时间,将百分比设回0,
    • 然后等用户满意后rollout为所有与流量提供服务
  • 一个用户想慢慢地给新版本增加生产流量,开始时只给他一部分的实时流量,等一段时间后再给新版本更多的流量。最终,新版本将接收所有的生产流量。通过金丝雀策略,用户可以指定他们希望新版本接收的百分比,以及百分比之间的等待时间
  • 一个用户希望使用部署中的滚动更新策略,如果用户使用没有步骤的金丝雀策略,滚动将使用最大激增值和最大不可用值来滚动到新版本

你可能感兴趣的:(argo-rollout,kubernetes,docker,运维,argo-rollout)