采用Istio实现灰度发布，给运维人员一支强心剂

Posted ServiceMesh中文网

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了采用Istio实现灰度发布，给运维人员一支强心剂相关的知识，希望对你有一定的参考价值。


作者简介：

      赵化冰是一名程序员及开源软件爱好者，目前在NFV＆SDN编排开源社区ONAP担任MSB项目PTL，致力于高性能，高可用性微服务架构在编排领域的应用。

      博客链接：http://zhaohuabing.com/

目录

一、灰度发布（又名金丝雀发布）介绍

二、Istio实现灰度发布(金丝雀发布)的原理

三、操作步骤

  1. 测试环境安装

  2. 部署V1版本的服务

  3. 部署V2版本的reviews服务

  4. 将测试流量导入到V2版本的reviews服务

  5. 将部分生产流量导入到V2版本的reviews服务

  6. 将所有生产流量导入到到V2版本的reviews服务

  7. 删除V1版本的reviews服务

四、参考



一、灰度发布（又名金丝雀发布）介绍


当应用上线以后，运维面临的一大挑战是如何能够在不影响已上线业务的情况下进行升级。做过产品的同学都清楚，不管在发布前做过多么完备的自动化和人工测试，在发布后都会出现或多或少的故障。根据墨菲定律，可能会出错的版本发布一定会出错。


“ANYTHING THAT CAN GO WRONG WILL GO WRONG” –MURPHY’S LAW


因此我们不能寄希望于在线下测试时发现所有潜在故障。在无法百分百避免版本升级故障的情况下，需要通过一种方式进行可控的版本发布，把故障影响控制在可以接受的范围内，并可以快速回退。


可以通过灰度发布（又名金丝雀发布）来实现业务从老版本到新版本的平滑过渡，并避免升级过程中出现的问题对用户造成的影响。


“金丝雀发布”的来源于矿工们用金丝雀对矿井进行空气测试的做法。以前矿工挖煤的时候，矿工下矿井前会先把金丝雀放进去，或者挖煤的时候一直带着金丝雀。金丝雀对甲烷和一氧化碳浓度比较敏感，会先报警。所以大家都用“金丝雀”来搞最先的测试。


下图中，左下方的少部分用户就被当作“金丝雀”来用于测试新上线的1.1版本。如果新版本出现问题，“金丝雀”们会报警，但不会影响其他用户业务的正常运行。


灰度发布（金丝雀发布）的流程如下：


  • 准备和生产环境隔离的“金丝雀”服务器。

  • 将新版本的服务部署到“金丝雀”服务器上。

  • 对“金丝雀”服务器上的服务进行自动化和人工测试。

  • 测试通过后，将“金丝雀”服务器连接到生产环境，将少量生产流量导入到“金丝雀”服务器中。

  • 如果在线测试出现问题，则通过把生产流量从“金丝雀”服务器中重新路由到老版本的服务的方式进行回退，修复问题后重新进行发布。

  • 如果在线测试顺利，则逐渐把生产流量按一定策略逐渐导入到新版本服务器中。

  • 待新版本服务稳定运行后，删除老版本服务。




二、Istio实现灰度发布的原理


从上面的流程可以看到，如果要实现一套灰度发布的流程，需要应用程序和运维流程对该发布过程进行支持，工作量和难度的挑战是非常大的。虽然面对的问题类似，但每个企业或组织一般采用不同的私有化实现方案来进行灰度发布,为解决该问题导致研发和运维花费了大量的成本。


Istio通过高度的抽象和良好的设计采用一致的方式解决了该问题，采用sidecar对应用流量进行了转发，通过Pilot下发路由规则，可以在不修改应用程序的前提下实现应用的灰度发布。


备注：采用kubernetes的滚动升级(rolling update)功能也可以实现不中断业务的应用升级,但滚动升级是通过逐渐使用新版本的服务来替换老版本服务的方式对应用进行升级，在滚动升级不能对应用的流量分发进行控制，因此无法采用受控地把生产流量逐渐导流到新版本服务中，也就无法控制服务升级对用户造成的影响。


采用Istio后，可以通过定制路由规则将特定的流量（如指定特征的用户）导入新版本服务中，在生产环境下进行测试，同时通过渐进受控地导入生产流量，可以最小化升级中出现的故障对用户的影响。并且在同时存在新老版本服务时，还可根据应用压力对不同版本的服务进行独立的缩扩容，非常灵活。采用Istio进行灰度发布的流程如下图所示：采用Istio实现灰度发布，给运维人员一支强心剂




三、操作步骤


下面采用Istion自带的BookinfoInfo示例程序来试验灰度发布的流程。


1.测试环境安装


首先参考手把手教你从零搭建Istio及Bookinfo示例程序安装Kubernetes及Istio控制面。


因为本试验并不需要安装全部3个版本的reviews服务，因此如果已经安装了该应用，先采用下面的命令卸载。


istio-0.2.10/samples/bookinfo/kube/cleanup.sh



2.部署V1版本的服务


首先只部署V1版本的Bookinfo应用程序。由于示例中的yaml文件中包含了3个版本的reviews服务，我们先将V2和V3版本的Deployment从yaml文件istio-0.2.10/samples/bookinfo/kube/bookinfo.yaml中删除。


从Bookinfo.yaml中删除这部分内容:

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: reviews-v2
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: reviews
        version: v2
    spec:
      containers:
      - name: reviews
        image: istio/examples-bookinfo-reviews-v2:0.2.3
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 9080
---
apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: reviews-v3
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: reviews
        version: v3
    spec:
      containers:
      - name: reviews
        image: istio/examples-bookinfo-reviews-v3:0.2.3
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 9080    
---        



部署V1版本的Bookinfo程序。



kubectl apply -f <(istioctl kube-inject -f istio-0.2.10/samples/bookinfo/kube/bookinfo.yaml)


通过kubectl命令行确认pod部署，可以看到只有V1版本的服务。

kubectl get pods

NAME                                             READY    STATUS     RESTARTS   AGE
details-v1-3688945616-nhkqk           2/2         Running      0                2m
productpage-v1-2055622944-m3fql  2/2         Running      0                2m
ratings-v1-233971408-0f3s9             2/2         Running      0                2m
reviews-v1-1360980140-0zs9z          2/2         Running      0                2m


http://10.12.25.116/productpage
采用Istio实现灰度发布，给运维人员一支强心剂


此时系统中微服务的部署情况如下图所示（下面的示意图均忽略和本例关系不大的details和ratings服务）：采用Istio实现灰度发布，给运维人员一支强心剂



3.部署V2版本的reviews服务


在部署V2版本的reviews服务前，需要先创建一条缺省路由规则route-rule-default-reviews.yaml，将所有生产流量都导向V1版本，避免对线上用户的影响。


apiVersion: config.istio.io/v1alpha2
kind: RouteRule
metadata:
  name: reviews-default
spec:
  destination:
    name: reviews
  precedence: 1
  route:
  - labels:
      version: v1


启用该路由规则。

istioctl create -f route-rule-default-reviews.yaml -n default


创建一个V2版本的部署文件bookinfo-reviews-v2.yaml，内容如下

apiVersion: extensions/v1beta1
kind: Deployment
metadata:
  name: reviews-v2
spec:
  replicas: 1
  template:
    metadata:
      labels:
        app: reviews
        version: v2
    spec:
      containers:
      - name: reviews
        image: istio/examples-bookinfo-reviews-v2:0.2.3
        imagePullPolicy: IfNotPresent
        ports:
        - containerPort: 9080


部署V2版本的reviews服务。

kubectl apply -f <(istioctl kube-inject -f  bookinfo-reviews-v2.yaml)


此时系统中部署了V1和V2两个版本的reviews服务，但所有的业务流量都被规则reviews-default导向了V1，如下图所示：采用Istio实现灰度发布，给运维人员一支强心剂


4.将测试流量导入到V2版本的reviews服务


在进行模拟测试时，由于测试环境和生产环境的网络，服务器，操作系统等环境存在差异，很难完全模拟生产环境进行测试。为了减少环境因素的对测试结果的影响，我们希望能在生产环境中进行上线前的测试，但如果没有很好的隔离措施，可能会导致测试影响已上线的业务，对企业造成损失。


通过采用Istio的路由规则，可以在类生产环境中进行测试，又完全隔离了线上用户的生产流量和测试流量，最小化模拟测试对已上线业务的影响。如下图所示：采用Istio实现灰度发布，给运维人员一支强心剂

创建一条规则，将用户名为 test-user 的流量导入到V2


apiVersion: config.istio.io/v1alpha2
kind: RouteRule
metadata:
  name: reviews-test-user
spec:
  destination:
    name: reviews
  precedence: 2
  match:
    request:
      headers:
        cookie:
          regex: "^(.*?;)?(user=test-user)(;.*)?$"
  route:
  - labels:
      version: v2


注意：precedence属性用于设置规则的优先级，在同时存在多条规则的情况下，优先级高的规则将先执行。这条规则的precedence设置为2，以确保其在缺省规则之前运行，将test-user用户的请求导流到V2版本reviews服务中。


启用该规则。

istioctl create -f route-rule-test-reviews-v2.yaml -n default


以test-user用户登录，可以看到V2版本带星级的评价页面。采用Istio实现灰度发布，给运维人员一支强心剂

注销test-user，只能看到V1版本不带星级的评价页面。如下图所示：采用Istio实现灰度发布，给运维人员一支强心剂


5.将部分生产流量导入到V2版本的reviews服务


在线上模拟测试完成后，如果系统测试情况良好，可以通过规则将一部分用户流量导入到V2版本的服务中，进行小规模的“金丝雀”测试。


修改规则route-rule-default-reviews.yaml，将50%的流量导入V2版本。


备注：本例只是描述原理，因此为简单起见，将50%流量导入V2版本，在实际操作中，更可能是先导入较少流量，然后根据监控的新版本运行情况将流量逐渐导入，如采用5%，10%，20%，50% …的比例逐渐导入。

apiVersion: config.istio.io/v1alpha2
kind: RouteRule
metadata:
  name: reviews-default
spec:
  destination:
    name: reviews
  precedence: 1
  route:
  - labels:
      version: v1
    weight: 50
  - labels:
      version: v2
    weight: 50
istioctl replace -f route-rule-default-reviews.yaml -n default


此时系统部署如下图所示：采用Istio实现灰度发布，给运维人员一支强心剂


6.将所有生产流量导入到到V2版本的reviews服务


如果新版本的服务运行正常，则可以将所有流量导入到V2版本。

apiVersion: config.istio.io/v1alpha2
kind: RouteRule
metadata:
  name: reviews-default
spec:
  destination: 
    name: reviews
  precedence: 1
  route:
  - labels:
      version: v2
    weight: 100
istioctl replace -f route-rule-default-reviews.yaml -n default


系统部署如下图所示：采用Istio实现灰度发布，给运维人员一支强心剂

此时不管以任何用户登录，都只能看到V2版本带星级的评价页面，如下图所示：

备注：如果灰度发布的过程中新版本的服务出现问题，则可以通过修改路由规则，将流量重新导入到V1版本的服务中，将V2版本故障修复后再进行测试。



7.删除V1版本的reviews服务


待V2版本上线稳定运行后，删除V1版本的reviews服务和测试规则。

kubectl delete pod reviews-v1-1360980140-0zs9z

istioctl delete -f route-rule-test-reviews-v2.yaml -n default


四、参考

  • Istio官方文档





推荐阅读

实用指南 | 基于Kubernetes, GRPC 和 Linkerd 构建可扩展微服务万字长文 | 如何构建安全的微服务应用，先要解决这两个问题实例 | 当Istio遇见Jaeger，如何解决端到端分布式追踪问题？


ServiceMesh中文社区：

ServiceMesh中文社区（servicemesh.cn）已上线，Istio、Conduit官方文档翻译版已在社区发布，欢迎大家登录浏览。社区翻译小组志愿者招募中，有兴趣的私信小数即可~


ServiceMesh微信交流群：


以上是关于采用Istio实现灰度发布，给运维人员一支强心剂的主要内容，如果未能解决你的问题，请参考以下文章

Istio 太复杂？KubeSphere基于Ingress-Nginx实现灰度发布

Istio，灰度发布从未如此轻松！！！

直播 | 基于Istio的灰度平台实践

Istio的设计目标——描述Istio设计坚持的核心原则

Istio在UAEK中的实践改造之路

基于Istio的灰度发布架构方案实践之路