Kubernetes StatefulSets: Stable Identity for Pods
A StatefulSet gives pods a stable, unique identity and persistent storage, unlike a Deployment's interchangeable replicas. Use it for clustered databases or queues where members need stable network names.
WHY IT EXISTS: Standard Deployments treat pods as stateless and interchangeable. This model breaks for applications like databases, where each node has a unique state and identity within a cluster. StatefulSet was created to manage these applications, providing guarantees about ordering and uniqueness that Deployments lack.
THE MENTAL MODEL: Think of a Deployment as managing a herd of cattle, where any one can be replaced by another. A StatefulSet manages a team of specialists, like a surgical team. Each member has a specific name (Dr. Alice, Dr. Bob) and their own set of tools (persistent storage). If a member is replaced, the new one must assume the same name and use the same tools.
HOW IT WORKS: A StatefulSet provides two key guarantees. First, a stable, unique network identity. Pods are created with a predictable, ordinal name like app-0, app-1, app-2. This name is tied to a stable DNS entry. Second, stable, persistent storage. Each pod gets its own PersistentVolumeClaim, which is re-attached to it even if the pod is rescheduled to a different node. Scaling and updates are ordered; for example, scaling down from 3 to 2 pods will always terminate app-2 first.
WHEN TO USE IT: Use a StatefulSet for any application that requires stable identifiers or ordered deployment, scaling, and deletion. This is common for distributed databases (etcd, Cassandra, MongoDB), message brokers (Kafka, RabbitMQ), and other clustered software where peer discovery and data locality are critical.
WHEN NOT TO USE IT: Do not use a StatefulSet for stateless applications like web servers or API gateways. A Deployment is simpler, faster, and more flexible for these use cases. Using a StatefulSet where it's not needed adds unnecessary complexity and operational overhead.
ONE CANONICAL EXAMPLE: A three-node etcd cluster. The StatefulSet would create pods named etcd-0, etcd-1, and etcd-2. Each pod would have its own PersistentVolume to store its data. If the node running etcd-1 fails, Kubernetes will restart the etcd-1 pod on a healthy node and re-attach its original storage volume, allowing it to rejoin the cluster with its state intact.
Read the original → kubernetes.io
Get five bites like this every day.
Tezvyn delivers a daily feed of 60-second tech bites with quizzes to lock in what you learn.