Teacher idou teaches you to learn Istio12: Istio implements traffic mirroring

Teacher idou teaches you to learn Istio12: Istio implements traffic mirroring


Microservices have brought us excellent features for rapid development and deployment, and how to reduce the risk of development and change has become a problem. Istio's traffic mirroring, also known as shadow traffic, is to copy production traffic mirroring to a test cluster or a new version. Test before directing real-time traffic, which can effectively reduce the risk of version changes.

Traffic mirroring has the following advantages:

1. When traffic is mirrored to different services, it will occur outside the critical path of the request, so that any problems caused by traffic mirroring will not affect production;

2. Ignore the response to any mirrored traffic ; The traffic is regarded as "send and forget", so that it will not interfere with the response of normal production traffic;

3. When the traffic is mirrored, the request will be sent to the mirroring service through its host/authorization header and attached-shadow It is used to distinguish where the traffic is mirrored from;

4. Using real-time production use cases and traffic can have a more realistic test service environment, which effectively reduces the risk of deployment; here

are several typical usage scenarios that can play a role in traffic mirroring Advantages:

1. For testing: the test cluster can use the real traffic of the production instance, and will not affect the critical path of normal production.

2. Used for new version verification: can compare the output results of production flow and mirroring flow in real time.

3. Used for version rollback of collaboration service: When the service that uses mirrored traffic needs to modify the collaboration service, because the mirroring mode adds the -shadow flag, the mirroring request can be processed normally and rolled back before submission. The change of the mirror version will not affect the production version.

4. Isolate the test database: For services related to data processing, you can use empty data to store and load test data, and perform mirroring traffic operations on the data to achieve isolation of test data.

Let's demonstrate through an example.

First , let all traffic reach the v1 version, and then use the rules to mirror the traffic to the v2 version: Environment preparation: two application mirroring

steps : httpbin and tutum/curl are required. Step 1 (Configure and start the service):

First deploy two versions of httpbin service:

httpbin-v1:



httpbin-v2:



Deploy the sleep service to provide load for curl:



After completing the above configuration files, you can use kubectl create -f ./yourconfig.yaml to start the service, and use kubectl get pod to view the running status of the service:



Start httpbin service:

first check whether there is an httpbin service through kubectl get svc. If the service has been created, you need to delete it with kubectl delete service httpbin, and create a new service through the yaml shown in the figure below:



Step 2 (Create routing strategy):

1. Use kubectl delete virtualservice httpbin, kubectl delete destinationrule httpbin to delete the existing httpbin strategy, and create a new routing strategy through the yaml shown in the figure below, and import all the traffic to the v1 version:



Take effect through kubectl create -f ./yourrules.yaml:



2. Now that the service has been set up, we send some traffic to the service:



3. Check the logs in the pod of httpbin's v1 and v2 respectively:



We can find that there is a record of traffic access in the v1 pod, and the log in the v2 pod is empty, indicating that the traffic has not entered the v2 pod, which matches our policy of importing all the traffic into v1.

Step three (mirroring traffic):
  1. Modify the routing rules to mirror the traffic to the v2 service:




Delete the previously deployed virtualservice rules, and deploy the yaml in the above figure with kubectl create -f, where the mirror field specifies the traffic mirroring to the v2 service.

2. Send traffic: send traffic

through the command

kubectl exec -it $SLEEP_POD -c sleep - sh -c'curl http://httpbin:8080/header s'| python -m json.tool:



3.View the access logs of v1 and v2:



By comparing the recorded timestamps, we can find that after the policy is changed, the traffic of v1 is mirrored to v2. The v2 packet in the log is larger than v1 because the traffic is marked as shadow traffic.

Step 4 (Clear):

1. Clear routing rules:

kubectl delete virtualservice httpbin

kubectl delete destinationrule httpbin

2. Close httpbin/sleep service:

kubectl delete deploy httpbin-v1 httpbin-v2 sleep

kubectl delete svc httpbin

Through the above steps, we know how to set Routing rules to introduce traffic mirroring.

For related services, please visit support.huaweicloud.co..._2019