3

如何在Service Mesh微服务架构中实现金丝雀发布？

 2 years ago
source link: http://dockone.io/article/2434645
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

今天的文章聊聊有关Service Mesh微服务架构的话题，如果对之前的聊过的话题还不了解，可以参考文末的推荐阅读。本文主要讲的话题是：如何在Service Mesh微服务架构中实现“金丝雀发布”？

什么是金丝雀发布

既然要聊具体的实现，那么在开始之前，先科普下什么是“金丝雀发布”。金丝雀发布也叫“灰度发布”，具体来说就是在发布线上版本时，先将少量的生产流量打到服务的新版本，以验证新版本的准确性和可靠性，待发布的新版本得到线上流量的全面验证后，在逐步将所有流量放入新版本，以实现生产服务版本的稳定更新。

为什么叫金丝雀发布呢，是因为金丝雀对矿场中的毒气比较敏感，所以在矿场开工前工人们会放一只金丝雀进去，以验证矿场是否存在毒气，这便是金丝雀发布名称的由来。

在不同技术栈场景中，金丝雀发布的实现方式也不尽相同：有通过nginx实现的、也有借助A/B测试实现的。而随着以Kubernetes为代表的云原生基础设施的普及，金丝雀发布作为一项基本的服务发布功能，其实现方式也有了一些新的趋势——那就是逐步与云原生基础设施融为一体，成为基础设施服务的一部分。

Kubernetes中的金丝雀（灰度）发布

接下来，先看看在Kubernetes中是如何实现版本更新的。以下内容假设你已经有了一套可用的Kubernetes环境，如果没有可以查看文末推荐阅读的文章链接，参考相关分享自行部署。
在介绍Kubernetes中的金丝雀（灰度）发布之前，先来了解下Kubernetes中最重要的应用部署方式——“滚动升级”。

所谓“滚动升级”：是指当更新了Kubernetes中Deployment编排资源的Pod模版（例如更新镜像版本号）之后，Deployment就需要遵循一种叫做“滚动更新（rolling update）”的方式，来升级现有的容器，从而实现应用对外服务的“不中断更新部署”。Kubernetes实现“滚动升级”的示意图如下：

如上图所示，滚动升级的过程为：
  1. 当容器开始升级时，集群中会先启动一个新版本的Pod，并终止一个旧版本的Pod。
  2. 如果此时，新版本的Pod有问题启动不了，那么“滚动升级”就会停止，并允许开发和运维人员介入。而在这个过程中，由于应用本身还有两个旧版本的Pod在线，所以服务并不会受到太大的影响。
  3. 而如果新版本的Pod启动成功，且服务访问正常，则继续滚动升级，直至按照Deployment编排器设置的副本数量，完成后续旧版本Pod的升级。
在Kubernetes中Deployment还可以通过相应地“滚动升级”策略，来控制Pod的滚动升级行为，以进一步保证服务的连续性。例如：“在任何时间窗口内，只有指定比例的Pod处于离线状态；在任何时间窗口内，只有指定比例的新Pod被创建出来”。可以通过相应地控制参数进行设置，如下：
...

spec:

selector:

matchLabels:

  app: micro-api

replicas: 3

#设置滚动升级策略

#Kubernetes在等待设置的时间后才开始进行升级，例如5秒

minReadySeconds: 5

strategy:

type: RollingUpdate

rollingUpdate:

  #升级过程中最多可以比原先设置多出的Pod数量

  maxSurge: 1

  #升级过程中Deployment控制器最多可以删除多少个旧Pod，主要用于提供缓冲时间

  maxUnavailable: 1

...

在上面RollingUpdate Strategy（滚动升级策略）的配置中：
  • maxSurge：指定的是，除了设定的Pod副本数量之外，在一次“滚动”中，Deployment控制器还可以创建多少个新的Pod。
  • maxUnavailable：指的是，在一次“滚动”中，Deployment控制器可以删除多少个旧Pod。

通过这种精确的“滚动升级”策略，可以使得Kubernetes服务版本发布的过程更加平滑。此外，这两个配置还可以通过百分比的方式来表示，比如“maxUnavailable=50%”，指的是Deployment控制器最多可以一次删除“50%*设定Pod副本数”个Pod。

接下来具体演示下在Kubernetes中进行服务滚动升级的详细过程。

该项目以Spring Boot编写的Java服务为主，在体验上更接近真实的项目开发场景。项目的结构如下：


该项目所在的GitHub地址为：https://github.com/manongwudi/ ... -demo

“滚动升级”演示：

这里先借助示例项目中的“micro-api”服务来演示其在Kubernetes中进行“滚动升级”的过程，步骤如下：

1、首先准备“micro-api”服务的k8s发布文件（如：micro-api.yaml）。代码如下：
apiVersion: v1

kind: Service

metadata:

name: micro-api

spec:

type: ClusterIP

ports:

- name: http

  port: 19090

  targetPort: 9090

selector:

app: micro-api

---

apiVersion: apps/v1

kind: Deployment

metadata:

name: micro-api

spec:

selector:

matchLabels:

  app: micro-api

replicas: 3

#设置滚动升级策略

#Kubernetes在等待设置的时间后才开始进行升级，例如5秒

minReadySeconds: 5

strategy:

type: RollingUpdate

rollingUpdate:

  #升级过程中最多可以比原先设置多出的Pod数量

  maxSurge: 1

  #升级过程中Deployment控制器最多可以删除多少个旧Pod

  maxUnavailable: 1

template:

metadata:

  labels:

    app: micro-api

spec:

  #设置的阿里云私有镜像仓库登陆信息的secret（对应2.1.2的设置）

  imagePullSecrets:

    - name: regcred

  containers:

    - name: micro-api

      image: registry.cn-hangzhou.aliyuncs.com/wudimanong/micro-api:1.0-SNAPSHOT

      imagePullPolicy: Always

      tty: true

      ports:

        - name: http

          protocol: TCP

          containerPort: 19090

上述部署文件设置了“micro-api”服务的Pod副本个数为“3”，并且设置了相应地滚动升级策略。

2、接下来执行Kubernetes部署命令，如下：
$ kubectl apply -f micro-api.yaml

成功后，查看Deployment创建后的状态信息，命令效果如下：
$ kubectl get deployments

NAME          READY   UP-TO-DATE   AVAILABLE   AGE

micro-api     3/3     3            3           190d

从上述命令的返回结果中，可以看到三个状态字段，它们的含义如下所示：
  • READY：表示用户期望的Pod副本个数，以及当前处于Running状态的Pod个数。
  • UP-TO-DATE：当前处于最新版本的Pod个数。所谓最新版本，指的是Pod的Spec部分与Deployment中Pod模版里定义的完全一致。
  • AVAILABLE：当前已经可用的Pod的个数——既是Running状态，又是最新版本，并且已经处于Ready（监控检查正确）状态的Pod个数。
3、模拟服务版本升级，触发滚动升级。

接下来重新构建“micro-api”服务的版本，并将其上传至私有镜像仓库。之后，通过命令修改“micro-api”的Deployment所使用的镜像，并触发滚动升级。

修改Deployment所使用的镜像的命令如下：
$ kubectl set image deployment/micro-api micro-api=registry.cn-hangzhou.aliyuncs.com/wudimanong/micro-api:1.1-SNAPSHOT

deployment.apps/micro-api image updated

这里使用了“kubectl set image”指令，主要是为了方便操作，也可以直接在Kubernetes部署文件中进行镜像版本的修改。

修改完Deployment的镜像版本后，Kubernetes会立即触发“滚动升级”的过程。可以通过“kubectl rollout status”指令来查看Deployment资源的状态变化。具体如下：
$ kubectl rollout status deployment/micro-api

Waiting for deployment "micro-api" rollout to finish: 2 out of 3 new replicas have been updated...

Waiting for deployment "micro-api" rollout to finish: 2 out of 3 new replicas have been updated...

Waiting for deployment "micro-api" rollout to finish: 2 out of 3 new replicas have been updated...

Waiting for deployment "micro-api" rollout to finish: 2 of 3 updated replicas are available...

Waiting for deployment "micro-api" rollout to finish: 2 of 3 updated replicas are available...

deployment "micro-api" successfully rolled out

这时，也可以通过查看Deployment的Events，看到这个“滚动升级”的过程。具体如下：
$ kubectl describe deployment micro-api

...

OldReplicaSets:  <none>

NewReplicaSet:   micro-api-d745d8649 (3/3 replicas created)

Events:

Type    Reason             Age   From                   Message

----    ------             ----  ----                   -------

Normal  ScalingReplicaSet  12m   deployment-controller  Scaled up replica set micro-api-677dd4d5b6 to 1

Normal  ScalingReplicaSet  12m   deployment-controller  Scaled down replica set micro-api-57c7cb5b74 to 2

Normal  ScalingReplicaSet  12m   deployment-controller  Scaled up replica set micro-api-677dd4d5b6 to 2

Normal  ScalingReplicaSet  5m1s  deployment-controller  Scaled down replica set micro-api-677dd4d5b6 to 0

Normal  ScalingReplicaSet  5m    deployment-controller  Scaled up replica set micro-api-d745d8649 to 2

Normal  ScalingReplicaSet  56s   deployment-controller  Scaled down replica set micro-api-57c7cb5b74 to 0

Normal  ScalingReplicaSet  56s   deployment-controller  Scaled up replica set micro-api-d745d8649 to 3

可以看到，当你修改了Deployment里的Pod定义后，“Deployment Controller”会使用这个修改后的Pod模版，创建一个新的ReplicaSet，这个新的ReplicaSet的初始Pod副本数是：0。

然后在Age=12 m的位置，开始将这个新的ReplicaSet所控制的Pod副本数从0个变成1个。

紧接着，在Age=12 m的位置，又将旧ReplicaSet所控制的Pod副本数减少1个，即“水平收缩”成两个副本。

如此交替进行，新ReplicaSet所管理的Pod的副本数，从0个变成1个，再变成2个，最后变成3个；而旧ReplicaSet所管理的Pod的副本数则从3个变成2个，最后变成0个。

这样，就完成了一组Pod的版本升级过程。而像这样将一个Kubernetes集群中正在运行的多个Pod版本，交替逐一升级的过程，就是“滚动升级”。

金丝雀（灰度）发布

上面内容比较详细的演示了Kubernetes的“滚动升级”的方式，虽然通过滚动升级的方式可以方便、平滑的实现版本更新，但是这个过程，并没有灰度功能。滚动升级的方式，虽然中间有缓冲交替的过程，但这种过程是自动的、迅速的，滚动升级过程结束就相当于直接进行了新版本的全量发布。

而对于需要进行金丝雀（灰度）发布的场景，“滚动升级”的方式很显然是不够用的。那么，在Kubernetes中应该如何结合版本更新做到金丝雀（灰度）发布呢？

具体步骤如下：

1、编写实现新版本灰度发布的部署文件。

为了实现在Kubernetes中的金丝雀（灰度）发布过程的可观测，我们重新定义下具体的Kubernetes发布文件（如：micro-api-canary.yaml）的内容如下：
...

spec:

selector:

matchLabels:

  app: micro-api

replicas: 3

#设置滚动升级策略

#Kubernetes在等待设置的时间后才开始进行升级，例如5秒

minReadySeconds: 5

strategy:

type: RollingUpdate

rollingUpdate:

  #升级过程中最多可以比原先设置多出的Pod数量

  maxSurge: 1

  #升级过程中Deployment控制器最多可以删除多少个旧Pod，主要用于提供缓冲时间

  maxUnavailable: 1

...

上述发布文件与上一小节中演示滚动升级时，发布文件的内容一致，只是为了方便观察灰度发布过程的实现，这里通过“track: canary”对新发布的Pod版本进行标记。

设置新版本的镜像为：“micro-api:1.3-SNAPSHOT”。并且通过“spec.selector.matchLabels.app:micro-api”与历史版本Pod所对应的Service（micro-api.yaml文件中定义的Service）资源定义匹配。

2、执行“滚动升级”发布命令，实现“灰度发布”效果。
$ kubectl apply -f micro-api-canary.yaml && kubectl rollout pause deployment/micro-api

上面通过“kubectl rollout pause”命令实现对Deployment的金丝雀（灰度发布）。执行发布命令之后的运行效果如下：
$ kubectl get pods --show-labels -o wide

NAME                         READY   STATUS    RESTARTS   AGE     IP          NODE         NOMINATED NODE   READINESS GATES   LABELS

micro-api-57c7cb5b74-mq7m9   1/1     Running   0          6m20s   10.32.0.3   kubernetes   <none>           <none>            app=micro-api,pod-template-hash=57c7cb5b74

micro-api-57c7cb5b74-ptptj   1/1     Running   0          6m20s   10.32.0.4   kubernetes   <none>           <none>            app=micro-api,pod-template-hash=57c7cb5b74

micro-api-7dbb6c5d66-4rbdc   1/1     Running   0          5m33s   10.32.0.6   kubernetes   <none>           <none>            app=micro-api,pod-template-hash=7dbb6c5d66,track=canary

micro-api-7dbb6c5d66-cfk9l   1/1     Running   0          5m33s   10.32.0.5   kubernetes   <none>           <none>            app=micro-api,pod-template-hash=7dbb6c5d66,track=canary

查看Deployment的滚动升级情况，命令如下：
$ kubectl get deployments

NAME            READY   UP-TO-DATE   AVAILABLE   AGE

micro-api       4/3     2            4           194d

可以看到此时“micro-api” ready的数量为4，其中两个旧版本Pod，两个新版本Pod。

3、接下来进行流量测试。

查询两组Pod版本所对应的Service资源的IP，命令如下：
# kubectl get svc micro-api

NAME        TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)     AGE

micro-api   ClusterIP   10.110.169.161   <none>        19090/TCP   194d

接下来，模拟对服务的接口进行批量访问，命令如下：
$ for i in {1..10}; do curl 10.110.169.161:19090/test/test; done

{"code":0,"data":"V3|无依赖测试接口返回->OK!","message":"成功"}

{"code":0,"data":"V3|无依赖测试接口返回->OK!","message":"成功"}

{"code":0,"data":"无依赖测试接口返回->OK!","message":"成功"}

{"code":0,"data":"无依赖测试接口返回->OK!","message":"成功"}

{"code":0,"data":"V3|无依赖测试接口返回->OK!","message":"成功"}

{"code":0,"data":"V3|无依赖测试接口返回->OK!","message":"成功"}

{"code":0,"data":"无依赖测试接口返回->OK!","message":"成功"}

{"code":0,"data":"无依赖测试接口返回->OK!","message":"成功"}

{"code":0,"data":"V3|无依赖测试接口返回->OK!","message":"成功"}

{"code":0,"data":"V3|无依赖测试接口返回->OK!","message":"成功"} 

可以看到，此时流量会随机的流向旧版本和新版本（日志标记为V3）的服务。

4、将服务版本升级为新版本。

如果新版本的服务经过线上流量测试验证没有问题，则可以通过“rollout resume”命令将整体服务的版本升级为新版本。命令如下：
$ kubectl rollout resume deployment micro-api

deployment.apps/micro-api resumed

升级后的效果如下：
$ kubectl get pods --show-labels -o wide

NAME                         READY   STATUS    RESTARTS   AGE   IP          NODE         NOMINATED NODE   READINESS GATES   LABELS

micro-api-7dbb6c5d66-4rbdc   1/1     Running   0          18m   10.32.0.6   kubernetes   <none>           <none>            app=micro-api,pod-template-hash=7dbb6c5d66,track=canary

micro-api-7dbb6c5d66-bpjtg   1/1     Running   0          84s   10.32.0.3   kubernetes   <none>           <none>            app=micro-api,pod-template-hash=7dbb6c5d66,track=canary

micro-api-7dbb6c5d66-cfk9l   1/1     Running   0          18m   10.32.0.5   kubernetes   <none>           <none>            app=micro-api,pod-template-hash=7dbb6c5d66,track=canary

可以看到，此时目标服务已经通过“滚动升级”的方式完成了全量更新。而如果存在问题，则通过“kubectl rollout undo”命令进行回滚即可！

从上述过程可以看到，Kubernetes中的金丝雀（灰度发布）主要是通过操纵（如：pause）“滚动升级”的过程来实现的——通过发布一定数量的新版本Pod，并利用Service资源类型本身的负载均衡能力来实现流量在新/旧Pod之间的随机交替。

这样的方式虽然已经可以满足一些简单的场景，但是没有办法做到更精准的灰度流量控制。这时候就需要借助 Service Mesh 中的解决方案了，下面我们来看看在 Istio 中如何做到精准流量的金丝雀（灰度）发布。

Istio中的金丝雀（灰度）发布

以下内容默认你已经在Kubernetes中安装了Istio环境，如果还没有安装可以参考《干货|如何步入Service Mesh微服务架构时代》中分享的内容。

Istio与Kubernetes实现金丝雀（灰度）发布的方式不一样，Istio通过Envoy（SideCar）强大的路由规则管理能力，可以非常灵活地控制对应版本的流量占比，从而实现具备精准流量控制能力的金丝雀（灰度）发布功能。

Istio通过Envoy（SideCar）实现金丝雀（灰度）发布的流量路由示意图如下（继续以“micro-api”服务为例）：

从上图中可以大致看出，Istio具备强大的流量管理能力，而这种能力对于实现流量精准控制的金丝雀（灰度）发布功能来说，自然是水到渠成的。

具体来说，在Istio中是通过VirtualService（虚拟服务）这种特定的资源在服务网格中实现流量路由的。通过VirtualService可以方便地定义流量路由规则，并在客户端试图连接到服务时应用这些规则，并最终到达目标服务。

接下来，具体演示如何在Istio中通过VirtualService实现金丝雀（灰度）发布。步骤如下：

1、首先发布一个v1版本的服务。

要在Istio中实现更精准的版本控制，需要在发布Pod资源时，通过明确的“版本标签”进行指定。准备“micro-api”服务v1版本的Kubernetes部署文件（micro-api-canary-istio-v1.yaml）：
apiVersion: v1

kind: Service

metadata:

name: micro-api

spec:

type: ClusterIP

ports:

- name: http

  port: 19090

  targetPort: 9090

selector:

app: micro-api

---

apiVersion: apps/v1

kind: Deployment

meta data:

name: micro-api-v1

spec:

selector:

matchLabels:

  app: micro-api

  #这里是关键，需要设置版本标签，以便实现灰度发布

  version: v1

replicas: 3

#设置滚动升级策略

#Kubernetes在等待设置的时间后才开始进行升级，例如5秒

minReadySeconds: 5

strategy:

type: RollingUpdate

rollingUpdate:

  #升级过程中最多可以比原先设置多出的Pod数量

  maxSurge: 1

  #升级过程中Deployment控制器最多可以删除多少个旧Pod，主要用于提供缓冲时间

  maxUnavailable: 1

template:

metadata:

  labels:

    app: micro-api

    #设置版本标签，便于灰度发布

    version: v1

spec:

  #设置的阿里云私有镜像仓库登陆信息的secret

  imagePullSecrets:

    - name: regcred

  containers:

    - name: micro-api

      image: registry.cn-hangzhou.aliyuncs.com/wudimanong/micro-api:1.1-SNAPSHOT

      imagePullPolicy: Always

      tty: true

      ports:

        - name: http

          protocol: TCP

          containerPort: 19090

“spec.selector.matchLabels.version:v1”标签用来标注服务的版本，该标签是后续Istio的流量管理规则中，识别服务版本的主要依据。

准备好发布文件后，执行发布命令：
$ kubectl apply -f micro-api-canary-istio-v1.yaml

此时，一个低版本的服务就运行成功了！接下来我们模拟对其实施金丝雀（灰度）发布。

2、发布一个v2版本的服务（升级的目标版本）。

与v1版本服务一样，发布的v2版本的服务也需要明确版本标签，其发布文件（micro-api-canary-istio-v2.yaml）的内容如下：
apiVersion: apps/v1

kind: Deployment

metadata:

name: micro-api-v2

spec:

selector:

matchLabels:

  app: micro-api

  #设置好版本标签，便于灰度发布

  version: v2

replicas: 3

#设置滚动升级策略

#Kubernetes在等待设置的时间后才开始进行升级，例如5秒

minReadySeconds: 5

strategy:

type: RollingUpdate

rollingUpdate:

  #升级过程中最多可以比原先设置多出的Pod数量

  maxSurge: 1

  #升级过程中Deployment控制器最多可以删除多少个旧Pod，主要用于提供缓冲时间

  maxUnavailable: 1

template:

metadata:

  labels:

    app: micro-api

    #设置好版本标签，便于灰度发布

    version: v2

spec:

  #设置的阿里云私有镜像仓库登陆信息的secret

  imagePullSecrets:

    - name: regcred

  containers:

    - name: micro-api

      image: registry.cn-hangzhou.aliyuncs.com/wudimanong/micro-api:1.3-SNAPSHOT

      imagePullPolicy: Always

      tty: true

      ports:

        - name: http

          protocol: TCP

          containerPort: 19090

执行发布命令：
$ kubectl apply -f micro-api-canary-istio-v2.yaml 

deployment.apps/micro-api-v2 created

此时，系统中就存在了两组版本的Pod资源，具体如下：
# kubectl get pods

NAME                            READY   STATUS    RESTARTS   AGE

micro-api-v1-565d749dd4-7c66z   1/1     Running   2          13h

micro-api-v1-565d749dd4-7dqfb   1/1     Running   2          13h

micro-api-v1-565d749dd4-l62wc   1/1     Running   2          13h

micro-api-v2-6f98c598c9-5stlw   1/1     Running   0          82s

micro-api-v2-6f98c598c9-f2ntq   1/1     Running   0          82s

micro-api-v2-6f98c598c9-l8g4j   1/1     Running   0          82s

接下来将演示如何利用Istio强大的流量管理功能，来实现流量在这两组版本Pod资源之间的精确控制！

3、创建Istio网关资源。

在Istio中要实现流量的精确控制，需要将VirtualService绑定到具体的Ingressgateway（入口网关）资源。因此在创建VirtualService资源实现流量路由及控制前，需要创建一个Istio网关。部署文件（micro-gateway.yaml）的内容如下：
apiVersion: networking.istio.io/v1alpha3

kind: Gateway

metadata:

name: micro-gateway

spec:

selector:

istio: ingressgateway

servers:

- port:

    number: 80

    name: http

    protocol: HTTP

  hosts:

    - "*"

上述部署文件执行后将创建一个名称为“micro-gateway”的Istio网关，并允许所有主机（hosts:"*"指定）通过该网关。

4、创建Istio虚拟服务资源VirtualService。

前面提到过在Istio中主要是通过VirtualService（虚拟服务）来实现服务网格内的流量路由及控制。接下来我们看看VirtualService资源的具体创建方式，准备资源文件（如virtual-service-all.yaml），内容如下：
apiVersion: networking.istio.io/v1alpha3

kind: VirtualService

metadata:

name: micro-api-route

spec:

#用于定义流量被发送到的目标主机（这里为部署在Kubernetes中的micro-api服务）

hosts:

- micro-api.default.svc.cluster.local

#将VirtualService绑定到Istio网关，通过网关来暴露路由目标

gateways:

- micro-gateway

http:

- route:

    #设置旧版本（V1）版本的流量占比为70%

    - destination:

        host: micro-api.default.svc.cluster.local

        subset: v1

      #通过权重值来设置流量占比

      weight: 70

    #设置新版本（V2）版本的流量占比为30%

    - destination:

        host: micro-api.default.svc.cluster.local

        subset: v2

      weight: 30

如上所示，VirtualService资源具备针对http的精准流量控制能力，可以将指定占比的流量路由到特定的“subset”指定的版本。而为了实现这一能力，VirtualService资源还需要与Istio网关绑定，通过Istio网关来暴露路由目标。

5、创建Istio目标路由规则资源。

虚拟服务VirtualService在Istio中主要用于控制流量的行为，而定义流量行为的路由规则则需要通过“DestinationRule”路由规则资源来定义。创建路由规则文件（destination-rule-all.yaml），具体内容如下：
apiVersion: networking.istio.io/v1alpha3

kind: DestinationRule

metadata:

name: micro-api-destination

spec:

#与Deployment资源对应的Service资源名称关联

host: micro-api

#流量策略设置：负载均衡策略、连接池大小、局部异常检测等，在路由发生后作用于流量

trafficPolicy:

#限流策略

connectionPool:

  tcp:

    maxConnections: 10

  http:

    http1MaxPendingRequests: 1

    maxRequestsPerConnection: 1

#设置目的地的负债均衡算法

loadBalancer:

  simple: ROUND_ROBIN

#目的地指的是不同的子集（subset）或服务版本。通子集（subset），可以识别应用程序的不同版本，以实现流量在不同服务版本之间的切换

subsets:

- name: v1

  labels:

    version: v1

- name: v2

  labels:

    version: v2

如上所示，通过subsets属性，定义了VirtualService资源用于路由的具体版本标签匹配信息。至此，针对两个版本服务的灰度流量控制规则就设置好了，接下来测试具体的金丝雀（灰度）发布效果。

6、测试Istio实现金丝雀（灰度）发布的流量控制效果。

在正式测试之前，可以通过命令查看下当前的部署资源情况：
#查看部署的Deployment资源

kubectl get deploy  | grep micro-api

micro-api-v1             3/3     3            3           21h

micro-api-v2             3/3     3            3           8h
#查看两组版本Pod资源对应的K8s-Service的服务IP

kubectl get svc micro-api

NAME        TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)     AGE

micro-api   ClusterIP   10.110.169.161   <none>        19090/TCP   205d
#查看VirtualService资源定义

kubectl get vs

NAME              GATEWAYS          HOSTS                                   AGE

micro-api-route   [micro-gateway]   [micro-api.default.svc.cluster.local]   7h34m
#查看定义的路由规则资源

kubectl get dr

NAME                    HOST        AGE

micro-api-destination   micro-api   7h27m

通过上面的资源信息查看，这里我们已经可以查到Deployments对应的K8s-Service资源的IP，但如果通过K8s-Service资源来进行测试的话，会发现流量的控制并不精准，并不能达到我们设置的70%流量流向v1，30%的流量流向v2（因为这是随机流量）。

因此，要使用Istio的精准流量控制功能，还需要使用Istio的Ingressgateway。查看Istio的Ingressgateway资源IP的命令如下：
#查看ingress的IP

kubectl get svc -n istio-system | grep ingress

istio-ingressgateway   LoadBalancer   10.98.178.61     <pending>     15021:31310/TCP,80:32113/TCP,443:31647/TCP,31400:30745/TCP,15443:30884/TCP   7h54m

接下来，通过Ingress的IP来访问“micro-api”服务，命令及效果如下：
# for i in {1..10}; do curl -H "Host:micro-api.default.svc.cluster.local" 10.98.178.61:80/test/test; done

{"code":0,"data":"V3|无依赖测试接口返回->OK!","message":"成功"}

{"code":0,"data":"无依赖测试接口返回->OK!","message":"成功"}

{"code":0,"data":"无依赖测试接口返回->OK!","message":"成功"}

{"code":0,"data":"无依赖测试接口返回->OK!","message":"成功"}

{"code":0,"data":"无依赖测试接口返回->OK!","message":"成功"}

{"code":0,"data":"无依赖测试接口返回->OK!","message":"成功"}

{"code":0,"data":"无依赖测试接口返回->OK!","message":"成功"}

{"code":0,"data":"无依赖测试接口返回->OK!","message":"成功"}

{"code":0,"data":"V3|无依赖测试接口返回->OK!","message":"成功"}

{"code":0,"data":"V3|无依赖测试接口返回->OK!","message":"成功"} 

如上所示，流量按照设定的比例（v1:70%;v2:30%）进行了分流。

7、测试将流量全部切向新版本。

为了更明显地验证Istio的流量控制效果，接下来，我们通过变更VirtualService资源的流量设置占比，将流量全部切到新版本。变更后的VirtualService资源的配置文件内容如下：
apiVersion: networking.istio.io/v1alpha3

kind: VirtualService

metadata:

name: micro-api-route

spec:

#用于定义流量被发送到的目标主机（这里为部署在Kubernetes中的micro-api服务）

hosts:

- micro-api.default.svc.cluster.local

#将VirtualService绑定到Istio网关，通过网关来暴露路由目标

gateways:

- micro-gateway

http:

- route:

    #设置旧版本（V1）版本的流量占比为70%

    - destination:

        host: micro-api.default.svc.cluster.local

        subset: v1

      #通过权重值来设置流量占比

      weight: 0

    #设置新版本（V2）版本的流量占比为30%

    - destination:

        host: micro-api.default.svc.cluster.local

        subset: v2

      weight: 100

继续通过Istio网关访问目标服务，命令如下：
# for i in {1..10}; do curl -H "Host:micro-api.default.svc.cluster.local" 10.98.178.61:80/test/test; done

{"code":0,"data":"V3|无依赖测试接口返回->OK!","message":"成功"}

{"code":0,"data":"V3|无依赖测试接口返回->OK!","message":"成功"}

{"code":0,"data":"V3|无依赖测试接口返回->OK!","message":"成功"}

{"code":0,"data":"V3|无依赖测试接口返回->OK!","message":"成功"}

{"code":0,"data":"V3|无依赖测试接口返回->OK!","message":"成功"}

{"code":0,"data":"V3|无依赖测试接口返回->OK!","message":"成功"}

{"code":0,"data":"V3|无依赖测试接口返回->OK!","message":"成功"}

{"code":0,"data":"V3|无依赖测试接口返回->OK!","message":"成功"}

{"code":0,"data":"V3|无依赖测试接口返回->OK!","message":"成功"}

{"code":0,"data":"V3|无依赖测试接口返回->OK!","message":"成功"} 

可以观察到，此时流量已经全部切换到了新版本服务！

在微服务时代，不同的服务之间相互联系，关系错综复杂，部署升级一个服务，可能造成整个系统的瘫痪，因此，需要选择合适的部署方式，从而将风险降到最低。金丝雀（灰度）发布只是多种部署方式的一种，还有蓝绿部署、滚动部署（如K8s的滚动升级）等，可以根据不同的业务场景选择不同的发布形式。

原文链接：https://mp.weixin.qq.com/s/a8OLm7udd0T0PY2TskZELw

report

Recommend

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK