Request routing through VirtualService and destination rules - Kubernetes Tutorial

- [Instructor] Now let's take a moment to refresh the book info application. In my use case, it's listening on port 80, so I will go to localhost/productpage. Let's refresh multiple times. And as we are refreshing, did you notice what is happening? Take a look at the written section, the Book Reviews section. Each time I refresh, we are served by different version of the service. Sometimes it shows the red star, which is review version 3. And sometimes it doesn't show any review, which is review version 1, and sometimes shows the black writing, which is reviews version 2. This is because Istio is routing traffic to different versions of the review service using a round-robin approach. Now, the good news is that it still let us take the control of this behavior. We can decide which version of a service users see, and this makes things consistent and predictable, and even flexible for us. So far in previous videos, we've talked about traffic management with VirtualServices and destination rules. And in the last video, we set up waypoint proxy in ambient mode. This is going to help us with some Layer 7 routing and make it flexible. Now, let's use what we've learned in the previous videos to configure Istio request routing. Our goal in this video is to send all traffic to version 1 of the reviews version. Let's jump in and see how it's done. Take a look at the directory 03_05. There, you'll see the files we are using for this video. Before we configure Istio to route traffic, we need to define the service versions. This is done using subsets in the destination rules. But how does Istio know what these subsets are? The answer lies in the deployment labels. Let's take a look at the deployment manifests that we used to deploy our bookinfo application in the previous video. Notice the app label, for example, for review service, it has a app label reviews, which identifies the service name. And we then have a version label, version 1, which specifies the version. It still uses these labels to map subsets in the destination rules. And this allows us to route traffic specifically to version 1 of the reviews service. Let's take a look at the subsets in the destination rule. In this destination rule, each subset defined here, for example, from line 18, we have subsets name v1 with label version v1, and we also have subsets for v2 and subset for v3. Each of these subsets is linked to the version label that we saw in our deployment, version label in the deployment. So with these subsets defined in the destination rules, we can route all traffic to version 1 using VirtualService. Let's take a look at our VirtualService. This is an example VirtualService that routes traffic to subset v1 that we defined in the destination rule. Let's head over to the terminal and apply this configuration and see it in action. I'm in the directory 03_05 that we just went through. The first thing we are going to do is to apply the destination rule with kubectl apply -f, destination-rule file in the bookinfo namespace. Let's confirm our destination rule. Yes, we can see it got created, but let's confirm what got created. Yes, we can see our subsets are defined in the destination rule, version 1, version 2, and version 3. Let's clear our screen. The next thing we are going to apply is the VirtualService kubectl apply -f, all the VirtualService in the bookinfo namespace. Yes, our VirtualServices have been created and we will do the same thing to confirm the VirtualServices. We can see our VirtualServices got created 12 seconds ago. We can check the YAML. Yes, we have the VirtualService with the destination rule tied together here. We are going to route traffic to only version 1 of review service, the rating service, version 1 of all the services basically. Now let's confirm our routing has been configured properly. We can confirm this by going to the browser and refresh again. We should only see version 1 because that's what we've configured. As you can see after multiple refresh, only version 1 comes up here. I'll refresh again. Yes, that's working as expected. Another way to confirm this is to go to our Kiali dashboard. My Kiali is listening on local host ports 2001/kiali. Let's visit the traffic graph. As we can see, only version 1 of the review service shows up here as well. We don't have version 2 and we don't have version 3. This confirms that our routing is working as expected and all traffic is going to only version 1. Now, imagine you're rolling out a new feature and you want to make sure only certain users can see it. How do you do that with Istio? We would route traffic based on user identity. Specifically, we are going to route all traffic from a username jasmine to review version 2, which includes the star ratings feature. Meanwhile, all other users will still see reviews version 1, which doesn't have the star ratings. The product page service in the bookinfo app has a custom HTTP header called end-user to every request, and we are going to use this header in Istio to control where traffic goes. The goal of this video is that Jasmine will be able to see reviews version 2 with the star ratings and every other user will see version 1. Let's look at the configuration to make this happen. I'm in the directory 03_05, and it has the manifest we are going to use for this session. Let's cat the file. In this VirtualService, we have set up a rule that says if the end-user is jasmine, route the traffic to reviews version 2. If it is any other user, route the traffic to reviews version 1. Now let's apply this rule using the command kubectl apply -f the name of our file in the bookinfo namespace. Yes, our VirtualService has been created. Let's confirm we actually got it created using kubectl get virtualservices reviews -o yaml. Yes, we can see our VirtualService was created and we can see that we have the match, header, end-user, exact is, of course, jasmine. Now to test this, we'll go back to our browser, access the bookinfo application, refresh it, and log in as user jasmine. with the password. We can see user jasmine is able to access review version 2. We'll refresh multiple times after logging in as user jasmine. You would see that in the book review session, we are only being served by reviews version 2 because we are logged in as user jasmine. I'm going to log out and log in as another user, let's say the user dave. User dave is logged in now and user dave can see review 1. User dave can only see review 1. That's what configured in our routing. Let's go back to our routing to confirm. We configured our routing that anytime user jasmine logs in, she should be served with review version 2, and anytime any other user logs in, they should be served with review version 1, which is exactly what we just saw in the bookinfo application. And that's how simple it is to route traffic based on user identity in Istio. By using custom HTTP headers, we can give specific users a special experience while keeping everyone else on the default parts.