Skip to content
Permalink
Branch: master
Find file Copy path
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
53 lines (34 sloc) 1.87 KB

Demo: Resiliency

Resiliency is part of the code: if an API call is not answered because of an error ar a timeout, the business logic must have some form of fallback. Istio helps to test resiliency by introducing faults into the mesh without changing the application code.

In order to demonstrate resiliency you can run the following commands to create a working set of services:

$ cd $PROJECT_HOME
$ scripts/check-prerequisites.sh
$ scripts/delete-all.sh
$ scripts/deploy-articles-java-jee.sh
$ scripts/deploy-web-api-java-jee.sh
$ scripts/deploy-authors-nodejs.sh
$ scripts/deploy-web-app-vuejs.sh
$ scripts/deploy-istio-ingress-v1.sh
$ scripts/show-urls.sh

After this the Web Application shows articles together with the author information:

The next script disables the Authors service by using Istio Fault Injection:

$ kubectl apply -f istio/fault-authors-500.yaml

It defines a rule in the Istio virtual service for Authors that responds with an HTTP Error 500 on every request (100 percent).

The articles are still displayed, but without author information. The fallback logic is: if the authors service doesn't work, show no authors information but also don't show an error.

The following command disables the articles service, too, again using Istio Fault Injection:

$ kubectl apply -f istio/fault-articles-500.yaml

Now every request to the articles services gets an HTTP error 500 as response. The same five articles are displayed, since they are cached in the web-api service. This is the fallback logic for the articles service.

To remove the Istio Fault Injection rules execute these commands:

$ kubectl apply -f istio/nofault-authors.yaml
$ kubectl apply -f istio/nofault-articles.yaml
You can’t perform that action at this time.