Level-up your testing with Chaos Engineering. Learn how pushing your programs to failure can help you plan your improvements.

DevOps for Developers

Let’s face it, bad things happen in software engineering, often when you least expect it. Servers go down, there are spikes in traffic, you receive networking errors. Luckily, you can avoid these problems. Enter chaos engineering.
Chaos engineering is where you try to find the limits of a system and simulate adverse effects that might happen. These simulations then help you to determine the best way to improve your system and build up its resiliency.
This course is divided into various sections to get you used to the different types of experiments you can run in chaos engineering. You will start by learning how to destroy application instances in order to show you the importance of scaling, fault tolerance, and high availability.
You will then dive deep into other types of experiments such as destroying a network, draining and deleting nodes, and testing availability. Towards the end of the course, you will learn how to run experiments in a Kubernetes cluster.

Kubernetes Chaos Engineering

Just like always, we will have to create a cluster, unless you kept the one from before.

# Note for Minikube and Docker Desktop users

Unlike other sections, there is a potential problem that we might face. It is related to the fact that we will not be able to run chaos experiments that target the nodes of our cluster on Minikube or Docker Desktop. If we drain or delete a node and that node is the only one in our cluster, then bad things will happen. In a “real” cluster like Azure, Google, AWS, DigitalOcean, or even on-prem, this shouldn’t be a problem since we’d have multiple nodes, and we can scale our cluster up and down. However, this is impossible, at least to my knowledge, with Minikube and Docker Desktop. Since they are a single node cluster, we will not be able to run experiments targeting nodes.

If you are a **Minikube** or **Docker Desktop** user, try to create a Kubernetes cluster somewhere else. As long as that cluster can run on multiple nodes, it should be fine. I prepared Gists to create a cluster in AWS (EKS), Google (GKE), Azure (AKS), so you can use those if you have an account in one of those providers. Alternatively, you can roll out your own. All the examples should work as long as that is not a Docker Desktop or Minikube cluster.

If, on the other hand, you cannot (or don't want to) run a Kubernetes cluster anywhere else, then the only thing you can do is to observe what I'm showing without doing the same actions yourself.

The good news is that this is likely the only section that restricts us from using Docker Desktop or Minikube.

Once you create a cluster, you'll need the environment variable `INGRESS_HOST`. The Gists already have the instructions on how to define it. If you're creating a cluster on your own, make sure that it contains the address of Istio Gateway through which we can access applications.

Finally, here is a big warning:

> Do NOT use a real production cluster.

Even though I’m sure you have been using a demo cluster for the exercises in this course, I had to warn you. What we’re about to do will be very destructive. You might not be able to recuperate from the mayhem we are going to create. So, make sure that the cluster is disposable.

# Gists for different Kubernetes flavors

Gists with the commands to create and destroy a Kubernetes cluster are as follows.

* [GKE with Istio](https://gist.github.com/924f817d340d4cc52d1c4dd0b300fd20)
* [EKS with Istio](https://gist.github.com/3989a9707f80c2faa445d3953f18a8ca)
* [AKS with Istio](https://gist.github.com/c512488f6a30ca4783ce3e462d574a5f)

Let's move on and deploy our demo application. 

---

The next lesson will contain the instructions for deploying the demo application.


This lesson contains instructions regarding creating a Kubernetes cluster.

Creating a Cluster