Istio - TrafficManagement - Circuit Breaker

简介: 断路器也成服务熔断,在多个服务调用的时候,服务A依赖服务B,服务B依赖服务C,如果服务C响应时间过长或者不可用,则会让服务B占用太多系统资源,而服务A也依赖服B,同时也在占用大量的系统资源,造成系统雪崩的情况出现。 Istio 断路器通过网格中的边车对流量进行拦截判断处理,避免了在代码中侵入控制逻辑,非常方便的就实服务熔断的能力。

> 断路器也成服务熔断,在多个服务调用的时候,服务A依赖服务B,服务B依赖服务C,如果服务C响应时间过长或者不可用,则会让服务B占用太多系统资源,而服务A也依赖服B,同时也在占用大量的系统资源,造成系统雪崩的情况出现。 Istio 断路器通过网格中的边车对流量进行拦截判断处理,避免了在代码中侵入控制逻辑,非常方便的就实服务熔断的能力。


#### 什么场景需要用到超时处理

微服务场景下,在多个服务调用的时候,服务A依赖服务B,服务B依赖服务C,如果服务C响应时间过长或者不可用,则会让服务B占用太多系统资源,而服务A也依赖服B,同时也在占用大量的系统资源,造成系统雪崩的情况出现。

image.jpeg

#### 通过例子来理解

image.jpeg


apiVersion: apps/v1
kind: Deployment
metadata:  labels:    app: nginx-deployment
  name: nginx-deployment
spec:  replicas: 1  selector:    matchLabels:      app: nginx-deployment
  strategy:    rollingUpdate:      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  template:    metadata:      labels:        app: nginx-deployment
    spec:      containers:        - image: 'nginx:latest'          name: nginx-deployment
---apiVersion: v1
kind: Service
metadata:  name: nginx-service
spec:  selector:    app: nginx-deployment
  type: ClusterIP
  ports:  - name: http
    port: 80    targetPort: 80    protocol: TCP
---apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:  name: nginx-dr
spec:  host: nginx-service
  trafficPolicy:    connectionPool:      http:        http1MaxPendingRequests: 1        maxRequestsPerConnection: 1    outlierDetection:      consecutiveErrors: 1      interval: 10s
      baseEjectionTime: 10s
      maxEjectionPercent: 100


##### 测试服务熔断

通过执行 ``kubectl get svc`` 获取服务IP地址

image.jpeg

通过压测工具进行请求测试

``fortio load -c 10 -n 50 -qps 0 http://10.2.189.170``

image.jpeg

结果显示 Code 503 有 64% 的流量触发到熔断


##### 断路器相关参数配置

http1MaxPendingRequests: http 请求挂起状态的最大请求数

maxRequestsPerConnection: 一定时间内限制对后端服务发起的最大请求数,如果超过了此配置,就会出现限流。

outlierDetection.consecutiveErrors: 拒绝连接的最大失败次数

outlierDetection.interval: 触发熔断的时间间隔,在 interval 时间间隔内,达到 consecutiveErrors 即触发熔断

outlierDetection.baseEjectionTime: 熔断时长

maxEjectionPercent: 熔断连接最大百分比

目录
相关文章
|
Kubernetes 安全 API
Istio安全架构(一)
Istio安全架构(一)
|
运维 监控 负载均衡
Istio 介绍
当下,微服务架构在构建和部署现代应用程序时变得越来越流行。然而,微服务架构的复杂性也随之增加,特别是在涉及到服务间通信、负载均衡、安全性和监控方面。在这个复杂的环境中,Istio成为了一个强大的工具,它可以帮助您管理和控制微服务应用程序的各个方面。本文将详细介绍Istio,并探讨其核心功能和优势。
|
负载均衡 Kubernetes API
Istio:Gateway设计与实现
Istio:Gateway设计与实现
1002 0
Istio:Gateway设计与实现
|
3月前
|
Kubernetes 网络协议 安全
Istio安全-证书管理
Istio安全-证书管理
44 1
Istio安全-证书管理
|
Prometheus 负载均衡 Kubernetes
Service Mesh: Istio vs Linkerd
根据CNCF的最新年度调查,很明显,很多人对在他们的项目中使用服务网格表现出了浓厚的兴趣,并且许多人已经在他们的生产中使用它们。近69%的人正在评估Istio,64%的人正在研究Linkerd。Linkerd是市场上第一个服务网格,但是Istio使服务网格更受欢迎。这两个项目都是最前沿的,而且竞争非常激烈,因此选择一个项目是一个艰难的选择。在此博客文章中,我们将了解有关Istio和Linkerd体系结构,其运动部件的更多信息,并比较其产品以帮助您做出明智的决定。
153 0
|
Rust Kubernetes 安全
Linkerd,其实也很 Diao 的
在之前的文章,我们介绍了有关 Service Mesh (服务网格)微服务生态体系中的 2个核心成员 Linkerd 和 Istio ,具体可参考相关链接:微服务之 Service Mesh浅析 以及 Service Mesh 体系解析。对于2者,其都是围绕“ Control Plane (控制平面)” 和“ Date Plane (数据平面)” 展开。
185 0
|
负载均衡 Kubernetes 监控
[Istio是什么?] 还不知道你就out了,40分钟快速理解(上)
[Istio是什么?] 还不知道你就out了,40分钟快速理解
186 0
|
负载均衡 Kubernetes 网络协议
[Istio是什么?] 还不知道你就out了,40分钟快速理解(下)
[Istio是什么?] 还不知道你就out了,40分钟快速理解(下)
112 0
|
数据采集 Prometheus 监控
ISTIO telemetry V2 介绍
### 背景 ISTIO 早期版本(1.4以前)的架构非常优雅, 模块之间解耦清晰,职责分明。 但现在看来有一定理想化,所有流量通过Mixer,通过Mixer 统一采集和上报所有的遥测数据和服务间访问鉴权,导致一旦规模上来,Mixer 非常容易成为性能瓶颈。 ![image.png](https://ata2-img.cn-hangzhou.oss-pub.aliyun-inc.com/920
1714 0
|
负载均衡 Kubernetes 监控
[Istio是什么?] 还不知道你就out了,一文40分钟快速理解
这篇文章属于纯理论,所含内容如下,按需阅读: - `Istio概念、服务网格、流量管理、istio架构(Envoy、Sidecar 、Istiod)` - `虚拟服务(VirtualService)、路由规则、目标规则(DestinationRule)` - `网关(Gateway)、网络弹性和测试(超时、重试、熔断器、故障注入)`
381 0
[Istio是什么?] 还不知道你就out了,一文40分钟快速理解