 Hi, I'm Don Shang, Director of Developer Experience with Red Hat Developer. In this video series, we'll examine how the Istio service mesh works with Kubernetes and your microservices. In this particular video, I'll demonstrate how Istio route rules enable you to direct traffic between your microservices, make changes to those rules, and all while never changing your source code. For this video, we'll be following the route rules section of the Red Hat Developer Istio tutorial, which can be found at this URL. If you wish to follow along or try this tutorial on your own, you'll need to install some prerequisites. Start Minishift, install Istio, and get the referenced microservices up and running. I've already done that so we can jump right into Istio route rules. As you can see, I have three microservices running, including two different versions of the recommendation service. When I switch over to another terminal session and start a loop of curl commands against our example, you can see that by default Kubernetes is routing traffic to versions 1 and 2, 50-50, round robin, splitting the traffic. Now we can introduce the power of Istio route rules. And one thing to always keep in mind is that at no time will we need to change our running code, only our Istio configuration. And since we're not changing source code, we know we won't be introducing bugs or defects. So the first route rule will direct all traffic to version 2 of the recommendation service and ignore version 1. But before implementing it, let's take a look at it. Looking at this configuration file, notice near the bottom that the route is looking for a label of version V2. It's weighted such that 100% of the traffic is directed to it, version 2. Note that if you had multiple routes listed here, the total weight has to equal 100. Also note near the top of the listing, the name of the route rule, recommendation default. The name here does not need to match the name of the file. However, this example might not be a best practice. In fact, since a file may contain multiple configurations, it's a good idea to give a lot of thought to a logical, hierarchical naming strategy. For now it's a tutorial, so we'll give ourselves some slack. Looking at the pods and their labels, we can see that the last pod listed is the one that's going to fulfill this routing configuration. We should expect recommendation version 1 to basically be ignored. Let's go ahead and create this entry, and then we'll switch over to the other terminal session and see the results. If I start a loop of curl commands against our solution, we can now see that recommendation version 2 is the one being routed to. Now, let's implement a route rule that does just the opposite. Let's direct all traffic to version 1. If we switch to the curl loop, now you can notice that all the recommendation traffic is going to version 1. Again, we did this all with route rules. We didn't change any code. Let's go back to the command line, and we'll notice a few things. First, notice that instead of using the Istio create command, we used the replace command. This is because the route rule names are the same, and we're replacing an existing route rule instead of creating a new one. Notice also that I can retrieve the contents of the YAML file by using the command line rather than looking at the file. And if you look at the contents, as you've probably figured out by now, it's the same as before except for at the bottom we're looking for version 1 of the label instead of version 2. Up to this point, using route rules, we've only been using one version of the microservice or the other. When we remove the route rule, we go back to the default Kubernetes behavior where traffic is split 50-50 between the two services. And when we switch to the curl loop, we can watch it go back to the 50-50 split. Now let's put the route rule to work. In the case of a canary deployment, you might want to send traffic unevenly between the two versions. For example, let's direct 90% of the traffic to version 1 and only 10% of the traffic to version 2. Let's take a look at that route rule. Now let's go ahead and create this route rule and check the results. As we start the curl loop and watch it, you can see the 90-10 split starting to take effect. As you've figured out by now, we could easily update this route rule to, say, 75-25 split, then 60-40 and 50-50 and so on, basically carrying out a canary deployment. And again, this is important to remember we did all this with no code changes. I hope this video helps you see the simplicity and power of Istio route rules and I trust you'll be willing to give this a try. Visit the URL mentioned at the beginning of this tutorial to start learning and experimenting with Istio today. And also check out our free e-book. Thank you.