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

# Independent chapters

There are multiple different sections, and each section starts from scratch. You can jump to any individual section and run all the examples independently of each other. For this to work, I will give you instructions in each section on how to create a cluster, how to deploy a demo application, and how to set up everything we need in a cluster. Similarly, at the end of each section, we will destroy everything we created.

All in all, each section will start from scratch. We will introduce the section’s theme,  set up everything we need, do some exercises, and then destroy everything. Each section is independent of the others.


# Choice of Kubernetes cluster

Now, as for Kubernetes clusters, I created examples and tested them in:

* **Minikube**
* **Docker Desktop**
* **Google Kubernetes Engine (GKE)**
* **AWS Elastic Kubernetes Service (EKS)**
* **Azure Kubernetes Service (AKS)** 

That does not mean that you have to use one of those Kubernetes distributions. You can run the experiments anywhere you like, in any type of distribution, running in any provider. However, I tested all the examples only in those previously mentioned, and sometimes you might need to modify some definitions or commands if you're using a different Kubernetes flavor.

If you run into any problems, contact me, and I will do my best to help you out. I might even extend this course to provide instructions for other Kubernetes distributions. You just need to let me know what your favorite is.

## Limitations of Minikube and Docker Desktop

While we are at the subject of Kubernetes distributions, Minikube and Docker Desktop will work most of the time. Not always. Specifically, **we will not be able to experiment on nodes in Minikube and Docker Desktop** simply because they are single-node clusters with a control plane and worker node mixed together. Damaging a single-node cluster will not produce the desired results. It will result in permanent destruction.

All in all, everything works and is tested in GKE, EKS, and AKS, while Minikube and Docker Desktop work most of the time. In those few cases, when something doesn't work in one of the local single-node clusters, you should be able to observe the outcomes from the outputs I provide. You should be able to see what is happening and learn, even if an example doesn't work in Minikube or Docker Desktop.

# Homework assignments

I will give you assignments. You will have homework that you might choose to do. Unlike some other courses, those assignments will not be easy. They will be harder than the examples I show you. If you choose to do the homework, expect it to be challenging because I want you to spend time with it and get yourself immersed in the world of chaos engineering by doing hard things, not easy ones.

I do not go through everything that the tooling we’ll use provides. Instead, I assume that you can read the documentation and figure out all the additional modules and plugins and capabilities. We only go through the most commonly used scenarios.


# Critical assumptions and prerequisites

Finally, there is one more critical assumption that I’m making for this course. I assume that you are already proficient with Kubernetes. This course does not teach you how to do some basic Kubernetes operations. I also assume that you have at least a basic understanding of Istio. You don’t need to be an *Istio ninja*, but some basic knowledge is welcome. Also, you will see that I talk about monitoring, alerting, and dashboards. I do not go through those in detail.

All in all, the subject of this course is not to teach you Kubernetes, service mesh, or monitoring and alerting. It is focused on chaos engineering in Kubernetes. I do, however, provide the references for material that you might want to go through if you’re going to dive deeper into some of the topics that are not directly related to the subject of this course.


---

In the next lesson, we will discuss a few things to consider before we officially get started with the course content.

This lesson discusses how the content of this course is organized.

How is the Course Organized?

Independent chapters