Istio入门体验系列——基于Istio的灰度发布实践


导言:灰度发布是指在项目迭代的过程中用平滑过渡的方式进行发布。灰度发布可以保证整体系统的稳定性,在初始发布的时候就可以发现、调整问题,以保证其影响度。作为Istio体验系列的第一站,本文基于Istio的流量治理机制,针对最简单的几种业务场景进行了实践,为后续的探索学习提供了一个思路和实践案例。

文章目录

  • 一、背景介绍
  • 1.1 灰度发布概述
  • 1.2 基于kubernetes的灰度发布
  • 1.3 基于Istio的灰度发布
  • 二、前置条件
  • 2.1 实验环境搭建
  • 2.2 服务网格监控组件的安装与配置
  • 2.2.1 Kiali的安装
  • 2.2.2 配置Kiali控制面板对外访问
  • 2.3 实验项目部署
  • 2.3.1 项目简介
  • 2.3.2 Weather Forecast 部署
  • 三、实验过程
  • 3.1 初始状态部署
  • 3.2 基于流量比例的路由
  • 3.3 基于请求内容的发布
  • 3.4 多服务同时发布
  • 3.5 自动化部署
  • 四、总结

一、背景介绍

1.1 灰度发布概述

在新版本上线时,不管是在技术上考虑产品的稳定性等因素,还是在商业上考虑新版本被用户接受的程度,直接将老版本全部升级是非常有风险的。所以一般的做法是,新老版本同时在线,新版本只切分少量流量出来,在确认新版本没有问题后,再逐步加大流量比例。这正是灰度发布要解决的问题。其核心是能配置一定的流量策略,将用户在同一个访问入口的流量导到不同的版本上。有如下几种典型场景。

  • 蓝绿发布

蓝绿发布是指不停止老版本,部署新版本,然后进行测试,确认没有问题之后,再将流量全量切到新版本,然后老版本同时也升级到新版本。这样做的好处是无需停机,并且风险较小。

20210219221322136.jpg_x-oss-process_image_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTc2MjE3Mw_size_16_color_FFFFFF_t_70_pic_center

其发布的步骤大致如下:

  1. 部署版本1的应用(一开始的状态),所有外部请求的流量都打到这个版本上;
  2. 部署版本2的应用,版本2的代码与版本1不同(新功能、Bug修复等);
  3. 将流量从版本1切换到版本2,即流量从v1:v2为100:0,切换为0:100;
  4. 如果版本2存在问题,需要回滚到版本1,进行流量切换回v1:v2为100:0。

    • A/B测试
      A/B测试的场景比较明确,就是同时在线上部署A和B两个对等的版本来接收流量,按一定的目标选取策略让一部分用户使用A版本,让一部分用户使用B版本,收集这两部分用户的使用反馈,即对用户采样后做相关比较,通过分析数据来最终决定采用哪个版本。蓝绿发布则主要用于安全稳定地发布新版本应用,而A/B测试则是用来测试应用功能表现的一种方法。
    • 金丝雀发布
      金丝雀发布是指通过让一小部分用户流量引入的新版本进行测试,就像把一个金丝雀塞到瓦斯井里面一样,探测这个新版本在环境中是否可用,在观察到新版本没有问题后再增加切换的比例,直到全部切换完成,是一个渐变、尝试的过程。如在过程中出现任何问题,则可以中止并回滚到旧版本。最简单的方式是随机选择百分比请求到金丝雀版本,但在更复杂的方案下,则可以基于请求的内容、特定范围的用户或其他属性等。
      ![在这里插入图片描述][Image 1]

      20210219222820450.jpg_x-oss-process_image_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTc2MjE3Mw_size_16_color_FFFFFF_t_70_pic_center

1.2 基于kubernetes的灰度发布

在Kubernetes环境下可以基于Pod的数量比例分配流量。如下图所示,B服务的两个版本v2和v1分别有2个和3个实例,当流量被均衡地分发到每个实例上时,前者可以得到40%的流量,后者可以得到60%的流量,从而达到流量在两个版本间分配的效果。
 

20210219223015381.png_x-oss-process_image_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTc2MjE3Mw_size_16_color_FFFFFF_t_70_pic_center


给v1和v2版本设置对应比例的Pod数量,依靠Kube-proxy把流量均衡地分发到目标后端,可以解决一个服务的多个版本分配流量的问题,但是限制非常明显:首先,要求分配的流量比例必须和Pod数量成比例,试想,基于这种方式支持 3:97 比例的流量基本上是不可能的;另外,这种方式不支持根据请求的内容来分配流量,比如要求Chrome浏览器发来的请求和IE浏览器发来的请求分别访问不同的版本。有没有一种更细粒度的分流方式?答案当然是有,Istio就可以。Istio叠加在Kubernetes之上,从机制上可以提供比Kubernetes更细的服务控制粒度及更强的服务管理能力。

1.3 基于Istio的灰度发布

Istio本身并没有关于灰度发布的规则定义,灰度发布只是流量治理规则的一种典型应用,在进行灰度发布时,只要写个简单的流量规则配置即可。Istio在每个Pod里都注入了一个Envoy,因而只要在控制面配置分流策略,对目标服务发起访问的每个Envoy便都可以执行流量策略,完成灰度发布功能。

在使用Istio实现灰度发布的情况下,流量路由和副本部署是两个完全独立的功能。服务的pod数量可以根据流量负载灵活伸缩,与版本流量路由的控制完全无关。这在自动缩放的情况下能够更加简单地管理金丝雀版本。Istio的路由规则非常灵活,可以支持细粒度控制流量百分比(例如,路由1%的流量而不需要100个pod),也可以使用其他规则来控制流量(例如,将特定用户的流量路由到金丝雀版本)。

为了更加直观的验证和说明,接下来我们就通过搭建实验环境来模拟各种业务场景下的灰度发布。

二、前置条件

2.1 实验环境搭建

由于个人电脑的网络和内存限制,本人是直接选择了在腾讯云服务器上安装Minikube和Kubectl,然后下载最新版本的Istio1.9,最后通过istioctl工具进行安装。安装过程不再赘述,具体可参考:
http://km.oa.com/group/34294/articles/show/410837

不过安装较新版本Istio的同学需要注意一下的是Istio 1.9 支持的kubernets版本要求不能低于v1.17,所以在用minikube启动kubernetes集群时必须指定好版本:

 
  1. $ minikube start --vm-driver=none --kubernetes-version v1.18.15

具体环境和版本清单如下:

  • 64位Cenos7.6:2核4G(最低配置要求)
  • Minikube == v1.17.1
  • Docker == v1.13.1
  • Kubernetes == v1.18.15
  • Istio == v1.9.0

2.2 服务网格监控组件的安装与配置

2.2.1 Kiali的安装

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

首先进入到Istio的安装包解压目录下,然后通过以下命令安装:

 
  1. [root@chon istio-1.9.0]# kubectl apply -f samples/addons
  2. [root@chon istio-1.9.0]# kubectl apply -f samples/addons/extras

安装时,由于网络原因,可能会报错,重试几次就好了。安装完成后,通过kubectl 命令查询相关pod的运行状态:

 
  1. [root@chon istio-1.9.0]# kubectl get pod -n istio-system
  2. NAME READY STATUS RESTARTS AGE
  3. grafana-94f5bf75b-fvlrt 1/1 Running 0 7h14m
  4. istio-egressgateway-5b475b9856-lzwwm 1/1 Running 0 24h
  5. istio-ingressgateway-648778567c-4gddl 1/1 Running 0 24h
  6. istiod-7cccc657f6-ng9r2 1/1 Running 0 24h
  7. jaeger-5c7675974-fmw4n 1/1 Running 0 7h14m
  8. kiali-d4fdb9cdb-wdj2v 1/1 Running 0 7h14m
  9. prometheus-7d76687994-p6whv 2/2 Running 0 7h14m
  10. zipkin-679599ffd8-xxb8l 1/1 Running 0 7h1m

2.2.2 配置Kiali控制面板对外访问

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

 
  1. [root@chon istio-1.9.0]# kubectl get service kiali -n istio-system
  2. NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S)
  3. kiali ClusterIP 10.105.136.82 <none> 20001:/TCP,9090/TCP

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

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

此时再查看kiali的service,可以看到已经可以端口已经暴露出来:

 
  1. [root@chon istio-1.9.0]# kubectl get service kiali -n istio-system
  2. NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
  3. kiali NodePort 10.105.136.82 <none> 20001:32662/TCP,9090:31692/TCP 7h44m

然后在浏览器中输入“http://<ip address>:32662/kiali”打开Kiali的登录页面,登录成功后,Kiali的总览视图如下所示:

2021021922323267.jpg_x-oss-process_image_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTc2MjE3Mw_size_16_color_FFFFFF_t_70_pic_center

2.3 实验项目部署

2.3.1 项目简介

下面通过经典的 Weather Forecast 进行部署实践,它是一款查询城市天气信息的应用实例,一共包含4个微服务,它们之间的调用关系如下:

20210219223559314.jpg_x-oss-process_image_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTc2MjE3Mw_size_16_color_FFFFFF_t_70_pic_center

  • frontend:前台服务,会调用 advertisement 和 forecast 这两个服务,展示整个应用的页面;
  • advertisement:广告服务,返回的静态的广告图片;
  • forecast:添加预报服务,返回相应城市的天气数据;
  • recommendation:推荐服务,根据天气情况向用户推荐穿衣和运行等信息。
    其中,frontend 服务的有两个版本:
  • v1 版本的界面按钮为绿色。
  • v2 版本的界面按钮为蓝色。
    forecast 服务有两个版本:
  • v1 版本会直接返回天气信息;
  • v2 版本会请求 recommendation 服务,获取推荐信息,并结合天气信息一起返回数据。

2.3.2 Weather Forecast 部署

Step1: 下载项目源码。由于官方代码的 Kubernetes api 版本未及时更新肯能会导致报错问题,所以这里不建议使用官,本文提供一个较新的源码:

 
  1. $ git clone https://github.com/slzcc/cloud-native-istio.git

Step2: 添加 v1 版本的服务

 
  1. $ kubectl create ns weather
  2. $ kubectl label namespace weather istio-injection=enabled
  3. $ kubectl apply -f install/weather-v1.yaml -n weather

等待服务安装成功:

20210219223908427.jpg_x-oss-process_image_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTc2MjE3Mw_size_16_color_FFFFFF_t_70_pic_center

Step3: 添加网关资源 Gateway。

 
  1. $ kubectl apply -f install/weather-gateway.yaml

Step4: 验证访问页面。添加网关资源 Gateway 创建完成后访问 istio-ingressgateway 地址即可访问,或者访问其 NodePort 端口:

 
  1. [root@chon ~]# kubectl get svc -n istio-system istio-ingressgateway
  2. NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
  3. istio-ingressgateway LoadBalancer 10.102.172.210 <pending> 15021:32492/TCP,80:31844/TCP,443:32460/TCP,31400:30568/TCP,15443:31743/TCP 25h

20210219224126222.jpg_x-oss-process_image_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTc2MjE3Mw_size_16_color_FFFFFF_t_70_pic_center

点击查询:

watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTc2MjE3Mw_size_16_color_FFFFFF_t_70_pic_center

至此,初始实验环境就全部搭建部署完成,接下来就正式开启Istio灰度发布功能的体验之旅。

三、实验过程

实验中有两个核心配置文件贯穿始终,有必要先提前认识和区分一下:

  • VirtualService:路由规则配置(虚拟服务),定义路由规则,可以将满足条件的流量都转发到对应的服务后端;
  • DestinationRule:目标规则配置,定义发生路由后应用于服务流量的策略,描述到达目标的请求怎么处理。
    目标规则是配合虚拟服务来使用的,主要用来定义子集,子集实际上就是具体的目标地址,除此以外,它主要描述的是到达目标请求后如何去处理,所谓的目标就是子集,而如何处理就是指具体的策略。

3.1 初始状态部署

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

 
  1. $ kubectl apply -f install/destination-rule-v1.yaml -n weather
  2. $ kubectl apply -f install/virtual-service-v1.yaml -n weather

查看配置的路由规则,以 forecast 服务为例:

 
  1. [root@chon ~]# kubectl get vs -n weather forecast-route -o yaml
  2. apiVersion: networking.istio.io/v1beta1
  3. kind: VirtualService
  4. ...
  5. name: forecast-route
  6. namespace: weather
  7. ...
  8. spec:
  9. hosts:
  10. - forecast
  11. http:
  12. - route:
  13. - destination:
  14. host: forecast
  15. subset: v1

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

20210219224638558.jpg_x-oss-process_image_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTc2MjE3Mw_size_16_color_FFFFFF_t_70_pic_center

3.2 基于流量比例的路由

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

Step1: 部署 recommendation 服务和 forecast 服务的 v2 版本。

 
  1. [root@chon cloud-native-istio]# kubectl apply -f install/recommendation-service/recommendation-all.yaml -f install/forecast-service/forecast-v2-deployment.yaml -n weather

查看服务状态:

在这里插入图片描述

Step2: 更新 forecast 服务 v2 版本的 DestinationRule。

 
  1. [root@chon cloud-native-istio]# kubectl apply -f install/forecast-service/forecast-v2-destination.yaml -n weather

查看下发成功的配置,可以看到增加了 v2 版本 subset 的定义:

 
  1. [root@chon cloud-native-istio]# kubectl get dr forecast-dr -o yaml -n weather
  2. ...
  3. host: forecast
  4. subsets:
  5. - labels:
  6. version: v1
  7. name: v1
  8. - labels:
  9. version: v2
  10. name: v2

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

Step3: 配置 forecast 服务的 VirtualService 配置,其中的 weight 字段显示了相应服务的流量占比,可以看到此时为 v1:v2 = 1:1。

在这里插入图片描述

 
  1. [root@chon cloud-native-istio]# kubectl apply -f chapter-files/canary-release/vs-forecast-weight-based-50.yaml -n weather

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

在这里插入图片描述

在这里插入图片描述

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

在这里插入图片描述

 
  1. [root@chon cloud-native-istio]# kubectl apply -f chapter-files/canary-release/vs-forecast-weight-based-v2.yaml -n weather

Step6: 在浏览器中查看配置后的效果。多次刷新页面查询天气,每次都会出现推荐信息,说明访问请求都被路由到了 forecast 服务 v2 版本。

查看Kiali控制台:

在这里插入图片描述

Step7: 保留 forecast 服务的老版本 v1 一段时间,再确认 v2 版本的各性能指标稳定后,删除老版本 v1 的所有资源,完成灰度发布。

3.3 基于请求内容的发布

场景二:在生产环境中同时上线了 forecast 服务的 v1 和 v2 版本,运维同学期望让不同的终端用户访问不同的版本,例如:让使用 Chrome 浏览器的用户看到推荐信息,但让使用其他浏览器的用户看不到推荐信息。

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

在这里插入图片描述

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

谷歌浏览器查询访问结果:

在这里插入图片描述

360浏览器查询访问结果:

在这里插入图片描述

现在已经掌握了两种路由规则的配置和应用之后,感兴趣的同学可以自己动手试一试,模拟将两种路由规则组合在一起的场景,比如:在生产环境中同时上线了 frontend 服务的 v1 和 v2 版本(v1 版本的按钮颜色是绿色的,v2 版本的按钮颜色是蓝色的),运维同学期望使用 Android 操作系统的一半用户看到的是 v1 版本,另一半用户看到的是 v2 版本;使用其他操作系统的用户看到的总是 v1 版本。

3.4 多服务同时发布

场景三:运维同学为 frontend 和 forecast 两个服务同时进行灰度发布,frontend 服务新增 v2 版本(界面的按钮为蓝色);forecast 服务新增 v2 版本(增加了推荐信息)。测试人员在用账户 tester 访问天气应用时会看到这两个服务的 v2 版本,其他用户只能看到两个服务的 v1 版本,要求不会出现服务版本交叉调用的情况。

在场景一中我们已经部署过了非入口服务 recommendation 和 forecast 的 v2 版本,并更新了 forecast 服务的 DestinationRule。现在我们在集群中来部署入口服务 frontend 的 v2 版本,并更新其 DestinationRule。

Step1: 部署入口服务 frontend 的 v2 版本。

 
  1. [root@chon cloud-native-istio]# vi install/frontend-service/frontend-v2-deployment.yaml
  2. apiVersion: apps/v1
  3. kind: Deployment
  4. metadata:
  5. name: frontend-v2
  6. labels:
  7. app: frontend
  8. version: v2
  9. spec:
  10. replicas: 1
  11. selector:
  12. matchLabels:
  13. app: frontend
  14. template:
  15. metadata:
  16. labels:
  17. app: frontend
  18. version: v2
  19. spec:
  20. containers:
  21. - name: frontend
  22. image: istioweather/frontend:v2
  23. imagePullPolicy: IfNotPresent
  24. ports:
  25. - containerPort: 3000
  26. [root@chon cloud-native-istio]# kubectl apply -f install/frontend-service/frontend-v2-deployment.yaml -n weather

查看部署情况:

在这里插入图片描述

Step2: 更新 frontend 服务的 DestinationRule,增加对 v2 版本 subset 的定义:

 
  1. [root@chon cloud-native-istio]# vi frontend-service/frontend-v2-destination.yaml
  2. apiVersion: networking.istio.io/v1alpha3
  3. kind: DestinationRule
  4. metadata:
  5. name: frontend-dr
  6. spec:
  7. host: frontend
  8. subsets:
  9. - name: v1
  10. labels:
  11. version: v1
  12. - name: v2
  13. labels:
  14. version: v2
  15. [root@chon cloud-native-istio]# kubectl apply -f install/frontend-service/frontend-v2-destination.yaml -n weather

Step3: 配置 frontend 服务的基于访问内容的路由规则,将测试账户(Cookie 带有 “user=tester”)信息的请求流量导入到 frontend 服务的 v2 版本的 Pod 实例。

 
  1. apiVersion: networking.istio.io/v1alpha3
  2. kind: VirtualService
  3. metadata:
  4. name: frontend-route
  5. spec:
  6. hosts:
  7. - "*"
  8. gateways:
  9. - istio-system/weather-gateway
  10. http:
  11. - match:
  12. - headers:
  13. cookie:
  14. regex: ^(.*?;)?(user=tester)(;.*)?$
  15. route:
  16. - destination:
  17. host: frontend
  18. subset: v2
  19. - route:
  20. - destination:
  21. host: frontend
  22. subset: v1
  23. [root@chon cloud-native-istio]# kubectl apply -f chapter-files/canary-release/vs-frontend-multiservice-release.yaml -n weather

Step4: 配置非入口服务 forecast 的路由规则,使得只有带“version:v2”标签的 Pod 实例的流量,才能进入 forecast 服务的新版本 v2 实例:

 
  1. [root@chon canary-release]# vi chapter-files/canary-release/vs-forecast-multiservice-release.yaml
  2. apiVersion: networking.istio.io/v1alpha3
  3. kind: VirtualService
  4. metadata:
  5. name: forecast-route
  6. spec:
  7. hosts:
  8. - forecast
  9. http:
  10. - match:
  11. - sourceLabels:
  12. version: v2
  13. route:
  14. - destination:
  15. host: forecast
  16. subset: v2
  17. - route:
  18. - destination:
  19. host: forecast
  20. subset: v1
  21. [root@chon cloud-native-istio]# kubectl apply -f chapter-files/canary-release/vs-forecast-multiservice-release.yaml -n weather

Step5: 查看配置后的效果。
用 tester 账户登录并访问前台页面,界面的按钮是蓝色的,表示访问到的是 frontend 服务的 v2 版本。在查询天气时会显示推荐信息,表示可以访问到 forecast 服务的 v2 版本:

在这里插入图片描述

不登入或者使用其他用户则访问的是 v1 版本看不到推荐信息:

在这里插入图片描述

可视化视图查看服务间调用关系:

在这里插入图片描述

3.5 自动化部署

前面介绍的灰度发布的策略配置都需要人工干预。在持续交付过程中,为了解决部署和管理的复杂性,往往需要通过自动化工具实现基于权重的灰度发布。

Flagger 是一个基于 Kubernetes 和 Istio 提供灰度发布、监控和告警等功能的开源软件,通过使用 Istio 的流量路由和 Prometheus 指标来分析应用程序的行为,从而实现灰度版本的自动部署,可以使用 Webhook 扩展 Canary 分析,已运行集成测试、压力测试或其他自定义测试。

在这里插入图片描述

其部署流程如上图所示,由于篇幅有限,这里就不再进行赘述,有兴趣的同学可以进一步进行实践体验。

四、总结

作为Istio入门体验系列的第一篇文章,关于灰度发布的实践暂时就先到这里了。对于一名刚接触Istio的小白,通过基于流量比例、基于请求内容以及多服务场景下的灰度发布的实践,Get到了它区别于Kubernetes的部署方式,也切身感受到了Istio在各种规则业务场景下的灵活性。当然,作为系列文章,接下来我也将继续学习探索,持续输出,还望各位同学多多关注,提出宝贵建议!

[

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/news/50874.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

如何批量加密PDF文件并设置不同密码 - 批量PDF加密工具使用教程

如果你正在寻找一种方法来批量加密和保护你的PDF文件&#xff0c;批量PDF加密工具是一个不错的选择。 它是一个体积小巧但功能强大的Windows工具软件&#xff0c;能够批量给多个PDF文件加密和限制&#xff0c;包括设置打印限制、禁止文字复制&#xff0c;并增加独立的打开密码。…

从零开始的Hadoop学习(一) | 大数据概念、特点、应用场景、发展前景

1. 大数据概念 大数据(Big Data)&#xff1a;指 无法在一定时间范围 内用常规软件工具进行捕捉、管理和处理的数据集合&#xff0c;是需要新处理模式才能具有更强的决策力、洞察发现力和流程优化能力的 海量、高增长率和多样化 的 信息资产。 大数据主要解决&#xff0c;海量…

【业务功能篇73】分布式ID解决方案

业界实现方案 1. 基于UUID2. 基于DB数据库多种模式(自增主键、segment)3. 基于Redis4. 基于ZK、ETCD5. 基于SnowFlake6. 美团Leaf(DB-Segment、zkSnowFlake)7. 百度uid-generator() 1.基于UUID生成唯一ID UUID:UUID长度128bit&#xff0c;32个16进制字符&#xff0c;占用存储空…

保护函数返回的利器——Linux Shadow Call Stack

写在前面 提到内核栈溢出的漏洞缓解&#xff0c;许多朋友首先想到的是栈内金丝雀&#xff08;Stack Canary&#xff09;。今天向大家介绍一项在近年&#xff0c;于Android设备中新增&#xff0c;且默默生效的安全机制——影子调用栈&#xff1a;SCS&#xff08;Shadow Call St…

elementUI moment 年月日转时间戳 时间限制

changeStartTime(val){debuggerthis.startT val// this.startTime parseInt(val.split(-).join())this.startTime moment(val).unix() * 1000 //开始时间毫秒if(this.endTime){this.endTime moment(this.endT).unix() * 1000 //结束时间毫秒if(this.startTime - this.endTi…

​山东省图书馆典藏《乡村振兴战略下传统村落文化旅游设计》鲁图中大许少辉博士八一新书

​山东省图书馆《乡村振兴战略下传统村落文化旅游设计》鲁图中大许少辉博士八一新书

Python豆瓣爬虫(最简洁的豆瓣250爬虫,随机选择电影)

案例背景 电影才是世界艺术&#xff0c;所以我一直想看完豆瓣250&#xff0c;那么就重新拾起我的爬虫知识。 以前刚学爬虫那啥也不会&#xff0c;python语法都没弄清楚&#xff0c;现在不一样了&#xff0c;能用最为简洁的代码写出爬虫250的代码。 代码实现 导入包&#xff…

多模态(文本、图片)数据融合模型(含公开数据集、文献及开源代码汇总)

多模态&#xff08;文本、图片&#xff09;数据融合模型&#xff08;含公开数据集、文献及开源代码汇总&#xff09; <center>多模态模型的应用跑代码普遍存在的问题 <center>多模态公开数据集<center>文献及开源代码 多模态模型的应用 多模态模型的应用按照…

单片机 (一) 让LED灯 亮

一&#xff1a;硬件电路图 二&#xff1a;软件代码 #include "reg52.h"#define LED_PORT P2void main() {LED_PORT 0x01; // 0000 0001 D1 是灭的 } #include "reg52.h" 这个头文件的作用&#xff1a;包含52 系列单片机内部所有的功能寄存器 三&#…

使用Termux在安卓手机上搭建Hexo博客网站,并发布到公网访问

文章目录 1. 安装 Hexo2. 安装cpolar内网穿透3. 公网远程访问4. 固定公网地址 Hexo 是一个用 Nodejs 编写的快速、简洁且高效的博客框架。Hexo 使用 Markdown 解析文章&#xff0c;在几秒内&#xff0c;即可利用靓丽的主题生成静态网页。 下面介绍在Termux中安装个人hexo博客并…

缓存穿透、缓存击穿和缓存雪崩

&#x1f44f;作者简介&#xff1a;大家好&#xff0c;我是爱发博客的嗯哼&#xff0c;爱好Java的小菜鸟 &#x1f525;如果感觉博主的文章还不错的话&#xff0c;请&#x1f44d;三连支持&#x1f44d;一下博主哦 &#x1f4dd;社区论坛&#xff1a;希望大家能加入社区共同进步…

【JVM 内存结构 | 程序计数器】

内存结构 前言简介程序计数器定义作用特点示例应用场景 主页传送门&#xff1a;&#x1f4c0; 传送 前言 Java 虚拟机的内存空间由 堆、栈、方法区、程序计数器和本地方法栈五部分组成。 简介 JVM&#xff08;Java Virtual Machine&#xff09;内存结构包括以下几个部分&#…

和鲸 ModelWhale 与中科可控多款服务器完成适配认证,赋能中国云生态

当前世界正处于新一轮技术革命及传统产业数字化转型的关键期&#xff0c;云计算作为重要的技术底座&#xff0c;其产业发展与产业规模对我国数字经济的高质量运行有着不可取代的推动作用。而随着我国数字上云、企业上云加快进入常规化阶段&#xff0c;云计算承载的业务应用越来…

跟随角色镜头时,解决地图黑线/白线缝隙的三种方案

下面一共三个解决方案&#xff0c;这里我推荐第二个方案解决&#xff0c;因为够快速和简单。 现象&#xff1a; 解决方案一&#xff1a; 参考【Unity2D】去除地图中的黑线_unity选中后有线_香菇CST的博客-CSDN博客&#xff0c;博主解释是因为抗锯齿采样导致的问题。 具体到这…

(6)(6.3) 自动任务中的相机控制

文章目录 前言 6.3.1 概述 6.3.2 自动任务类型 6.3.3 创建合成图像 前言 本文介绍 ArduPilot 的相机和云台命令&#xff0c;并说明如何在 Mission Planner 中使用这些命令来定义相机勘测任务。这些说明假定已经连接并配置了相机触发器和云台(camera trigger and gimbal ha…

ArcGIS API开发介绍

本来想自己总结写一下的&#xff0c;但是发现有个网站总结的特别好。所以直接给大家分享一下地址&#xff1a; 起步 - Start | ArcGis中文网 当然系统性的学习和使用还的看官网文档Quick Links | API Reference | ArcGIS Maps SDK for JavaScript 4.27 | ArcGIS Developers …

STM32CubeMX配置STM32G0 Standby模式停止IWDG(HAL库开发)

1.打开STM32CubeMX选择好对应的芯片&#xff0c;打开IWDG 2.打开串口1进行调试 3.配置好时钟 4.写好项目名称&#xff0c;选好开发环境&#xff0c;最后获取代码。 5.打开工程&#xff0c;点击魔术棒&#xff0c;勾选Use Micro LIB 6.修改main.c #include "main.h"…

Hive(一)

一、DDL 1、数据库操作 1&#xff09;、创建数据库 语法&#xff1a; CREATE DATABASE [IF NOT EXISTS] database_name [COMMENT database_comment] [LOCATION hdfs_path] [WITH DBPROPERTIES (property_nameproperty_value, ...)]; 案例&#xff1a; &#xff08;1&…

OpenGL —— 2.5、绘制第一个三角形(附源码,glfw+glad)(更新:纹理贴图)

源码效果 C源码 纹理图片 需下载stb_image.h这个解码图片的库&#xff0c;该库只有一个头文件。 具体代码&#xff1a; vertexShader.glsl #version 330 corelayout(location 0) in vec3 aPos; layout(location 1) in vec3 aColor; layout(location 2) in vec2 aUV;out ve…

【Linux】socket编程(二)

目录 前言 TCP通信流程 TCP通信的代码实现 tcp_server.hpp编写 tcp_server.cc服务端的编写 tcp_client.cc客户端的编写 整体代码 前言 上一章我们主要讲解了UDP之间的通信&#xff0c;本章我们将来讲述如何使用TCP来进行网络间通信&#xff0c;主要是使用socket API进…