Istio Route Rules: Telling Service Requests Where To Go

OpenShift and Kubernetes do a great job of working to make sure calls to your microservice are routed to the correct pods. After all, that’s one of the raison d’être for Kubernetes: routing and load balancing. What if, however, you want to customize the routing? What if you want to run two versions at the same time? How do Istio Route Rules handle this?

Route rules are, well, rules that determine routing. While the possible configurations can get quite complicated, the overall functionality remains simple: route the request based on certain parameters and HTTP header values. Let’s look at some examples.

Kubernetes default: 50/50 Split

This example allows you to use two versions of a microservice. Let’s call them “v1” and “v2”, running in OpenShift. With each running in its own Kubernetes-managed pod, the default behavior is an evenly balanced, round robin routing. Each pod will receive a percentage of requests based on its number of microservice instances, or replicas. With Istio we can change that balance.

For this example, we have two deployments of our “recommendation” service running in OpenShift, named “recommendation-v1” and “recommendation-v2”.

In Figure 1, we see the results of each service running one instance of their respective microservices with an even distribution between them. Looking at the screen capture, you can clearly see the 1–2-1-2-… pattern. This is the default routing from Kubernetes:

Multiple Versions, Weighted Distribution

In Figure 2, we see the results after increasing the number of v2 replicas to two (the command is oc scale --replicas=2 deployment/recommendation-v2). As you would expect, the mix is now 1/3 for v1, 2/3 for v2. The 1-2-2-1-2-2-… pattern is obvious:

Ignoring a Version with Istio

Using Istio, we can alter this distribution just about any way we please. For example, we can direct all traffic to recommendation-v1 using the following Istio yaml file:

Here are some things to notice. The pods are selected by using their labels. In this example, the “v1” label is being used. The weight is 100; meaning 100% of the traffic will be routed to all recommendation pods with the v1 label.

Uneven Version Split (Canary Deployment)

Next, using the weight parameter, we can direct traffic to both pods without regard to the number of microservice instances running in each. For example, here we are directing 90% of the traffic to v1 and 10% percent to v2:

Mobile Users Only

For our final example, we’ll route mobile users to v2, while everyone else is directed to v1. This is done by using a regular expression to choose the client based on the user-agent value in the request header.

What can you do?

Seeing this example of using a regular expression to select a request based on information in the header should get the creative wheels turning. The power is unlimited, given that you can inject header values in to your source code.

Ops, not Dev

Keep in mind, all of this is happening without any changes to your code; excepting of course, the unique case where you inject values into the request header. Developers will benefit from the knowledge of Istio and will undoubtedly use it in developmental testing. In production, Istio configuration will most likely be a function of the operations team.

I cannot stress this enough: there are no changes to your source code. You do not need to build a new image or start a new container. This all happens outside of your source code.

Let Your Mind Wander

Because you can use regular expressions against the request header, just imagine how powerful that is. Want to direct your biggest customer to a special version of your microservice? How about those that use the Google Chrome browser? Pretty much any characteristic you want can be used to direct traffic.

Try it for yourself, for free

Reading about Istio, Kubernetes and OpenShift is one thing, but wouldn’t you rather give it a try for yourself? The Red Hat Developer Program team has put together a detailed and thorough tutorial that you can use immediately to jump into these leading technologies. It’s open source, so there’s no cost. It works on macOS, Linux and Windows, with source code in Java or node.js (with more languages coming soon). Point your browser to the Red Hat Developer Demo github repo and get started today.

Next: Gracefully Handling Problems

This is the power of Istio Route Rules. Now imagine if you could use this power to handle errors. That will be covered in our next blog post.
Stay tuned!