Menu Close

In this article we are going to explore the traffic management concepts of Istio with some use cases like static/dynamic routing and canary deployments in GKE. Sample book store application installed in the GKE in the article “ Configure Istio Service Mesh in GKE “ will be used while illustrating the use cases.

BookInfo is a simple mock bookstore application made up of four microservices – all managed using Istio. Each microservice is written in a different language, to demonstrate how you can use Istio in a multi-language environment, without any changes to code.

The microservices are:

  • productpage: calls the details and reviews microservices to populate the page.
  • details: contains book information.
  • reviews: contains book reviews. It also calls the ratings microservice.
  • ratings: contains book ranking information that accompanies a book review.

The microservices are:

  • productpage: calls the details and reviews microservices to populate the page.
  • details: contains book information.
  • reviews: contains book reviews. It also calls the ratings microservice.
  • ratings: contains book ranking information that accompanies a book review.

Version 1 : No Ratings Service

Version 2:  with Ratings Service displayed in black stars

Version 3:  with Ratings Service displayed in Red stars

Use case 1: Testing Normal Kubernetes behavior

Step 1) Refresh the page (IP/productpage) several times, three different versions of review screen will be shown in the product page in the round-robin style. Since there are no traffic or routing settings done, default round robin behavior is exhibited in this use case.

Version 1 : No Ratings Service
Version 2:  with Ratings Service displayed in black stars
Version 3:  with Ratings Service displayed in Red stars

Use Case 2: Change Request Routing

Routes control how requests are routed within an Istio service mesh. Requests can be routed based on the source and destination, HTTP paths and header fields, and weights associated with individual service versions. Available versions, called subsets, should be defined in destination rules for Istio to control the routing. Run the following command to create default destination rules for the Bookinfo services

kubectl apply -f samples/bookinfo/networking/destination-rule-all-mtls.yaml

2.1 Static Routing Use case

VirtualService for each microservice needs to be created. A VirtualService defines the rules that control how requests for the service are routed. Virtual service is created to send traffic only to version: v1 of the app. This version 1 app shows no Ratings in the screen.

kubectl apply -f samples/bookinfo/networking/virtual-service-all-v1.yaml

Use the below command to verify the rules. Add -o yaml to view the actual configuration.

Kubectl get virtualservices

kubectl get destinationrules

Access the product page, it will display the review page without ratings.

2.2 Dynamic Routing Use Case

Service mesh operates at Layer 7, HTTP attributes (paths or cookies) to decide on how to route a request. In this example, certain Users of the application e.g., user name : Jason is routed to a service by applying regex to a header.

kubectl apply -f samples/bookinfo/networking/virtual-service-reviews-test-v2.yaml

Get status: kubectl get virtualservices reviews

Access the product page with username and password as “Jason”.

Version V2 of the application which has black color ratings can be seen. This means based on User name Regex the Istio Traffic management automatically routes the request for Version 2 of the application. 

Use Case 3: Canary Deployment

Use the below command to send the 50% traffic to Version V3 and 50% of the Traffic to Version v1.

kubectl apply -f samples/bookinfo/networking/virtual-service-reviews-50-v3.yaml

Version V1 Screen

Version V3 Screen

Use the below command to send 100% traffic to Version v3(red color review)

kubectl apply -f samples/bookinfo/networking/virtual-service-reviews-v3.yaml

Other Advanced cases

In Addition to the above use cases, Istio Traffic Management can be used to manage Timeouts, retries, Inject faults and introduce circuit breakers.

Timeouts and retries

The Default timeout for HTTP requests is 15 seconds, but it can be overridden in a Istio route rule. In addition, we can also specify the number of retry attempts for an HTTP request in a route rule. The maximum number of retry attempts, or the number of attempts possible within the default or overridden timeout period in Istio Traffic Rules

Fault Injection

A route rule can specify one or more faults to inject while forwarding HTTP requests to the rule’s corresponding request destination. The faults can be either delays or aborts.  For example, we can introduce a 5 second delay in 10% of the requests to the “v1” version of the ratings microservice app. In addition, we can also introduce an abort, to prematurely terminate a request and simulate a failure. For example, we can configure we can inject HTTP 400 error code for 10% of the requests to the identified microservice.

Circuit breakers

Circuit breaking is an important pattern for creating resilient microservice applications. Circuit breaking allows you to write applications that limit the impact of failures, latency spikes, and other undesirable effects of network peculiarities.  In Istio Traffic Rules Circuit breaker can be set based on several conditions such as connection and request limits. For example, in a DestinationRule we can set a limit that only 100 connections are allowed for the identified Microservice.

Refer Istio Documentation for configuring the rules for the above advanced use cases.

Posted in post categories

Related Posts

Leave a Reply

Your email address will not be published. Required fields are marked *