Introduction to StatefulSets

In this chapter, we'll learn how to use StatefulSets to deploy and manage stateful applications on Kubernetes.

For the purposes of this chapter, we define a stateful application as one that creates and saves valuable data. Examples include databases, key-value stores, and applications that save data about client sessions and use it for future sessions.

StatefulSet theory

It's helpful to compare StatefulSets with Deployments. Both are resources in the Kubernetes API and follow the standard Kubernetes controller architecture — control loops that reconcile observed state with desired state. Both manage Pods and add self-healing, scaling, rollouts, and more.

However, StatefulSets offer the following three features that Deployments do not:

• Predictable and persistent Pod names

• Predictable and persistent DNS hostnames

• Predictable and persistent volume bindings

These three properties form a Pod's state, which we sometimes refer to as its sticky ID. StatefulSets ensure that all three persist across failures, scaling operations, and other scheduling events.

As a quick example, failed Pods managed by a StatefulSet will be replaced by new Pods with the exact same Pod name, the exact same DNS hostname, and the exact same volumes. This is true even if Kubernetes starts the replacement Pod on a different cluster node. This makes StatefulSets useful for applications that require unique, reliable Pods and volumes.

The following YAML defines a simple StatefulSet called tkb-sts with three replicas running the mongo:latest image. We post this to the API server, it gets persisted to the cluster store, the scheduler assigns the replicas to worker nodes, and the StatefulSet controller ensures observed state matches the desired state