Traffic routing using Istio

Using istio virtual services to route traffic within microservices.

Photo by Denys Nevozhai on Unsplash

My stint with Istio started almost a year ago when I wanted to establish communication between a grpc client and grpc server residing in two different networks within a Kubernetes cluster. I have a post written about the same here. With time, I have gotten to know the various other capabilities of Istio and its broader usage within microservices-based application development.

As most of the application development is adopting to use of microservice-based architecture, it includes a lot of hassle for scenarios when the network between the two services is laggy, mandating each microservice to keep an eye on its fault tolerance by doing fault injection testing, adopting the use of circuit breaker pattern or safely deploying the service by doing canary rollouts of the application to observe the response time of application with periodic updates in the underlying microservice.

The key indicator of any microservice application is RED metrics which can be talked about in another post-in-depth. For now, let's focus on how traffic management with istio can solve all these issues for application developers by deploying a sidecar that is responsible for carrying out all the cross cutting features for any microservice application.

In the below scenarios, I am going to talk about three scenarios of application traffic routing achieved using istio virtual services.

use case1: Route all of the traffic to the only version of the service

Whenever we want to route all of the application traffic in any microservices to only one specific version, it can be achieved by adding a route to the version number in the subset as shown below where the value in the HTTP request header routes all of the incoming traffic to the designated version of the service. The envoy takes care to route the traffic as per the routing rules mentioned in the virtual service below.

- apiVersion: networking.istio.io/v1beta1   
  kind: VirtualService 
  metadata: 
   name: reviews 
   namespace: test
  spec:     
    hosts:     
     - reviews     
    http:     
    - route:       
      - destination:           
         host: reviews           
         subset: v1

use case 2: Weighted Routing

There are certain instances where part of application traffic needs to be routed to version 1 and the remaining to version2 of the service like in A/B testing and canary rollouts. This can be achieved by assigning weights to various versions of the service as shown below snippet where 60% of the traffic will be forwarded to the v1 service and the remaining 40% to the v2 version. In this manner, the requests are forwarded to the service instances according to a specific percentage.

This kind of scenario is helpful for A/B testing when the application team would want to review the performance metrics by releasing various versions of the web services and observing the RED metrics of the application.

- apiVersion: networking.istio.io/v1alpha3   
  kind: VirtualService 
  metadata: 
   name: reviews 
   namespace: test
  spec:     
    hosts:     
     - reviews     
    http:
    - route:       
      - destination:           
         host: reviews           
         subset: v1
        weight: 60
      - destination: 
         host: reviews
         subset: v2
        weight: 40

use case 3: User-based Routing

There could be some instances where the application service needs to be exposed to a certain set of users before making a production release to a larger group of users. This can be achieved by adding a custom header “end-user” and mapping it to the list of users for which the traffic will be routed to the v2 version in the below snippet and for all other users the traffic will be routed to the v1 version of the microservice.

This scenario is helpful for beta testing the application.

- apiVersion: networking.istio.io/v1alpha3   
  kind: VirtualService 
  metadata: 
   name: reviews 
   namespace: test
  spec:     
    hosts:     
     - reviews     
    http:  
    - match:  
      - headers: 
         end-user:     
           exact: ram
      route: 
      - destination: 
         host: reviews 
         subset: v2
    - route:       
      - destination:           
         host: reviews           
         subset: v1
        

Conclusion — The traffic routing capabilities of istio helps developers configure their microservice as per the needs of a specific set of users and allows for testing several versions of the service on staging and lower environment before making the production rollout. There are various other features of istio other than traffic routing like fault injection, circuit breaker, timeouts, and retries all of which constitute the smooth running of a microservice-based application that can be tried out from official istio documentation.