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

概述

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

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

蓝绿发布

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

过程大致如下：

第一步、部署版本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 测试通常会针对特定的用户群体进行，其目的在于通过科学的实验设计、采样样本代表性、流量分割与小流量测试等方式来获得具有代表性的实验结论，并确信该结论在推广到全部流量可信；这与蓝绿发布的目的不尽相同，蓝绿发布主要是用于安全稳定地发布新版本应用，并在必要时回滚。

金丝雀发布

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

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，比较简单地集成到自己项目的微服务开发中。