西餐甜点网站建设,济南行知网站制作,论坛 网站建设的步骤过程,在哪里做推广效果好导言#xff1a;灰度发布是指在项目迭代的过程中用平滑过渡的方式进行发布。灰度发布可以保证整体系统的稳定性#xff0c;在初始发布的时候就可以发现、调整问题#xff0c;以保证其影响度。作为Istio体验系列的第一站#xff0c;本文基于Istio的流量治理机制#xff0c;… 导言灰度发布是指在项目迭代的过程中用平滑过渡的方式进行发布。灰度发布可以保证整体系统的稳定性在初始发布的时候就可以发现、调整问题以保证其影响度。作为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 灰度发布概述 在新版本上线时不管是在技术上考虑产品的稳定性等因素还是在商业上考虑新版本被用户接受的程度直接将老版本全部升级是非常有风险的。所以一般的做法是新老版本同时在线新版本只切分少量流量出来在确认新版本没有问题后再逐步加大流量比例。这正是灰度发布要解决的问题。其核心是能配置一定的流量策略将用户在同一个访问入口的流量导到不同的版本上。有如下几种典型场景。 蓝绿发布 蓝绿发布是指不停止老版本部署新版本然后进行测试确认没有问题之后再将流量全量切到新版本然后老版本同时也升级到新版本。这样做的好处是无需停机并且风险较小。 其发布的步骤大致如下 部署版本1的应用一开始的状态所有外部请求的流量都打到这个版本上部署版本2的应用版本2的代码与版本1不同新功能、Bug修复等将流量从版本1切换到版本2即流量从v1v2为1000切换为0100 如果版本2存在问题需要回滚到版本1进行流量切换回v1v2为1000。 A/B测试 A/B测试的场景比较明确就是同时在线上部署A和B两个对等的版本来接收流量按一定的目标选取策略让一部分用户使用A版本让一部分用户使用B版本收集这两部分用户的使用反馈即对用户采样后做相关比较通过分析数据来最终决定采用哪个版本。蓝绿发布则主要用于安全稳定地发布新版本应用而A/B测试则是用来测试应用功能表现的一种方法。金丝雀发布 金丝雀发布是指通过让一小部分用户流量引入的新版本进行测试就像把一个金丝雀塞到瓦斯井里面一样探测这个新版本在环境中是否可用在观察到新版本没有问题后再增加切换的比例直到全部切换完成是一个渐变、尝试的过程。如在过程中出现任何问题则可以中止并回滚到旧版本。最简单的方式是随机选择百分比请求到金丝雀版本但在更复杂的方案下则可以基于请求的内容、特定范围的用户或其他属性等。 ![在这里插入图片描述][Image 1] 1.2 基于kubernetes的灰度发布 在Kubernetes环境下可以基于Pod的数量比例分配流量。如下图所示B服务的两个版本v2和v1分别有2个和3个实例当流量被均衡地分发到每个实例上时前者可以得到40%的流量后者可以得到60%的流量从而达到流量在两个版本间分配的效果。 给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集群时必须指定好版本 $ minikube start --vm-drivernone --kubernetes-version v1.18.15 具体环境和版本清单如下 64位Cenos7.62核4G(最低配置要求)Minikube v1.17.1Docker v1.13.1Kubernetes v1.18.15Istio v1.9.0 2.2 服务网格监控组件的安装与配置 2.2.1 Kiali的安装 Kiali 是一个为 Istio 提供图形化界面和丰富观测功能的 Dashboard 的开源项目其名称源于希腊语意思是望远镜。用户利用 Kiali 可以监测网格内服务的实时工作状态管理Istio的网络配置快速识别网络问题。但是从Istio 1.7开始默认不安装控制面板Kiali等组件所以需要用户自行单独安装控制面板Kiali及相关的组件。 首先进入到Istio的安装包解压目录下然后通过以下命令安装 [rootchon istio-1.9.0]# kubectl apply -f samples/addons[rootchon istio-1.9.0]# kubectl apply -f samples/addons/extras 安装时由于网络原因可能会报错重试几次就好了。安装完成后通过kubectl 命令查询相关pod的运行状态: [rootchon istio-1.9.0]# kubectl get pod -n istio-systemNAME READY STATUS RESTARTS AGEgrafana-94f5bf75b-fvlrt 1/1 Running 0 7h14mistio-egressgateway-5b475b9856-lzwwm 1/1 Running 0 24histio-ingressgateway-648778567c-4gddl 1/1 Running 0 24histiod-7cccc657f6-ng9r2 1/1 Running 0 24hjaeger-5c7675974-fmw4n 1/1 Running 0 7h14mkiali-d4fdb9cdb-wdj2v 1/1 Running 0 7h14mprometheus-7d76687994-p6whv 2/2 Running 0 7h14mzipkin-679599ffd8-xxb8l 1/1 Running 0 7h1m 2.2.2 配置Kiali控制面板对外访问 查看kiali服务发现其类型为ClusterIP没有对外暴露端口无法从外部访问 [rootchon istio-1.9.0]# kubectl get service kiali -n istio-systemNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) kiali ClusterIP 10.105.136.82 none 20001:/TCP,9090/TCP 所以此时需要通过NodePort的方式对外暴露控制面板我们将原来的ClusterIP类型的service导出yaml文件通过删除注解、创建信息、状态字段及ClusterIP等信息将类型改NodePort然后使用kubectl apply -f 创建 [rootchon istio-1.9.0]# kubectl get svc -n istio-system kiali -o yaml kiali-nodeport.yaml[rootchon istio-1.9.0]# vi kiali-nodeport.yaml#主要删除metadata下的annotation, resourceVersion,seflFlink, uid; 以及spec下的ClusterIP,修改类型为NodePort 同时删除status状态字段即可。[rootchon istio-1.9.0]# kubectl apply -f kiali-nodeport.yaml 此时再查看kiali的service可以看到已经可以端口已经暴露出来 [rootchon istio-1.9.0]# kubectl get service kiali -n istio-systemNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEkiali NodePort 10.105.136.82 none 20001:32662/TCP,9090:31692/TCP 7h44m 然后在浏览器中输入“http//ip address32662/kiali”打开Kiali的登录页面登录成功后Kiali的总览视图如下所示 2.3 实验项目部署 2.3.1 项目简介 下面通过经典的 Weather Forecast 进行部署实践它是一款查询城市天气信息的应用实例一共包含4个微服务它们之间的调用关系如下 frontend前台服务会调用 advertisement 和 forecast 这两个服务展示整个应用的页面;advertisement广告服务返回的静态的广告图片;forecast添加预报服务返回相应城市的天气数据;recommendation推荐服务根据天气情况向用户推荐穿衣和运行等信息。 其中frontend 服务的有两个版本:v1 版本的界面按钮为绿色。v2 版本的界面按钮为蓝色。 forecast 服务有两个版本v1 版本会直接返回天气信息v2 版本会请求 recommendation 服务获取推荐信息并结合天气信息一起返回数据。 2.3.2 Weather Forecast 部署 Step1 下载项目源码。由于官方代码的 Kubernetes api 版本未及时更新肯能会导致报错问题所以这里不建议使用官本文提供一个较新的源码 $ git clone https://github.com/slzcc/cloud-native-istio.git Step2 添加 v1 版本的服务 $ kubectl create ns weather$ kubectl label namespace weather istio-injectionenabled$ kubectl apply -f install/weather-v1.yaml -n weather 等待服务安装成功 Step3 添加网关资源 Gateway。 $ kubectl apply -f install/weather-gateway.yaml Step4 验证访问页面。添加网关资源 Gateway 创建完成后访问 istio-ingressgateway 地址即可访问或者访问其 NodePort 端口 [rootchon ~]# kubectl get svc -n istio-system istio-ingressgatewayNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEistio-ingressgateway LoadBalancer 10.102.172.210 pending 15021:32492/TCP,80:31844/TCP,443:32460/TCP,31400:30568/TCP,15443:31743/TCP 25h 点击查询 至此初始实验环境就全部搭建部署完成接下来就正式开启Istio灰度发布功能的体验之旅。 三、实验过程 实验中有两个核心配置文件贯穿始终有必要先提前认识和区分一下 VirtualService路由规则配置虚拟服务定义路由规则可以将满足条件的流量都转发到对应的服务后端DestinationRule目标规则配置定义发生路由后应用于服务流量的策略描述到达目标的请求怎么处理。 目标规则是配合虚拟服务来使用的主要用来定义子集子集实际上就是具体的目标地址除此以外它主要描述的是到达目标请求后如何去处理所谓的目标就是子集而如何处理就是指具体的策略。 3.1 初始状态部署 在开始实验前首先对每个服务都创建各自的 VirtualService 和 DestinationRule 资源将访问请求路由到所有服务的 v1 版本 $ kubectl apply -f install/destination-rule-v1.yaml -n weather$ kubectl apply -f install/virtual-service-v1.yaml -n weather 查看配置的路由规则以 forecast 服务为例 [rootchon ~]# kubectl get vs -n weather forecast-route -o yamlapiVersion: networking.istio.io/v1beta1kind: VirtualService...name: forecast-routenamespace: weather...spec:hosts:- forecasthttp:- route:- destination:host: forecastsubset: v1 在浏览器中多次加载前台页面并查询城市的天气信息确认显示正常。然后打开Kiali控制台查看各个服务之间的调用关系如下图所示 3.2 基于流量比例的路由 场景一用户需要软件能够根据不同的天气情况推荐合适的穿衣和运动信息。于是开发的同学增加了 recommendation 新服务并升级 forecast 服务到 v2 版本来调用 recommendation 服务。在新特性上线时运维的同学首先部署 forecast 服务的 v2 版本和 recommendation 服务并对 forecast 服务的 v2 版本进行灰度发布。 Step1 部署 recommendation 服务和 forecast 服务的 v2 版本。 [rootchon 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。 [rootchon cloud-native-istio]# kubectl apply -f install/forecast-service/forecast-v2-destination.yaml -n weather 查看下发成功的配置可以看到增加了 v2 版本 subset 的定义 [rootchon cloud-native-istio]# kubectl get dr forecast-dr -o yaml -n weather...host: forecastsubsets:- labels:version: v1name: v1- labels:version: v2name: v2 这时去浏览器中查询天气显然还不会出现推荐信息因为所有流量依然都被路由到 forecast 服务的 v1 版本不会调用 recommendation 服务。 Step3 配置 forecast 服务的 VirtualService 配置其中的 weight 字段显示了相应服务的流量占比可以看到此时为 v1:v2 1:1。 [rootchon 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 版本。 [rootchon 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 版本。 [rootchon cloud-native-istio]# vi install/frontend-service/frontend-v2-deployment.yamlapiVersion: apps/v1kind: Deploymentmetadata:name: frontend-v2labels:app: frontendversion: v2spec:replicas: 1selector:matchLabels:app: frontendtemplate:metadata:labels:app: frontendversion: v2spec:containers:- name: frontendimage: istioweather/frontend:v2imagePullPolicy: IfNotPresentports:- containerPort: 3000[rootchon cloud-native-istio]# kubectl apply -f install/frontend-service/frontend-v2-deployment.yaml -n weather 查看部署情况 Step2 更新 frontend 服务的 DestinationRule增加对 v2 版本 subset 的定义 [rootchon cloud-native-istio]# vi frontend-service/frontend-v2-destination.yamlapiVersion: networking.istio.io/v1alpha3kind: DestinationRulemetadata:name: frontend-drspec:host: frontendsubsets:- name: v1labels:version: v1- name: v2labels:version: v2[rootchon cloud-native-istio]# kubectl apply -f install/frontend-service/frontend-v2-destination.yaml -n weather Step3 配置 frontend 服务的基于访问内容的路由规则将测试账户Cookie 带有 “usertester”信息的请求流量导入到 frontend 服务的 v2 版本的 Pod 实例。 apiVersion: networking.istio.io/v1alpha3kind: VirtualServicemetadata:name: frontend-routespec:hosts:- *gateways:- istio-system/weather-gatewayhttp:- match:- headers:cookie:regex: ^(.*?;)?(usertester)(;.*)?$route:- destination:host: frontendsubset: v2- route:- destination:host: frontendsubset: v1[rootchon cloud-native-istio]# kubectl apply -f chapter-files/canary-release/vs-frontend-multiservice-release.yaml -n weather Step4 配置非入口服务 forecast 的路由规则使得只有带“versionv2”标签的 Pod 实例的流量才能进入 forecast 服务的新版本 v2 实例 [rootchon canary-release]# vi chapter-files/canary-release/vs-forecast-multiservice-release.yamlapiVersion: networking.istio.io/v1alpha3kind: VirtualServicemetadata:name: forecast-routespec:hosts:- forecasthttp:- match:- sourceLabels:version: v2route:- destination:host: forecastsubset: v2- route:- destination:host: forecastsubset: v1[rootchon 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在各种规则业务场景下的灵活性。当然作为系列文章接下来我也将继续学习探索持续输出还望各位同学多多关注提出宝贵建议 [
