Istio流量管理实践之(2): 通过Istio管理应用的灰度发布

9天前 231

概述

在项目迭代的过程中,不可避免需要上线。上线对应着部署,或者重新部署;部署对应着修改;修改则意味着风险。

灰即在黑与白之间,灰度发布就是指能够平滑过渡的一种发布方式。灰度发布可以保证整体系统的稳定,在初始灰度的时候就可以发现、调整问题,以保证其影响度,而我们平常所说的AB测试、金丝雀发布等也就是灰度发布的不同方式。

蓝绿发布

蓝绿发布是指不停老版本,部署新版本然后进行测试,确认没有问题之后,将流量切到新版本,然后老版本同时也升级到新版本。它的特点是无需停机,并且风险较小。

图片.png

过程大致如下:

  • 第一步、部署版本1的应用(一开始的状态),所有外部请求的流量都打到这个版本上。
  • 第二步、部署版本2的应用,版本2的代码与版本1不同(新功能、Bug修复等)。
  • 第三步、将流量从版本1切换到版本2,即流量从v1:v2为100:0,切换为0:100。
  • 第四步,如果版本2存在问题,需要回滚到版本1,进行流量切换回v1:v2为100:0。

A / B测试

A/B 测试不同于蓝绿发布,它是用来测试应用功能表现的一种方法,例如可用性、受欢迎程度、可见性等等。 A/B 测试通常会针对特定的用户群体进行,其目的在于通过科学的实验设计、采样样本代表性、流量分割与小流量测试等方式来获得具有代表性的实验结论,并确信该结论在推广到全部流量可信;这与蓝绿发布的目的不尽相同,蓝绿发布主要是用于安全稳定地发布新版本应用,并在必要时回滚。

图片.png

金丝雀发布

金丝雀发布是指通过让一小部分用户流量引入的新版本进行测试,如果一切顺利,则可以增加(可能逐渐增加)百分比,逐步替换旧版本。如在过程中出现任何问题,则可以中止并回滚到旧版本。最简单的方式,是随机选择百分比请求到金丝雀版本,但在更复杂的方案下,则可以基于请求的内容、特定范围的用户或其他属性等。

图片.png

Kubernetes中的灰度发布

Kubernetes自带的rolling-update 功能提供了一种渐进式的更新过程,可以实现不中断业务的应用升级。简要回顾下Kubernetes的升级策略。

spec:
  replicas: 5
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 2
      maxUnavailable: 2
  minReadySeconds: 5
  • maxSurge: 升级过程中最多可以比原先设定所多出的pod 数量,此栏位可以为固定值或是比例(%)。例如:maxSurge: 1、replicas: 5,代表Kubernetes 会先开好1 个新pod 后才删掉一个旧的pod,整个升级过程中最多会有5+1 个pod。
  • maxUnavailable: 最多可以有几个pod 处在无法服务的状态,当maxSurge不为零时,此栏位亦不可为零。例如. maxUnavailable: 1,代表Kubernetes 整个升级过程中最多会有1 个pod 处在无法服务的状态。
  • minReadySeconds: 容器内应用程式的启动时间,Kubernetes 会等待设定的时间后才继续进行升级流程,如果没有此栏位的话,Kubernetes 会假设该容器一开完后即可进行服务。

实现滚动升级的方式也有以下几种:

  • 使用kubectl set image
  • 使用kubectl replace
  • 使用kubectl rollout

尽管这种机制能够很好地工作,但只适用于部署的经过适当测试的版本,也就是说,更多的是蓝/绿发布场景。实际上,Kubernetes 中的金丝雀发布将使用具有相同Label的两个 Deployment 来完成。在这种情况下,我们不能再使用AutoScaler,因为是有由两个独立的AutoScaler来进行控制,不同负载情况下,replicas比例(百分比)可能与所需的比例不同。

无论我们使用一个或者两个部署,使用 Kubernetes 进行的金丝雀发布都存在一个根本问题:使用实例扩容来管理流量;这是因为版本流量分发和副本部署在Kubernetes平台中并非独立。所有 pod 副本,无论版本如何,在 kube-proxy 循环池中都被相同对待,因此管理特定版本接收的流量的唯一方法是控制副本比例。以小百分比例的金丝雀流量需要许多副本(例如1% 将需要至少 100 个副本)。即使我们可以忽略这个问题,部署方式功能仍然非常有限,因为它只支持简单(随机百分比)金丝雀部署。如果想根据某些特定规则将请求路由到金丝雀版本上,仍然需要另一种解决方案。这就是Istio的。

使用 Istio进行灰度发布

使用Istio的流量管理模型,本质上是将流量与基础设施扩容进行解耦,让运维人员可以通过Pilot指定流量遵循什么规则,而不是指定哪些pods/VM应该接收流量。通过将流量从基础设施扩展中解耦,就可以让 Istio 提供各种独立于应用程序代码之外的流量管理功能。 这些功能都是通过部署的Envoy sidecar代理来实现的。

在使用 Istio实现灰度发布的情况下,流量路由和副本部署是两个完全独立的功能。服务的 pod 数量可以根据流量负载灵活伸缩,与版本流量路由的控制完全无关。这在自动缩放的情况下能够更加简单地管理金丝雀版本。

Istio 的路由规则非常灵活,可以支持细粒度控制流量百分比(例如,路由 1% 的流量而不需要 100 个 pod),也可以使用其他规则来控制流量(例如,将特定用户的流量路由到金丝雀版本)。如下所示:

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: addedvalues
spec:
  hosts:
  - addedvalues
  http:
  - match:
    - headers:
        end-user:
          prefix: yunqi
    route:
    - destination:
        host: addedvalues
        subset: v3
  - route:
    - destination:
        host: addedvalues
        subset: v2
      weight: 50
    - destination:
        host: addedvalues
        subset: v1
      weight: 50  

独立于AutoScaler

使用 Istio进行灰度发布时,由于不再使用副本比例维持流量分发比例,所以可以安全地设置 Kubernetes HPA 来管理两个版本 Deployment 的副本。

统一的流量路由规则

无论是蓝绿发布,还是AB测试或金丝雀发布,基于Istio提供的统一的流量路由规则定义可以实现。具体如下:

基于流量比例的发布

Istio根据输入的流量比例来确定流量分发的比重。范围限制为[0, 100],

  • 例如,当版本v1配置为0,版本v2配置为100时,这种场景即为蓝绿发布中使用到的规则。
  • 此外,如果版本v1比例设置为x,则x%的服务流量会走向此版本v1,(100-x)%的流量会走向版本v2,即从版本v1分走一部分流量。这种场景即为金丝雀发布或AB测试中使用到的规则。

基于请求内容的发布

基于请求内容的发布会遍历除默认版本外的全部金丝雀规则,若满足某个版本的规则,则流量走向此版本,若全部不满足,则流量会走到默认版本。这种场景即为金丝雀发布或AB测试中使用到的规则。

总结

如上所述,Istio 可以支持灵活规则下的金丝雀发布,以及区别于Kubernetes 部署方式。Istio 服务网格提供了管理流量分配所需的基础控制,并完全独立于AutoScaler,从而允许简单而强大的方式来进行金丝雀测试和上线。

支持金丝雀部署的智能路由只是 Istio 的众多功能之一,它将使基于大型微服务的应用程序的生产部署变得更加简单。欢迎大家使用阿里云上的容器服务,快速搭建微服务的开放治理平台Istio,比较简单地集成到自己项目的微服务开发中。

云栖社区 集群 微服务 容器 测试 负载均衡 kubernetes 高可用架构 Istio servicemesh 服务网格 基础中间件 解决方案/技术支持

作者

osswangxining
TA的文章

相关文章

评论 评论(1)

我爱你好0

2018-11-09 16:47:32

强力好文,支持大拿!!