idou老师教你学Istio 19 : Istio 流量治理功能原理与实战

一、负载均衡算法原理与实战

负载均衡算法(load balancing algorithm),定义了几种基本的流量分发方式,在Istio中一共有4种标准负载均衡算法。

?Round_Robin: 轮询算法,顾名思义请求将会依次发给每一个实例,来共同分担所有的请求。

?Random: 随机算法,将所有的请求随机分发给健康的实例

?Least_Conn: 最小连接数,在所有健康的实例中任选两个,将请求发给连接数较小的那一个实例。

接下来,我们将根据以上几个算法结合APM(应用性能管理)的监控拓扑图来实战下。

·实战环境·

华为云开启了Istio服务网格的CCE集群

官方最佳时间Bookinfo应用,并且给Reviews配置了五个实例

开通APM测试服务(免费)

我们知道如果用户不进行任何配置,负载均衡算法默认是轮询算法,所以我们现将负载均衡算法设为随机(Random)。

步骤 1
在云容器引擎界面点击应用管理,选择流量治理。

步骤 2
右侧出现拓扑图,在上面的选项栏中选择集群,命名空间,应用。然后点击我们想配置的组件,这里是 reviews,右侧则会出现流量治理的界面。

步骤 3
在负载均衡算法中,由Round_Robin 改为random。

步骤 4
在左侧导航栏中选择流量治理下面的流量监控,再选择相应的集群,命名空间,应用。多访问几次,或者后台写脚本一直curl productpage,可以从拓扑图中观察数据。

步骤 5
当有流量时,鼠标右键点击reviews组件,选择展开选项这时我们可以看到所有实例的被分发情况。

实例编号 1 2 3 4 5
访问次数 62 38 39 42 52

其余负载均衡算法基本一样,我们在步骤上不做赘述,直接展示结果。

轮询算法:

实例编号 1 2 3 4 5
访问次数 47 47 48 46 47

二、会话保持原理与实战

会话保持(Session Affinity)是通过设定的某个指标来计算,将哈希值相同的请求分发至某个固定的实例来处理。现在支持基于HTTP头部设定指标和Cookie键值设定指标。

我们当前还在轮询算法中,所以所有请求会均匀的分配给所有实例,设置会话保持基于HTTP请求头部,并且设为Cookie。我们后台curl的请求cookie设为了一个固定值,理论上来讲所有的请求都会分发至同一个pod。

我们依然采用流量监控,展开reviews组件来观察分发情况。

根据图中不难看出,所有的请求都分发至了第二个实例,因为cookie一致所以保持了这个会话链接。

三、故障注入原理与实战

故障注入(Fault Injection)为开发和测试人员主动向系统中引入故障,来观察系统在非正常状态下的行为,是一种可靠性,稳定性的验证手段。Istio也支持了非侵入式的注入故障,分为时延故障和中断故障。

故障注入的步骤大致相同在流量治理页面的下方,选择时延故障,并且输入触发百分比和延时时间。然后再打开productpage 手动刷新几次,能明显感觉到延迟有了变化,当然也可以打开F12调试界面,观察网络请求状况,不难发现productpage请求耗时都在2秒上下。

这时候我们打开流量监控界面观察下发现productpage与reviews受到了明显的影响。红色表示请求状态极差,虚线表示是由时延造成的。

接下来我们来测试并且使用中断故障,我们对details配置中断故障,中断返回码设为501。

配置完后,我们再去手动访问几次productpage来观察下结果。

发现现在的右侧details已经报了error

我们回到流量监控图,可以看到组件之间的访问情况。在给ratings配置了中断故障后,原本调用ratings组件的reviews组件,已经无法和ratings通信了。

本文以华为云istio服务结合APM服务为大家演示了流量治理中的主要功能。希望大家在今后的开发和测试中可以利用istio灵活的非侵入的治理功能提高开发和测试的效率。

相关服务请访问https://support.huaweicloud.com/cce/index.html?cce_helpcenter_2019

原文地址:http://blog.51cto.com/14051317/2350578

时间: 2024-08-28 11:34:23

idou老师教你学Istio 19 : Istio 流量治理功能原理与实战的相关文章

Istio 流量治理功能原理与实战

一.负载均衡算法原理与实战 负载均衡算法(load balancing algorithm),定义了几种基本的流量分发方式,在Istio中共有4种标准负载均衡算法. ?Round_Robin: 轮询算法,顾名思义请求将会依次发给每一个实例,来共同分担所有的请求. ?Random: 随机算法,将所有的请求随机分发给健康的实例 ?Least_Conn: 最小连接数,在所有健康的实例中任选两个,将请求发给连接数较小的那一个实例. 接下来,我们将根据以上几个算法结合APM(应用性能管理)的监控拓扑图来实

idou老师教你学Istio 07: 如何用istio实现请求超时管理

前言 在前面的文章中,大家都已经熟悉了Istio的故障注入和流量迁移.这两个方面的功能都是Istio流量治理的一部分.今天将继续带大家了解Istio的另一项功能,关于请求超时的管理. 首先我们可以通过一个简单的Bookinfo的微服务应用程序来动手实践一下Istio是如何实现请求超时的管理.看过idou老师前面文章的老司机应该都已经对Bookinfo这个实例驾轻就熟了,当然还存在部分被idou老师的文采刚吸引过来的新同学. 下面先简单的介绍一下Bookinfo这个样例应用整体架构,以便我们更好地

idou老师教你学Istio11 : 如何用Istio实现流量熔断

在之前的最佳实践中,已经带大家通过一系列的实践任务领略了Istio的无穷魅力.今天,将向大家介绍如何用Istio实现流量熔断. 熔断机制是创建弹性微服务应用程序的重要模式.熔断可以帮助您自由控制故障影响的范围.网络延迟的峰值以及抵御其他一些来自外部的恶意攻击等场景. 在接下来的任务中,idou老师将通过配置一个熔断器来详细介绍如何在Istio中实现熔断,以及背后的原理. 首先,我们需要添加一个应用程序来模拟访问网络中的通信.接着我们按照前面Istio实践中所要求的将Sidecar注入进应用中,然

idou老师教你学Istio 15:Istio实现双向TLS的迁移

在Istio中,双向TLS是传输身份验证的完整堆栈解决方案,它为每个服务提供可跨集群的强大身份.保护服务到服务通信和最终用户到服务通信,以及提供密钥管理系统.本文阐述如何在不中断通信的情况下,把现存Istio服务的流量从明文升级为双向TLS. 使用场景 在部署了Istio的集群中,使用人员刚开始可能更关注功能性,服务之间的通信配置的都是明文传输,当功能逐渐完善,开始关注安全性,部署有sidecar的服务需要使用双向TLS进行安全传输,但服务不能中断,这时,一个可取的方式就是进行双向TLS的迁移.

idou老师教你学Istio 25:如何用istio实现监控和日志采集

大家都知道istio可以帮助我们实现灰度发布.流量监控.流量治理等功能.每一个功能都帮助我们在不同场景中实现不同的业务.那Istio是如何帮助我们实现监控和日志采集的呢? 这里我们依然以Bookinfo应用程序作为贯穿此任务的示例程序.首先在集群中安装并部署Istio. 1 收集遥测数据 创建一个新的YAML文件,用来保存Istio将自动生成和收集的新度量标准和日志流的配置.如下图所示: 通过命令$ kubectl apply -f new_telemetry.yaml推送刚刚配置的YAML文件

idou老师教你学istio:监控能力介绍

经过了一年多的开发和测试,Istio于北京时间7月31日发布了1.0版本,并且宣布1.0版本已经可以成熟的应用于生产环境.对于istio的各项主要功能,之前的文章已经介绍的非常详细,并且还会有更多的文章来分析原理和实践功能.今天我们主要介绍的服务是istio流量监控能力.我们知道每个pod内都会有一个Envoy容器,其具备对流入和流出pod的流量进行管理,认证,控制的能力.Mixer则主要负责访问控制和遥测信息收集.如拓扑图所示,当某个服务被请求时,首先会请求istio-policy服务,来判定

idou老师教你学Istio06: 如何用istio实现流量迁移

概要 流量迁移是流量管理的一个重要功能.istio提供的流量管理功能将流量从基础设施扩展中解耦,支持动态请求路由,故障注入.超时重试.熔断和流量迁移等.流量迁移的主要目的是将流量从微服务的某一版本的逐步迁移至另一个版本,如在新旧版本之间进行流量切换.本文通过一个简单的用例介绍如何使用istio进行流量迁移. 本文使用一个bookinfo的典型例子.通过istio的命令配置规则,将流量从reviews的版本v1逐步迁移到版本v3.在下面的例子中,应用基于权重路由配置,将百分百路由在reviews:

idou老师教你学Istio 04:Istio性能及扩展性介绍

Istio的性能问题一直是国内外相关厂商关注的重点,Istio对于数据面应用请求时延的影响更是备受关注,而以现在Istio官方与相关厂商的性能测试结果来看,四位数的qps显然远远不能满足应用于生产的要求.从发布以来,Istio官方也在不断的对其性能进行优化增强.同时,Istio控制面的可靠性是Istio用于生产的另一项重要考量标准,自动伸缩扩容,自然是可靠性保证的重要手段.下面我们先从性能测试的角度入手,了解下Istio官方提供的性能测试方法与基准,主要分为以下四个方面展开. 一.函数级别测试

idou老师教你学Istio 08: 调用链埋点是否真的“零修改”?

本文将结合一个具体例子中的细节详细描述Istio调用链的原理和使用方式.并基于Istio中埋点的原理解释来说明:为了输出一个质量良好的调用链,业务程序需根据自身特点做适当的修改,即并非官方一直在说的完全无侵入的做各种治理.另外还会描述Istio当前版本中收集调用链数据可以通过Envoy和Mixer两种不同的方式. Istio一直强调其无侵入的服务治理,服务运行可观察性.即用户完全无需修改代码,就可以通过和业务容器一起部署的proxy来执行服务治理和与性能数据的收集.原文是这样描述的: Istio