云原生Istio：灰度发布介绍与实验

灰度发布介绍

灰度发布也叫金丝雀发布，是指通过控制流量的比例，实现新老版本的逐步更替。

比如对于服务 A 有 version1、 version2 两个版本，当前两个版本同时部署，但是 version1 比例 90% ，version2 比例 10% ，看运行效果，如果效果好逐步调整流量占比 80～20 ，70～30 ·····10～90 ，0，100 ，最终 version1 版本下线。

灰度发布的特点：

1）新老版本共存

2）可以实时根据反馈动态调整占比

3）理论上不存在服务完全宕机的情况。

4）适合于服务的平滑升级与动态更新。

我们选择使用开源项目进行灰度发布的实验，通过经典的 Weather Forecast 进行部署实践，它是一款查询城市天气信息的应用实例，一共包含4个微服务，它们之间的调用关系如下：

项目服务介绍：

frontend：前台服务，会调用 advertisement 和 forecast 这两个服务，展示整个应用的页面;

advertisement：广告服务，返回的静态的广告图片;

forecast：添加预报服务，返回相应城市的天气数据;

recommendation：推荐服务，根据天气情况向用户推荐穿衣和运行等信息。

其中，frontend 服务的有两个版本:

v1 版本的界面按钮为绿色。

v2 版本的界面按钮为蓝色。

forecast 服务有两个版本：

v1 版本会直接返回天气信息；

v2 版本会请求 recommendation 服务，获取推荐信息，并结合天气信息一起返回数据。

正式开始我们的实验。

灰度发布实验环境搭建

1.下载实验所需文件

确保kubernetes就能运行正常，Istio核心组件正常运行

首先我们需要拉取我们的开源项目源码包，源码包储存在Github上面，我们可以在虚拟机或云主机里使用Curl命令进行源码包的获取，也可以下载到本地机器上，使用FTP协议工具上传至虚拟机或云主机上，若虚拟机和云主机无法拉取或无法访问Github，可以采用端口代理的方式配置一个网络代理，拉取源码包；

bash 复制代码

wget https://github.com/slzcc/cloud-native-istio/archive/refs/heads/master.zip
yum -y install unzip
unzip master.zip

在成功拉取源码包之后，我们需要解压源码包，我们所需要的所有yaml文件都在install目录和chapter-files目录之下；

2.创建独立命名空间weather

在搭建基础环境之前，我们要先创建一个新的命名空间独立使用，创建weather命名空间，并且打上istio - injection = enabled标签，这相当于给这个命名空间下了一个 "指令"。我们前面有仔细讲到过打上标签的含义，我们在此不做过多的讲解。

bash 复制代码

[root@master cloud-native-istio-master]# kubectl create ns weather
namespace/weather created
[root@master cloud-native-istio-master]# kubectl label namespace weather istio-injection=enabled
namespace/weather labeled

3.搭建基础环境

部署weather的V1版本，该yaml文件储存在源码包的install目录下，我们直接执行即可。当我们部署完V1版本的weather后，我们要全部输weather的网关服务，网关服务的yaml文件也在install目录之下，直接执行即可。

bash 复制代码

[root@master cloud-native-istio-master]# kubectl apply -f install/weather-v1.yaml -n weather
[root@master cloud-native-istio-master]# kubectl apply -f install/weather-gateway.yaml

在我们成功部署完weatherV1和网关服务后，我们要检查这些服务的Pod是否正常启动，这些服务所需要的镜像是否都呗正确的拉取到了，如果出现网络问题无法拉取到镜像，我们可以手动拉取镜像，可以使用ctr命令或Docker命令拉取镜像，在上传至Pod服务部署的从节点上，等待镜像加载一段时间后重新查看服务的Pod；在我们成功部署成功这些服务之后，我们要查看服务暴露的端口，可以使用kubectl get svc 并且指定命名空间-n weather查看服务的暴露端口，从而去浏览器进行查看weather的UI界面。

在浏览器中访问，以供有三个城市的温度信息，有杭州，上海和北京，点击查询天气会给出具体V1版本提供的信息

核心资源介绍：

VirtualService：路由规则配置（虚拟服务），定义路由规则，可以将满足条件的流量都转发到对应的服务后端；

DestinationRule：目标规则配置，定义发生路由后应用于服务流量的策略，描述到达目标的请求怎么处理。

目标规则是配合虚拟服务来使用的，主要用来定义子集，子集实际上就是具体的目标地址，除此以外，它主要描述的是到达目标请求后如何去处理，所谓的目标就是子集，而如何处理就是指具体的策略。

在开始实验前，首先对每个服务都创建各自的 VirtualService 和 DestinationRule 资源，将访问请求路由到所有服务的 v1 版本，所需的yaml文件储存在install目录之下，我们直接执行即可。

搭建kiali

Kiali 是一个为 Istio 提供图形化界面和丰富观测功能的 Dashboard 的开源项目，其名称源于希腊语，意思是望远镜。用户利用 Kiali 可以监测网格内服务的实时工作状态，管理Istio的网络配置，快速识别网络问题。但是从Istio 1.7开始，默认不安装控制面板Kiali等组件，所以需要用户自行单独安装控制面板Kiali及相关的组件。

Kiali的yaml执行文件在Istio安装包的samples/addons切换到该目录下执行：

bash 复制代码

[root@master addons]# kubectl apply -f ./

查看kiali服务，发现其类型为ClusterIP，没有对外暴露端口，无法从外部访问：

所以此时需要通过NodePort的方式对外暴露控制面板，我们将原来的ClusterIP类型的service导出yaml文件，通过删除注解、创建信息、状态字段及ClusterIP等信息将类型改NodePort。

bash 复制代码

[root istio-1.17.0]# kubectl get svc -n istio-system kiali -o yaml > kiali-nodeport.yaml
[root istio-1.17.0]# vi kiali-nodeport.yaml
#主要删除metadata下的annotation, resourceVersion,seflFlink, uid; 以及spec下的ClusterIP,修改类型为NodePort， 同时删除status状态字段即可。
[root istio-1.17.0]# kubectl apply -f kiali-nodeport.yaml

访问即可

4.初始化服务部署

在开始实验前，首先对每个服务都创建各自的 VirtualService 和 DestinationRule 资源，将访问请求路由到所有服务的 v1 版本：

bash 复制代码

[root@master cloud-native-istio-master]# kubectl apply -f install/destination-rule-v1.yaml -n weather
destinationrule.networking.istio.io/frontend-dr unchanged
destinationrule.networking.istio.io/advertisement-dr created
destinationrule.networking.istio.io/forecast-dr created
[root@master cloud-native-istio-master]# kubectl apply -f install/virtual-service-v1.yaml -n weather
virtualservice.networking.istio.io/frontend-route configured
virtualservice.networking.istio.io/advertisement-route created
virtualservice.networking.istio.io/forecast-route created

在浏览器中多次加载前台页面，并查询城市的天气信息，确认显示正常。然后打开Kiali控制台，查看各个服务之间的调用关系，如下图所示：

至此，基础环境搭建完成。

灰度发布实验

1.基于流量比例的路由

场景：用户需要软件能够根据不同的天气情况推荐合适的穿衣和运动信息。于是开发工程师增加了 recommendation 新服务，并升级 forecast 服务到 v2 版本来调用 recommendation 服务。在新特性上线时，运维工程师首先部署 forecast 服务的 v2 版本和 recommendation 服务，并对 forecast 服务的 v2 版本进行灰度发布。

bash 复制代码

部署 recommendation 服务和 forecast 服务的 v2 版本。
[root@master cloud-native-istio-master]# kubectl apply -f install/recommendation-service/recommendation-all.yaml -f install/forecast-service/forecast-v2-deployment.yaml -n weather

service/recommendation created
deployment.apps/recommendation-v1 created
destinationrule.networking.istio.io/recommendation-dr created
virtualservice.networking.istio.io/recommendation-route created
deployment.apps/forecast-v2 created

更新 forecast 服务 v2 版本的 DestinationRule。
[root@master cloud-native-istio-master]#  kubectl apply -f install/forecast-service/forecast-v2-destination.yaml -n weather
destinationrule.networking.istio.io/forecast-dr configured

这时去浏览器中查询天气，显然还不会出现推荐信息，因为所有流量依然都被路由到 forecast 服务的 v1 版本，不会调用 recommendation 服务。

bash 复制代码

[root@master cloud-native-istio-master]# kubectl apply -f chapter-files/canary-release/vs-forecast-weight-based-50.yaml -n weather
virtualservice.networking.istio.io/forecast-route configured

在浏览器中查看配置后的效果。多次刷新查询天气页面，可以发现大概约 50% 的情况下不显示推荐服务，表示调用了 forecast 服务的 v1 版本；在另外 50% 的情况下表示推荐服务，调用了 forecast 服务的 v2 版本（刷新页面基本上是两个版本交替着来）。

此时查看kiali视图：

继续增加 forecast 服务的 v2 版本的流量比例，直到流量全部被路由到 v2 版本。

bash 复制代码

[root@master cloud-native-istio-master]# kubectl apply -f chapter-files/canary-release/vs-forecast-weight-based-v2.yaml -n weather
virtualservice.networking.istio.io/forecast-route configured

再次在浏览器中对此烦恼顾问后发现版本已经完全变更为v2版本了

保留 forecast 服务的老版本 v1 一段时间，再确认 v2 版本的各性能指标稳定后，删除老版本 v1 的所有资源，完成灰度发布此时发现V1版本不再被访问。

2.基于内容转发

在生产环境中同时上线了 forecast 服务的 v1 和 v2 版本，工程师期望让不同的终端用户访问不同的版本，例如：让使用 Chrome 浏览器的用户看到推荐信息，但让使用其他浏览器的用户看不到推荐信息。

有了上面场景的经验，只需要修改 forecast 服务 v2 版本的 DestinationRule中的 match 条件，使来自Chrome浏览器的请求路由到 v2 版本，其余的不变即可：

bash 复制代码

[root@master cloud-native-istio-master]# vi chapter-files/canary-release/vs-forecast-header-based.yaml
[root@master cloud-native-istio-master]# kubectl apply -f chapter-files/canary-release/vs-forecast-header-based.yaml
virtualservice.networking.istio.io/forecast-route configured

此时进入到谷歌浏览器和火狐浏览器分别访问：

在浏览器中查看配置后的效果：用 Chrome 浏览器多次查询天气信息，发现始终显示推荐信息，说明访问到 forecast 服务的 v2 版本；用 Firefox 浏览器多次查询天气信息，发现始终不显示推荐信息，说明访问到 forecast 服务的 v1 版本。

关于灰度发布的基本介绍和基础实验就讲到这里，感谢各位看官！债见！