Network Traffic Shifting


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.

Network Traffic Shifting

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.

Network Traffic Shifting

Now I do have red color star. That means it landed with version 3. Let me access it once again.

Network Traffic Shifting

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.

Kiali Dashboard
Network Traffic Shifting Kiali Dashboard

So I do have 4 applications in default namespace. Let me get into the application.

Network Traffic Shifting

So these are all the applications that got deployed. I can get into the graph and see the details.

Network Traffic Shifting

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.

Network Traffic Shifting

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.

Traffic animation

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.

Traffic animation
Traffic animation

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.

Traffic animation

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.

Network Traffic Shifting

I’m not getting any reviews. That means it landed in version 1. Let me access it once again, one more time.

Network Traffic Shifting
Generate traffic

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.

Distribute traffic

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.

Conclusion

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.

Network Traffic Shifting
Scroll to top