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

在之前的最佳实践中,已经带大家通过一系列的实践任务领略了Istio的无穷魅力。今天,将向大家介绍如何用Istio实现流量熔断。

熔断机制是创建弹性微服务应用程序的重要模式。熔断可以帮助您自由控制故障影响的范围、网络延迟的峰值以及抵御其他一些来自外部的恶意攻击等场景。

在接下来的任务中,idou老师将通过配置一个熔断器来详细介绍如何在Istio中实现熔断,以及背后的原理。

首先,我们需要添加一个应用程序来模拟访问网络中的通信。接着我们按照前面Istio实践中所要求的将Sidecar注入进应用中,然后启动应用。

步骤一

为了演示Istio的熔断功能,我们需要创建熔断器,并在熔断器中设置一个目标规则,如下所示:

在本步骤中,我们可以理解为Istio的熔断功能主要是通过在链接池中加入上述三个参数:

  • MaxConnections定义了到目标主机的 HTTP1/TCP 最大连接数;
  • http1MaxPendingRequests定义了针对一个目标的 HTTP 请求的最大排队数量;
  • maxRequestsPerConnection定义了对某一后端的请求中,一个连接内能够发出的最大请求数量。如果将这一参数设置为 1 则会禁止 keep alive 特性。

在上述yaml文件中,我们为了方便进行实践,所以都设置成了1,当然大家也可以根据自己的需求自己设定阈值。

步骤二

对于网络通信熟悉的小伙伴应该都知道,模拟网络通信的环境需要一个服务端接收请求,一个请求端发送请求。刚刚我们已经创建完成一个服务端,并给服务端配置了熔断的条件,现在我们继续创建一个请求端来发送请求触发熔断机制。

我们用了官网上的一个例子fortio来进行测试。这个客户端可以控制连接数量、并发数、以及发送HTTP请求的延迟,当然我们也必须将Sidecar注入其中。

步骤三

我们可以通过命令kubectl exec -it $FORTIO_POD  -c fortio /usr/local/bin/fortio -- load -curl  http://httpbin:8000/get来登入客户端Pod,并使用刚刚创建的客户端来调用httpbin。将会看到如下所示:

这表明我们创建的客户端已经成功与服务端进行了一次通信。

步骤四

开始进入今天的主题,在上面的熔断设置中指定了 maxConnections=1 以及 http1MaxPendingRequests=1。这意味着如果超过了一个连接同时发起请求,Istio 就会熔断,阻止后续的请求或连接。我们不妨尝试通过并发2个连接发送20个请求数来看一下结果。

通过上图不难看出,基本上所有的请求都发送成功了。明明我们设置的最大连接数是1,而我们模拟了两个并发连接,理论上应该只有一半的请求能成功才对,难道熔断没有成功?这里别忘了我们还设置了http1MaxPendingRequests=1,正如在前文中介绍的,这个参数的功能类似于为最大连接数提供了一级缓存,所以虽然我们的最大连接数是1,但是因为这个参数也为1,所以两个并发连接的请求都可以发送成功。

步骤五

接下来我们再修改一下参数与步骤四做个对比,模拟并发连接数数改为3请求数依然是20,我们将会看到如下图所示的结果:

正如我们在第三步中说的那样,只有2/3的请求成功,还有1/3的请求数被熔断。如果你觉得还不放心,那么我们不妨再把http1MaxPendingRequests置为2。这时候缓存区的请求相当于最大允许连接数的2倍,是不是并发数为3的模拟连接发送的请求都可以成功呢?

从上图我们可以看到,确实如此,基本上所有的请求都成功了。

通过今天的实践我们就可以知道,如何通过修改Istio的目标规则来对请求数启动熔断机制。

原文地址:https://www.cnblogs.com/CCE-SWR/p/10329579.html

时间: 2024-08-29 04:34:20

idou老师教你学Istio11 : 如何用Istio实现流量熔断的相关文章

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

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

idou老师教你学Istio05: 如何用Isito实现智能路由配置

概要 要介绍istio请求路由,我们不由得先从pilot 和 envoy开始谈起. 在服务网格中,Pilot管理和配置所有的envoy实例.在pilot中,你几乎可以配置所有的关于流量导向规则及其他故障恢复规则.而Envoy不仅会获得从pilot拿到的基本负载均衡信息,同时周期性的健康检查,也会告诉所有的envoy其他的实例现在的运行状况.负载均衡信息,及健康检查的信息可以使envoy更加智能的去分发流量. 在上述的pilot结构中,不难理解,platform adapter作为平台适配器,可以

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

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

idou老师教你学Istio 14:如何用K8S对Istio Service进行流量健康检查

Istio利用k8s的探针对service进行流量健康检查,有两种探针可供选择,分别是liveness和readiness: liveness探针用来侦测什么时候需要重启容器.比如说当liveness探针捕获到程序运行时出现的一个死锁,这种情况下重启容器可以让程序更容易可用. readiness探针用来使容器准备好接收流量.当所有容器都ready时被视为pod此时ready.比如说用这种信号来控制一个后端服务,当pod没有到ready状态时,服务会从负载均衡被移除. 使用场景: liveness

idou老师教你学Istio 16:如何用 Istio 实现微服务间的访问控制

摘要使用 Istio 可以很方便地实现微服务间的访问控制.本文演示了使用 Denier 适配器实现拒绝访问,和 Listchecker 适配器实现黑白名单两种方法. 使用场景 有时需要对微服务间的相互访问进行控制,比如使满足某些条件(比如版本)的微服务能够(或不能)调用特定的微服务. 访问控制属于策略范畴,在 Istio 中由 Mixer 组件实现. Mixer拓扑图,来源官方文档 如上图所示,服务的外部请求会被 Envoy 拦截,每个经过 Envoy 的请求都会调用 Mixer,为 Mixer

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老师教你学istio1:如何为服务提供安全防护能力

今天,我们就来谈谈Istio主打功能---保护服务. 那么,便引出3个问题: Istio 凭什么保护服务? Istio 具体如何保护服务? 如何告诉 Istio 发挥保护能力? Istio凭什么保护服务? 将单体应用程序分解为一个个服务,为大型软件系统的开发和维护带来了诸多好处,比如更好的灵活性.可伸缩性和可复用性.但这也带来了一些安全问题: 为了抵御中间***,需要对流量进行加密 为了提供灵活的服务访问控制,需要 mTLS(双向的安全传输层协议)和细粒度的访问策略 要审计谁在什么时候做了什么,

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

我们知道每个pod内都会有一个Envoy容器,其具备对流入和流出pod的流量进行管理,认证,控制的能力.Mixer则主要负责访问控制和遥测信息收集. 如拓扑图所示,当某个服务被请求时,首先会请求istio-policy服务,来判定是否具备访问资格,若具备资格则放行反之则请求不会被下发到服务.这一切的访问信息,都会被记录在Envoy中,之后会上报给mixer作为原始数据.遥测数据的收集及其他功能完全是灵活可控的,你既可以配置新的收集指标和日志,也可以完全禁用这些功能. 1.Prometheus的应