Overview

Where to begin?

I believe that was enough theory. From now on, everything we’ll do will be hands-on.

So, where will we begin? What will be our first set of chaos experiments?

I don’t want to stress you out too much at first, so we’ll start easy and increase the complexity as we’re progressing.

The easiest thing we’ll explore is how to terminate instances of our applications. We’ll learn how to delete, remove, and kill instances of our applications. This will provide us with quite a few things. To begin with, it will give us a solid base of how chaos experiments work, as well as some side effects. It will hopefully show us the importance of scaling, fault tolerance, high availability, and a few other things.

What are we going to do in this chapter?

To begin, we are going to create a Kubernetes cluster. After all, this is about chaos engineering in Kubernetes. So, we’ll need a Kubernetes cluster. As I mentioned before, you can use Minikube, Docker Desktop, GKE, EKS, or AKS. With some small tweaks, any other cluster should do.

Then, we are going to deploy an application. We will need an app that we will use for demo purposes. It’ll be a simple one. The goal is not to develop a complex application, but to deploy a simple one, and to try experimenting on top of it.

Before we start running chaos experiments, we’ll explore the Kubernetes plugin for Chaos Toolkit. With it, we’ll be able to start terminating instances or, to be more precise, replicas of a demo application.

You will learn about the steady-state hypothesis, and we might need to add some tweaks to our scripts. We might need to explore how to pause things. In some cases, it might not be the best idea to go as fast as we can. You will learn how to impose some conditions and how to define phases to our hypotheses. We will try to observe what you learn from those experiments, and those learnings might lead you towards making your applications fault-tolerant. Once we’re finished with all that, and a few other things, we will destroy what we created.

Every chapter ends with the destruction of everything so that you can start the next chapter from a clean slate. This will allow you to take a break. It might be an hour break, daybreak, or even a full week. In any case, you don’t want to keep your cluster running while on the break. That would only incur unnecessary costs.

How does that sound?

Let’s get going. Let’s create our Kubernetes cluster.

---

In the next lesson, we will be provided with a gist that contains all the commands for this chapter.