Retry of network elasticity

General Catalog Index: istio from getting started to giving up series

1. Introduction

Network elasticity, also known as operation and maintenance elasticity, refers to the ability of the network to quickly recover and continue to operate in the event of a disaster. The scope of disaster events is very wide, such as long-term power failure, network equipment failure, malicious, etc.

Istio retry mechanism is the maximum number of times the invoke agent attempts to connect to the service if the call fails. By default, the Envoy agent will not attempt to reconnect to the service after failure unless we start the istio retry mechanism.

2. Retry instance

2.1 architecture

The architecture is as follows. This example simulates the client calling nginx, which forwards the request to tomcat. tomcat aborts the external service through fault injection. Nginx sets that if the access to tomcat fails, it will retry 3 times.

2.2 client resources

apiVersion: apps/v1
kind: Deployment
metadata:
  name: client
spec:
  replicas: 1
  selector:
    matchLabels:
      app: client
  template:
    metadata:
      labels:
        app: client
    spec:
      containers:
      - name: busybox
        image: busybox
        imagePullPolicy: IfNotPresent
        command: [ "/bin/sh", "-c", "sleep 3600" ]

2.3 server resources

apiVersion: v1
kind: Service
metadata:
  name: nginx-svc
spec:
  selector:
    server: nginx
  ports:
  - name: http
    port: 80
    targetPort: 80
    protocol: TCP
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
  labels:
    server: nginx
spec:
  replicas: 1
  selector:
    matchLabels:
      server: nginx
  template:
    metadata:
      labels:
        server: nginx
    spec:
      containers:
      - name: nginx
        image: nginx:1.14-alpine
        imagePullPolicy: IfNotPresent
---
apiVersion: v1
kind: Service
metadata:
  name: tomcat-svc
spec:
  selector:
    server: tomcat
  ports:
  - name: http
    port: 8080
    targetPort: 8080
    protocol: TCP
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: tomcat
  labels:
    server: tomcat
spec:
  replicas: 1
  selector:
    matchLabels:
      server: tomcat
  template:
    metadata:
      labels:
        server: tomcat
    spec:
      containers:
      - name: tomcat
        image: docker.io/kubeguide/tomcat-app:v1
        imagePullPolicy: IfNotPresent

2.4 virtual services

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: nginx-vs
spec:
  hosts:
  - nginx-svc
  http:
  - route:
    - destination:
        host: nginx-svc
    reties:
      attempts: 3
      perTryTimeout: 10s
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: tomcat-vs
spec:
  hosts:
  - tomcat-svc
  http:
  - fault:
      abort:
        percentage:
          value: 100
        httpStatus: 503
    route:
    - destination:
        host: tomcat-svc

3. istio injection test

We need to inject Istio into the client and deploy resources, and put the client, nginx and tomcat into the grid. Here we use manual injection of Istio

istioctl kube-inject -f client.yaml |kubectl apply -f -

istioctl kube-inject -f test-nginx.yaml |kubectl apply -f -

After successful injection, the results are as follows

4. Modify nginx agent

 kubectl exec -it nginx-579d7f7ff-ggnxs -- sh

vi /etc/nginx/conf.d/default.conf

Load nginx configuration from new after modification

nginx -t
nginx -s reload

5. Case test

Login client to access nginx

kubectl exec -it client-8496866cdf-8k6pv -- sh

wget -q -O - http://nginx-svc

Open another console to output nginx logs

Reference article: https://blog.51cto.com/14625168/2498681

Tags: Nginx Tomcat network Docker

Posted on Tue, 02 Jun 2020 13:00:33 -0400 by flyersun