干货分享｜使用 Istio 实现灰度发布

Kubernetes 作为基础渠道，供给了强壮的容器编列才干。可是在其上布置事务和服务办理上，依然会面对一些杂乱性和限制性。在服务办理上，已经有许多老练的 ServiceMesh 结构用于扩大其才干，如 Istio、Linkerd、Dapr 等。本文将首要介绍怎么运用 Istio 扩大 Kubernetes 灰度发布的才干。

而在布置上，则会运用开源项目 Rainbond 作为基础渠道来进行实践。Rainbond 是一个云原生运用办理渠道，它运用以运用为中心的规划形式。依据这一规划形式抽象出了标准化的运用模型。从运用的体会上不需求学习和编写YAML，即可完结事务运用的全生命周期办理。因而运用它简化事务的布置和办理。一起 Rainbond 支持 ServiceMesh 结构的替换，使咱们能够按需挑选与事务最匹配的 ServiceMesh 结构进行服务办理。

Kubernetes 中怎么完结灰度发布

当你在 Kubernetes 集群中布置事务时，能够运用 Kubernetes 原生供给的灰度发布的方法去上线事务。这种方法是经过在旧版别和新版别的服务之间，界说一个差异化的 Label，依据不同版别之间的公共 Label 负载流量到后端 Pod，终究完结依据 Pod 的副本数操控流量的百分比。

如下图所示：用户界说了两个 Deployment 方针，其间旧版别号为 frontend-stable，有3个副本。新版别为 frontend-canary，有1个副本。此刻界说了一个 Service 方针，运用它们之间公共的 Label 进行挑选。这就使得用户拜访 frontend 这个 Service 时，能以 3:1 的份额一起拜访到两个版别。而且还能够经过调整副本数持续操控流量份额，终究达到完好上线。

Kubernetes 默许的完结方法在简略的布置场景下很有效，可是在一些杂乱场景中，依然会有较大的限制，如：

1. 事务装备主动弹性后，会直接影响灰度发布的流量份额

2. 低百分比的流量操控占用资源高，如 1 % 的流量抵达新版别，则至少需求 100 个副本

3. 准确的流量分发操控，使拜访到新版别中的用户一直是同一批，而不是某个用户拜访时随机切换

Istio 灰度发布简述

因为 Kubernetes 供给的灰度发布方法的限制性，在一些杂乱场景下，咱们就需求运用 Istio 来完结更精密的灰度发布战略。在运用 Istio 进行灰度发布时，咱们需求了解两个重要概念：

1. Virtual services: 虚拟服务界说了恳求到服务的途径。能够包括一组路由规矩，使匹配到对应规矩的恳求能抵达指定方针。

2. Destination rules: 方针规矩能够办理抵达该方针的流量，如对服务后端所对应的实例池进行分组，再结合 Virtual services 界说的路由规矩，终究将流量转发到正确的实例上。

如下图所示，以 istio 官网供给的 Bookinfo 示例程序为例，给出了 virtual services 和 destination rules 的首要界说。其间 virtual services 首要分为两块，主机名和路由规矩。主机名是客户端向服务发送恳求时运用的一个或多个地址。当恳求抵达 virtual services 时，则会依据其界说的路由规矩匹配。图中就界说了邮箱以 gmail.com 结尾的用户流量只会抵达 v3 版别的实例上。而其他用户则以 1:9 的份额别离拜访到 v1 和 v2 版别的服务。这种方法完结了准确的流量分发操控。

当用户流量来到 reviews.demo.svc.cluster.local 这个 Service 上时，能够看到 destination rules 的规矩界说中依据 version 这个 label 界说了不同的实例集，完结了流量份额与副本数的解耦。不论 reviews-v1 有多少实例。始终只有 10% 的流量抵达 destination rules 的 v1 子集中。这就处理了事务副本数与流量份额的冲突问题，也使得资源运用愈加合理。

Istio 灰度发布在 Rainbond 上的实践

依据以上理解，咱们接下来以 BookInfo 为例来体会 Istio 的灰度发布。

1. 准备工作：

在开端之前，咱们需求提前装置好所需求的环境。

1. 装置 Rainbond

参阅 Rainbond 官方文档 快速装置，装置完结后能够经过对接 Helm 商铺一键装置 Istio 以及相应组件。

2. 装置 Istio 以及 Kiali

登录到 Rainbond 操控台后，先创立一个团队，团队英文名对应 Kubernetes 中的命名空间，Istio 默许装置的命名空间为 istio-system ，因而团队英文名填写istio-system，称号能够填写为 istio项目。接下来对接 Helm 商铺，经过 运用市场 -> 点击➕号 -> Helm 商铺 对接。商铺称号随意填写，地址填写 https://openchart.goodrain.com/goodrain/rainbond。商铺对接完结后，咱们即可点击装置 istio、kiali 等运用。详细可参阅 Istio 装置。

2. 布置 BookInfo 运用

在布置 BookInfo 之前，咱们需求在 Rainbond 中创立一个团队和运用，并将运用的办理形式切换为 Istio 办理形式。在 Rainbond 中运用办理形式切换是指能够无侵入地变更运用下组件间通信办理形式。

如下图所示，一个完好运用会包括多个微服务模块，而 ServiceMesh 结构则是对一切事务容器注入 Proxy，依据注入Proxy的差异能够支持多种类型的 ServiceMesh 完结，比方：Istio、Linkerd、Dapr，运用能够按需敞开 ServiceMesh 才干，或替换完结结构。为了让 BookInfo 这个运用运用到 Istio 的办理才干，所以需求切换到 Istio 办理形式。

1. 准备镜像

BookInfo 这个运用程序由 6 个微服务组成，它们之间的依靠如下图所示。其间 Productpage 这个服务供给了拜访页面，从 Details 这个服务中取得书本详细信息。从 Reviews 服务中取得书本点评。其间 Reviews-v2 和 Reviews-v3 会从 Ratings 这个服务中取得书本的评级信息。这六个微服务的镜像如下：

docker.io/istio/examples-bookinfo-productpage-v1:1.17.0
docker.io/istio/examples-bookinfo-details-v1:1.17.0
docker.io/istio/examples-bookinfo-reviews-v1:1.17.0
docker.io/istio/examples-bookinfo-reviews-v2:1.17.0
docker.io/istio/examples-bookinfo-reviews-v3:1.17.0
docker.io/istio/examples-bookinfo-ratings-v1:1.17.0

2. 布置组件

咱们在运用下，挑选增加组件 -> 指定镜像 -> 填写镜像地址 -> 新建组件 -> 承认创立，即可依次创立出这 5 个微服务对应的组件。

3. 生成可用的 Service

刚刚咱们仅完结了一切服务的布置，还未界说这些微服务的拜访战略。以 Productpage 为例，咱们经过点击拓扑图中 Productpage 这个组件，即可进入这个服务的办理页面。找到 端口 -> 增加端口 -> 端口号填写9080 -> 翻开对外服务 -> 点击生成的路由，即可拜访成功。 此刻会发现 Productpage 这个组件的页面还无法拉取到书本点评信息。这是因为它默许运用 details 和 reviews 这两个 Service 称号连接到它依靠的组件。此刻咱们布置的 Reviews-v1 等组件还没有正确的 Service 称号。因而还是进入组件办理页面，组件端口 -> 增加端口 -> 端口号填写9080 -> 修正运用别号 -> 内部域名填写为 reviews-v1 -> 翻开对内服务。details、reviews-v2、ratings 等组件都是如此，填写其对应的 Service 称号后，翻开对内服务即可。

最终在运用的 K8s 资源下，咱们还需求创立一个如下的 Service，用来在 Reviews 的三个版别之间负载流量。

apiVersion: v1
kind: Service
metadata:
  labels:
    app: reviews
    service: reviews
  name: reviews
spec:
  ports:
  - name: http
    port: 9080
    protocol: TCP
    targetPort: 9080
  selector:
    component: reviews # 需求在 Reviews 三个版别中，均增加 Kubernetes 属性，设置上该 Label，才干正确收效
  sessionAffinity: None
  type: ClusterIP

4. 编列依靠关系

完结以上操作后，拜访 Productpage 运用，能够看到书本谈论能正确在三个版别中切换了。此刻，能够在运用视图下，切换到编列形式，依据上述 BookInfo 运用的架构图进行连线，完结拓扑图的编列。如下图所示，这样编列的好处是后期能够将这个运用全体发布出去，其他用户直接装置下来即可得到相同的拓扑关系，再也不用担心找不到各个服务依靠的组件。

3. 灰度发布

在完结以上布置操作后，咱们得到了一个完好的 BookInfo 程序，但此刻还未界说 Istio 相关装备，所以还需求经过 Kiali 去界说流量规矩。完结灰度发布。

1. 装备路由规矩

拜访 Kiali 办理页面，即可看到该运用。在左侧边栏挑选 Services，找到 reviews 这个 Service，点击进入，右上角 Actions 挑选 Traffic Shifting，即可看到如下装备：拖动滑块挑选流量份额。下图中 30% 的流量将会拜访到 reviews-v1 上，70% 的流量拜访到 reviews-v2上。点击创立后，即可看见页面左下角，Kiali 主动为你生成了 virtual services 和 destination rules 资源。你能够点击进去依据自己需求再次编辑。

2. 验证路由规矩是否收效

找到最开端布置的组件 Productpage，进入组件办理页面，点击右上角拜访入口，能够看到书本概况和评级，重复刷新页面，能够看到不带星级的点评信息(reviews-v1)与黑色星级点评信息(reviews-v2)呈现的份额大概是 3:7。红色星级点评信息(reviews-v3)从未呈现。

3. 验证组件扩容对流量的影响

找到布置的组件 reviews-v1 ，进入组件办理页面 -> 弹性 -> 实例数量设置为4，此刻再次拜访 Productpage 页面，重复刷新页面，能够看到 reviews-v1 扩容后，拜访到 reviews-v1 与 reviews-v2 的份额仍为 3:7，组件实例数的多少对流量分发战略没有影响。