Difficulty: Intermediate
Estimated Time: 20 minutes

Distributed systems are difficult to test. It can be time-consuming to reproduce the errors and situations when it's deep within the system. Based on the traffic management capabilities, it's possible for Istio to inject faults and simulate application errors or timeouts.

In this scenario, you will learn how to cause delays or failures for certain sections of the traffic to allow you to test how the rest of the system handles problems.

Simulating Failures Between Microservices

Step 1 of 4

Step 1 - Bookinfo Application

In this scenario we'll use the Istio BookInfo sample application. The application is composed of four microservices:

  • The productpage microservice is the homepage, populated using the details and reviews microservices.
  • The details microservice contains the book information.
  • The reviews microservice contains the book reviews. It uses the ratings microservice for the star rating.
  • The ratings microservice contains the book rating for a book review.

The deployment included three versions of the reviews microservice to showcase different behaviour and routing:

  • Version v1 doesn’t call the ratings service.
  • Version v2 calls the ratings service and displays each rating as 1 to 5 black stars.
  • Version v3 calls the ratings service and displays each rating as 1 to 5 red stars.

The services communicate over HTTP using DNS for service discovery. An overview of the architecture is shown below.

BookInfo Architecture

The application doesn't understand anything about Istio, Kubernetes or metrics. It could be deployed onto any system.

The Bookinfo application should have already been deployed to the Kubernetes cluster along with the Istio Control Plane.

You can view the application status via kubectl get pods

When you visit the Product Page you will only see the reviews coming from our the different deployed services.