Traffic Management Example with Istio

Introduction to Traffic Management in Istio

Istio’s traffic routing rules permit you to efficiently manage the traffic flow and API calls between services. Istio simplifies the configuration of service-level properties and makes it simple to line up vital tasks like testing, and different rollouts. It additionally provides intuitive and innovative reliability features that help make your application more resilient against bugs of dependent services or the network.

Istio’s traffic management concept is based on the Envoy proxies deployed along with your services. All data plane traffic (essentially the traffic that your service mesh sends and receives) is proxied through Envoy. This facilitates the direct and controlled traffic around your mesh without having to make any changes to your services.

How does Istio’s Traffic Management work?

First, it is important to know that to be able to direct traffic within your mesh, Istio needs to know where all your endpoints are, and which services they belong to. Istio connects to a service discovery system to be able to establish its own service registry. For example, if you’ve installed Istio on a Kubernetes cluster (Managed Kubernetes Service) that we’ve previously discussed in our blog, then Istio automatically detects the services and endpoints in that particular cluster.

The Envoy proxies direct traffic to the relevant services by using the service registry. Typically, microservice-based applications have numerous instances of each service workload to handle service traffic, generally stated as a load-balancing pool. Envoy proxies’ role is to distribute traffic across each service’s load-balancing pool.

Istio’s service discovery and load balancing give you a working service mesh but keep in mind that Istio can do so much more in terms of traffic control. You have the ability to apply fine-grained control over what happens to your mesh traffic. For example, you can add an external dependency of your mesh to the service registry or apply special rules to traffic coming into or out of your mesh. You can do this and so much more by adding your own traffic configuration to Istio using Istio’s traffic management API.

Like other Istio configurations, the API is specified using Kubernetes custom resource definitions (CRDs), which you can configure using YAML, as you’ll see in our example.

You may review each of the traffic management API resources and what you can do with them here. The rest of this guide examines our Traffic Management Example.

Istio Traffic Management Example

Let’s review the Traffic Management concept of Istio. First, we will download the repository we have prepared for the example:

$git clone https://github.com/BKirov/istio.git

Secondly, we have to enter the Istio folder. Then, we are going to deploy the sample bookinfo application:

$kubectl apply -f bookinfo.yaml

It is important to check if it is working locally with the following command:

$ kubectl exec "$(kubectl get pod -l app=ratings -o jsonpath='{.items[0].metadata.name}')" -c ratings -- curl -sS productpage:9080/productpage | grep -o "<title>.*</title>"

You may see in the example above that it is working perfectly. We are now going to open the application.

1 . We will create an Istio Ingress Gateway to make the application accessible online.

$ kubectl apply -f bookinfo-gateway.yaml

Then we can take the IP like this:

$ kubectl -n istio-system get service istio-ingressgateway

We will enter the address in our browser and the output should look like this:

Now we have the working application open up and running online.

2. Let’s take a look at the two files named – destination-rule-all.YAML and virtualservices-all-v1.yaml

A VirtualService defines a set of traffic routing rules to apply when a host is addressed. Each routing rule defines matching criteria for the traffic of a specific protocol. If the traffic is matched, then it is sent to a named destination service (or subset/version of it) defined in the registry.

Have a look at the Review Section of the product page applications.

Then open the virtual-service-all-v1.yaml and change the VirtualService for review section from v1 to v3:

Version: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  http:
  - route:
    - destination:
        host: reviews
        subset: v3

This automatically leads the subset v3 in the destination-rule-all.yaml file

kubectl apply -f virtual-service-all-v1.yaml

Then refresh the browser page and the review section was changed.

This is an example of how the Istio Traffic Management concept works with Virtual Services and Destination Rules.

For more expert blog posts check our ITGix blog. For questions or consultation on a specific use case, don’t hesitate to contact us.