Istio - TrafficManagement - Retries

简介: Retries 是在服务请求的过程中产生异常后最简单的处理方法,就是让服务再次重试,通过重试可以提供服务的可用性和健壮性。

>  Retries 是在服务请求的过程中产生异常后最简单的处理方法,就是让服务再次重试,通过重试可以提供服务的可用性和健壮性。


#### 什么场景需要用到重试

重试是解决很多请求异常最直接、简单的方法,尤其是在工作环境比较复杂的场景下,克提高总体的服务质量。重试使用不当也会有问题,最糟糕的情况是重试一直不成功,反而增加延迟和性能开销。所以根据系统运行环境、服务自身特点,配置适当的重试规则显得尤为重要。


#### 通过例子来理解

image.jpeg

nginx 服务访问 httpd 服务,但 httpd 服务由于自身故障错误响应 nginx 服务,nginx 服务为了提高容错率则在等待了15秒之后重新发起第一次重试,如果还是为有响应,则在试第二次,如果还是没有响应则请求失败。在大多数场景下,由于故障不是恒定的,而是瞬时出现而后自动恢复的,则可以通过重试去提供服务的可用性。


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: apps/v1
kind: Deployment
metadata:  labels:    app: httpd-deployment
  name: httpd-deployment
spec:  replicas: 1  selector:    matchLabels:      app: httpd-deployment
  strategy:    rollingUpdate:      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  template:    metadata:      labels:        app: httpd-deployment
    spec:      containers:        - image: 'httpd:latest'          name: httpd-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: v1
kind: Service
metadata:  name: httpd-service
spec:  selector:    app: httpd-deployment
  type: ClusterIP
  ports:  - name: http
    port: 80    targetPort: 80    protocol: TCP
---apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:  name: nginx-vs
spec:  hosts:  - nginx-service
  http:  - route:    - destination:        host: nginx-service
    retries:      attempts: 3      perTryTimeout: 5s
---apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:  name: httpd-vs
spec:  hosts:  - httpd-service
  http:  - fault:      abort:        percentage:           value: 100        httpStatus: 503    route:    - destination:        host: httpd-service
```
##### 配置 nginx 反向代理 httpd 以完成上下游调用的效果kubectl exec -it nginx-deployment-56c94b9957-xgw88 -- sh
tee /etc/nginx/conf.d/default.conf <<-'EOF'server {    listen 80;
    server_name localhost;
    location / {        proxy_pass http://httpd-service;
        proxy_http_version 1.1;
}}EOF
nginx -t ; nginx -s reload
##### 进入客户端容器测试```yaml
apiVersion: apps/v1
kind: Deployment
metadata:  labels:    app: client-deployment
  name: client-deployment
spec:  replicas: 1  selector:    matchLabels:      app: client-deployment
  strategy:    rollingUpdate:      maxSurge: 25%
      maxUnavailable: 25%
    type: RollingUpdate
  template:    metadata:      labels:        app: client-deployment
    spec:      containers:        - image: 'busybox:latest'          name: client-deployment
          command: ["/bin/sh","-c","sleep 3600"]

通过 ``kubectl exec -it client-deployment-56c94b9957-xgw88 -- sh`` 进入容器

执行 ``wget -q -O - http://nginx-service`` 测试

image.jpeg


执行 ``kubectl logs -f nginx-deployment-86684f9cf6-lvxtj  -c istio-proxy -n demo`` 观测边车日志

image.jpeg

本身请求一次,加上三次重试



#### 重试相关参数配置

##### retries 参数

可以定义请求失败时的策略,重试策略包括重试次数、超时、重试条件

attempts: 必选字段,定义重试的次数

perTryTimeout: 单次重试超时的时间,单位可以是ms、s、m和h

retryOn: 重试的条件,可以是多个条件,以逗号分隔


##### retryOn 参数

5xx:在上游服务返回5xx应答码,或者在没有返回时重试

gateway-error:类似于5xx异常,只对502、503和504应答码进行重试

connect-failure:在链接上游服务失败时重试

retriable-4xx:在上游服务返回可重试的4xx应答码时执行重试

refused-stream:在上游服务使用REFUSED_STREAM错误码重置时执行重试

cancelled:gRPC应答的Header中状态码是cancelled时执行重试

deadline-exceeded:在gRPC应答的Header中状态码是deadline-exceeded时执行重试

internal:在gRPC应答的Header中状态码是internal时执行重试

resource-exhausted:在gRPC应答的Header中状态码是resource-exhausted时执行重试

unavailable:在gRPC应答的Header中状态码是unavailable时执行重试。

目录
相关文章
|
运维 监控 负载均衡
Istio 介绍
当下,微服务架构在构建和部署现代应用程序时变得越来越流行。然而,微服务架构的复杂性也随之增加,特别是在涉及到服务间通信、负载均衡、安全性和监控方面。在这个复杂的环境中,Istio成为了一个强大的工具,它可以帮助您管理和控制微服务应用程序的各个方面。本文将详细介绍Istio,并探讨其核心功能和优势。
|
负载均衡 Kubernetes API
Istio:Gateway设计与实现
Istio:Gateway设计与实现
1002 0
Istio:Gateway设计与实现
|
Kubernetes 测试技术 应用服务中间件
Istio简介及基于ACK安装Istio
了解服务网格开源产品Istio,使用阿里云ACK安装Istio过程
1138 2
|
网络协议 应用服务中间件 nginx
玩转Kubernetes TCP Ingress
如何使用Kubernetes的TCP Ingress
19861 0
|
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
|
负载均衡 Kubernetes 网络协议
[Istio是什么?] 还不知道你就out了,40分钟快速理解(下)
[Istio是什么?] 还不知道你就out了,40分钟快速理解(下)
112 0
|
负载均衡 Kubernetes 监控
[Istio是什么?] 还不知道你就out了,40分钟快速理解(上)
[Istio是什么?] 还不知道你就out了,40分钟快速理解
186 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的timeout问题
kubernetes+alpine+php特别容易出现访问外网/解析外网地址的时候出现超时的问题.
4492 0