关于kubernetes:干货分享｜使用-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，组件实例数的多少对流量散发策略没有影响。