14. Running Stateful Components in Kubernetes

Overview

In this chapter, we will expand our skills to go beyond stateless applications and learn how to deal with stateful applications. We will learn about the various forms of state preservation mechanisms available to Kubernetes cluster operators and derive a mental model for where certain options can be invoked to run applications well. We will also introduce Helm, a useful tool for deploying complex applications with various Kubernetes objects.

By the end of this chapter, you will be able to use StatefulSets and PersistentVolumes in conjunction to run apps that require disk-based state to be retained in between pod interruptions. You will also be able to deploy applications using Helm charts.

Introduction

From everything that you have learned up until this point, you know that pods and the containers that run in them are considered ephemeral. This means that they are not to be depended upon for stability as Kubernetes will intervene and move them around the cluster in order to comply with the desired state specified by the various manifests in the cluster. But there's a problem in this – what do we do with the parts of our applications that depend on the state being persisted from one interaction to the next? Without certain guarantees such as predictable naming for the pods and dependable storage operations, which we will learn about later in the chapter, such stateful components may fail if Kubernetes restarts the relevant pods or moves them around. However, before diving into the details of the aforementioned topics, let's talk briefly about stateful apps and why it's challenging to run them in a containerized environment.

Stateful Apps

We briefly introduced the concept of statefulness in Chapter 12, Your Application and HA. Stateful components of applications are a necessity to just about all information technology systems in the world. They're necessary to keep account details, records of transactions, information on HTTP requests, and a whole host of other purposes. The challenging part of running these applications in a production environment almost always has to do with either the network or the persistence mechanism. Whether it's spinning metal disks, flash storage, block storage, or some other yet-to-be-invented tool, persistence is notoriously difficult to deal with in all forms. Part of why this is difficult is because all of these forms have a non-zero probability of failure, which can become very significant once you need to have hundreds or even thousands of storage devices in a production environment. These days, many cloud providers will give assistance to customers and offer...

Understanding StatefulSets

In Figure 14.1, we can see that a StatefulSet is invoked to be able to manage pod life cycles. A StatefulSet (in older versions of Kubernetes, this was called a PetSet) operates very similarly to a Deployment in that we provide a pod template of what we want to run and how many instances of it we want to run. What differs between a StatefulSet and a Deployment is the following:

• A clear naming scheme that can be depended upon by pods in DNS queries:

  This means that in the preceding diagram when we name a StatefulSet mysql, the first pod in that StatefulSet will always be mysql-0. This is unlike a traditional deployment where pod IDs are assigned randomly. It also means that if you had a pod named mysql-2 and it crashed, it would be resurrected on the cluster using exactly the same name.

• A clearly ordered way in which updates must proceed:

  Depending on the update strategy in this StatefulSet, each pod will be taken down in a very specific order. So...

Further Refactoring Our Application

We'd like to now take our application a little further into cloud-native principles. Let's consider that the product manager for our counter app said that we're getting insane amounts of load (and you can confirm this through your observability toolset), and some people are not always getting a strictly increasing number; sometimes, they are getting duplicates of the same number. So, you confer with your colleagues and come to the conclusion that in order to guarantee the increasing number, you will need guarantees around how data is accessed and persisted in your app.

Specifically, you need a guarantee that operations against this datastore are atomically unique, consistent between operations, isolated from other operations, and durable against failure. That is, you are looking for an ACID-compliant database.

Note

More on what ACID compliance is can be found at this link: https://database.guide/what-is-acid-in-databases...

Helm

In this section, we are going to be taking a look at a tool that is very helpful in the Kubernetes ecosystem called Helm. Helm was created by Microsoft after it quickly became apparent that for any sizeable deployment of Kubernetes (for example, those involving 20 or more separate components, observability tools, services, and other objects), there are a lot of YAML manifests to keep track of. Couple that with the fact that many companies run multiple environments other than production, which you need to be able to keep in sync with each other, and you start to have an unwieldy problem on your hands.

Helm allows you to write Kubernetes manifest templates, to which you supply arguments that override any defaults, and then Helm creates the appropriate Kubernetes manifests for you. Thus, you can use Helm as a sort of package manager, where your entire application can be deployed using a Helm chart, and you can tweak a few small parameters before installing. Another way to use...

Summary

Over the course of this chapter, we have applied our skills to be able to leverage StatefulSets in our example application. We have looked at how to think about running stateful portions of our software programmatically and how to refactor applications to leverage that change in state persistence. Finally, we learned how to create and run Kubernetes StatefulSets that will allow us to run stateful components in our cluster and make guarantees about how that workload will be run.

Being equipped with the skills needed to manage stateful components on our Kubernetes cluster is a major step in being able to operate effectively in many real-world applications that you are likely to come across.

In the next chapter, we're going to talk more about data-driven application orchestration with the use of Metrics Server, HorizontalPodAutoscalers, and ClusterAutoscaler. We will learn how these objects help us respond to varying levels of demand on our application running on a...