Need help in this challenge? Check deployment files here 📘!
In this challenge you will install a service mesh in your Azure AKS cluster and implement most of the features Istio provides.
Why would you want such a mesh? There are many reasons, but most important is the fact that you can add - among others - some complicated routing, loadbalancing, fault injection etc. scenarios that you couldn't achieve otherwise or only with a huge effort.
Istio adds:
- Monitoring
- Tracing
- Circuit Breakers
- Request Routing
- Load Balancing (Round Robin, Least Connected, Random etc.)
- Fault Injection (Delays / Aborts)
- Retries / Timeouts
- Request Mirroring
- Access Control / Authorization
- Rate Limiting
- ...and much more!
Although Istio has reached version 1.0 and is now marked "production ready", beware of the fact that not each of all of these features are in that stage: https://istio.io/about/feature-stages/
Istio version >= 1.1.3 and Kubernetes >= 1.10.6.
- How to install Istio into your AKS cluster ⭐
- How to configure ingress routes and request routing ⭐
- How to remove slow/buggy containers temporarily and implement retry strategies (UNHEALTHY)
- How to implement the Circuit Breaker pattern
- How to gain insights about your applications routes ⭐
- How to play with fault injection to challenge your services
- How to test new service versions with request mirroring ⭐
- How to handle external service calls / Egress
⭐ = highly recommended
This can only be a quick introduction, but in general, Istio consists of a control and a dataplane. The dataplane is basically where your data flows, whereas the controlplane accepts your input in order to configure the dataplane. Usually, a pod consists of one container if no special requirements are demanded, but for Istio there will be a sidecar container running in parallel to the actual application container. This sidecar, which is an envoy proxy is responsible for handling all the network related stuff for the pod. Istio is able to inject the sidecar automatically while you deploy your pods to Kubernetes.
More details can be found here.
Using Istio can be somewhat expansive...but as always, it depends on what you are doing with it. It's written in Go an adds overhead to your architecture / application. The performance you may lose should be paid for by the increase of developer productivity and the fact that applications will run more robust inside the cluster, when you implement features like fault injection / retries / circuit breakers etc.