This repository contain exercises for the Istio service mesh. Exercises assume access to a Kubernetes cluster with Istio, Kiali and Jaeger tracing.

• Blue/green Deployments
• Blue/green Deployments Using Kubernetes Labels
• Canary Deployments
• Network Delay Investigations - Simple
• Network Delay Investigations - Larger Application Graph
• 🚧 WIP: Network Delay Investigations with Jaeger
• A Tour of the Istio Metrics

• Getting Traffic into the Mesh with Ingress Gateways
• 🚧 WIP: Getting Traffic out of the Mesh
• Multiple Teams and Separation of Duties
• Controlling Load Balancing
• Locality/Topology Aware Load Balancing and Failover
• Securing with Mutual TLS
• Debugging with Ephemeral Containers
• When not to use TLS
• Authorization - HTTP Network Policies
• Authentication with OIDC

• Circuit Breakers

• 🚧 WIP: Using gRPC

• Multi-mesh and Migrations

Exercises will cover the following deployment patterns:

• Blue/green. This pattern have multiple service versions deployed for test. Tests are being performed against different versions based on a deliberate choice of the version to use. I.e. this is typically used for tests being performed by testers or test frameworks.

• Canary. This pattern have multiple versions deployed for test and both/all versions are in active use. The version to use are determined on each request based on statistics, e.g. 1% of traffic should go to the test version. Typically its end-users that are being exposed to this.

Typically, blue/green and canary deployments are used in succession. First blue/green deployments are used to validate a new version in a production environment such that other production-dependencies can be included in the tests. When deliberate testing using blue/green deployments have proved the software to be OK, a larger group of users are exposed to the new version using canary deployments.

Another deployments pattern is:

• A/B testing. With this type of deployment, a certain percentage of end-users are exposed to a test version. This is typically used to test out different hypothesis, e.g. "a larger 'Buy' button makes users more liable to buy products".

The test application implements a simple 'sentences' builder, which can build sentences from the following simple algorithm:

age = random(0,100)
name = random(['Peter','Ray','Egon'])
return name + ' is ' + age + ' years'

i.e. it returns sentences of the form: 'Peter is 42 years'.

The application is made up of three services, one which can be queried for the random age, one which can be queried for a random name and a frontend, which calls the two other through HTTP requests and formats the final sentences. This is deployed to Kubernetes using three Deployments - typically with names like age, name and sentences.

The Python source for the application can be found here. Note that the application is a 'test' application and thus configurable for different test purposes. Much of the configuration is through environment variables. The most important environment variable is SENTENCE_MODE which define whether the application is running in age, name or sentences mode.

• Knative katas