Network Traffic Shifting
In this tutorial, we are going to discuss about network traffic shifting in Istio service mesh. Before going to this tutorial, you need to understand book details sample application.
So , Now I do have the sample application deployed with the default destination rules. Let’s go ahead and access the application using the port that we had generated.
$ echo $INGRESS_HOST 192.168.1.50
$ echo $INGRESS_PORT 31214
So this is the ingress port that we had and the IP address. I’m going to use the external IP address and access it within the web page.
Since I do have access to that specific port , basically I do have access to all the ports, so I should be in a position to access it /productpage will take me to the product page.
So I’m accessing the page. This time it’s not having any review. That means it landed with version 1. Let me access it once again.
Now I do have red color star. That means it landed with version 3. Let me access it once again.
Now I do have black color star. That means it landed with version 2. The reason, because the destination rule when we initially created I am allowing the traffic equally getting distributed across all these 3 subsets that is 3 versions, version 1, version 2 and version 3.
So the traffic is getting distributed across all the three subsets that is 3 version of review. Let me go ahead and access the same page n number of times and generate enough traffic.
So before that I’m going to access the Jaeger and Kiali UI and check the details about the application. Let me get into the Kiali UI.
So I do have 4 applications in default namespace. Let me get into the application.
So these are all the applications that got deployed. I can get into the graph and see the details.
Here this is going to give even much better clarity where I do have access to this particular version 1. And that is accessing the detail page. Details page is having 1 subset and version 1 of product page is accessing the reviews. Reviews having 3 subset. Version 1 of the review is not going to get the ratings.
So I do not have call to the ratings and version 2 is going to call the rating and version 3 also going to call the rating.
So here I do have the virtual service where I have configured all the request landing up with the product page where to get routed.
Now I am interested in this particular area that is traffic animation where I wanted to get the traffic how it is getting routed through this particular application. I wanted to get for the last 1 minute and every 10 seconds this particular screen should get refreshed.
Let me go ahead and generate the traffic now. I’m going to execute the following url product page 100 times using the for loop sequence.
$ for i in
seq 1 100; do curl -s -o /dev/null http://$GATEWAY_URL/productpage; done
So this is going to generate hundred request. Now, let me access the web UI.
I will be in a position to see the traffic getting shifted. So through the ingress I am getting into the traffic is getting into the details as well as to the reviews and the traffic is getting distributed between the 3 subsets.
In case if I wanted to get the percentage of the traffic, I can enable the traffic percentage.
Changing the destination rules
Now we are going to see the very interesting part of changing the destination rules within the virtual service.
Let me go ahead and make the change. (Refer here for YAML). Here what I’m going to do, I am going to route all the request to the version 1 of the rating. So basically, I’m going to route all the traffic to the version 1 subset only. So I’m not making any change to the existing application. All I’m going to do is change the virtual service. Let me go ahead and apply.
$ kubectl apply -f samples/bookinfo/networking/virtual-service-all-v1.yaml virtualservice.networking.istio.io/productpage created virtualservice.networking.istio.io/reviews created virtualservice.networking.istio.io/ratings created virtualservice.networking.istio.io/details created
So the virtual service destination rules got changed and it’s going to send only to the version 1 and we do have multiple version only for the ratings. Now, let me go ahead and access the web page.
I’m not getting any reviews. That means it landed in version 1. Let me access it once again, one more time.
So any number of time I am going to access the request, It’s landing in version one only. You can go ahead and generate hundred requests to the product page using for loop sequence.
Now you access the Kiali web UI and see the traffic how it is getting generated. Here You can very clearly see all the request that’s coming into this particular review is landing in version one only.
So this is the biggest advantage of Istio where I have configured the destination rules to land the traffic only in version 1 dynamically.
What’s going to happen?
So what’s going to happen architecturally? Any change that I am making using the yaml file, The control plane will trigger the event saying there are some changes happened and the pilot going to send those changes to all the envoy that got registered along with that particular pod.
So the pod that is running in the product page will take care of not to send the traffic to the version 2 and version 3. It will route the traffic only to version 1.
This is where the role of pilot comes into picture, where it is going to make sure all the configurations are deployed into all the sidecar of all the pods as well as into the Ingress controller when I’m changing the gateway routes.
So we learnt about how to route the traffic only to a specific subset.
Now let’s go ahead and do another change where I’m going to route 50% of the request to the version 2 and another 50% to the version 1. We will do that by changing the yaml file by making the change to the service. So this is the yaml file that I’m going to apply.
So in this particular case, I am going to change the virtual service of reviews where I’m going to have the route destination for reviews into the subset version 1 where it will have weight-age of 50%. And another destination to the reviews of version 3 where it will have weight age of 50%. Let me go ahead and apply this particular yaml file.
$ kubectl apply -f samples/bookinfo/networking/virtual-service-reviews-50-v3.yaml virtualservice.networking.istio.io/reviews configured
And whenever you’re applying this particular change, you may have to wait for a few minutes, maybe 2 or 3 minutes, so that the pilot should trigger the configuration change and get that deployed into all the proxy. Now, you can go ahead and generate hundred request, access that through the web UI. Now, you should be in a position to see the traffic coming into product page. Yes, it’s coming into the product page and it is getting routed to version 1 and version 3 only. It should get equally distributed.
So over a period of time when I am having more number of requests automatically it should get distributed in 50 – 50% ratio.
This is the biggest advantage of using the Kiali web UI where I can quickly go ahead and verify what’s happening within the application. And especially while learning the Istio, after making the changes, we can visually see what’s happening within the application.
So what we have done, we created the sample application and we customized the virtual services specific to the service to route the traffic to any specific version or only a percentage of the traffic to that specific version.
This we will be using it within the canary deployment where I’m going to have a new version of the application. What I will do, I will deploy the version and I will route only a percentage of the traffic, say 10% of the traffic to that particular version. And I will test it out whether the behavior is good and if there are no bugs, then I will shift all the traffic to that particular version and remove the older version.
So without impacting the user, I should be in a position to deploy new versions into the cluster. So this is a quick demonstration on how to do the traffic shifting using Istio.