Delve into Kubernetes Chaos Engineering to discover system limits, simulate adverse effects, and improve resiliency. Learn about fault tolerance, high availability, and running experiments in a Kubernetes cluster.

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.

The DevOps Toolkit: Kubernetes Chaos Engineering

# Use-cases for chaos engineering

Right now, you might be saying, “okay, I understand that chaos engineering is about learning from the destruction, but what does it really mean?” Let me give you a couple of use-cases for chaos engineering. Although I cannot go through all the permutations of everything we can do, a couple of examples might be in order.

We can validate what happens if you have improper fallback settings when a service is unavailable.

- What happens when a service is not accessible, one way or another?
- What happens if an app is retrying indefinitely to reach a service without having properly tuned timeouts?
- What is the result of outages when an application or a downstream dependency receives too much traffic or when it is not available?
- Will we experience cascading errors when a single point of failure crashes an app?
- What happens when our application goes down?
- What happens when there is something wrong with networking?
- What happens when a node is not available?
- Those are just a few of the questions we will explore through practical exercises.


# Limitations of the practical examples

There are quite a few reasons we will be unable to explore everything that you can or you should do using chaos engineering. First of all, chaos experiments that we can run depend on a system; not all the experiments apply to everybody. Also, going through all the possible permutations would require too much time. We can even say that the number of experiments and their permutations is infinite. I could write thousands of pages, and I’d still not be able to go through all of them.
Instead, I will try to teach you how to think, use some tools, and figure out what makes sense for your organization, your team, and your system.

Now that we mentioned a few examples (more are to come), let’s talk about the principles of chaos engineering.


---

In the next lesson, we will discuss the process of chaos experiments.


This lesson discusses some of the use-cases for chaos engineering.

Introduction To Kubernetes Chaos Engineering

Defining Requirements

Destroying Application Instances

Experimenting with Application Availability

Obstructing and Destroying Network

Draining and Deleting Nodes

Creating Chaos Experiment Reports

Running Chaos Experiments Inside a Kubernetes Cluster

Executing Random Chaos

What’s Next?

Examples Of Chaos Engineering

Use-cases for chaos engineering