In this lesson, you will learn how to use StatefulSets to guarantee that your pods maintain a consistent network identity and a fixed ordinal index, even when they are rescheduled or restarted.
The Identity Challenge
In a standard Deployment, pods are treated as interchangeable cattle. When one dies, Kubernetes spins up a replacement with a randomized name like web-7f89d. This is fine for stateless web servers, but database clusters or distributed systems often need to know exactly which member they are talking to (e.g., "Node 0" is the leader, "Node 1" is a follower).
How StatefulSets Solve This
A StatefulSet provides two essential guarantees that make pods predictable:
- Stable Network Identity: Each pod gets a predictable hostname based on its index (e.g.,
mysql-0,mysql-1). Because these hostnames are stable, other services can reliably connect to a specific instance regardless of which physical node it currently occupies. - Ordinal Indexing: Every pod is assigned an integer index starting from 0. This numbering is persistent; if
mysql-0is deleted, the replacement pod will also be namedmysql-0.
Defining a StatefulSet
When you define a StatefulSet, you must include a serviceName to link the pods to a Headless Service. This allows the cluster to use DNS to reach specific pods directly using their stable hostnames.
apiVersion: apps/v1
kind: StatefulSet
metadata:
name: mysql
spec:
serviceName: "mysql-internal"
replicas: 3
selector:
matchLabels:
app: mysql
template:
metadata:
labels:
app: mysql
spec:
containers:
- name: mysql
image: mysql:5.7
In this configuration, your pods will always be created as mysql-0, mysql-1, and mysql-2. If you need to perform maintenance or if a node fails, Kubernetes will ensure the replacement pod reclaims the exact same name and identifier, allowing your application to maintain its stateful connections and cluster membership logic without manual reconfiguration.
Key Takeaway: StatefulSets ensure that pod names and network identities remain consistent across the entire lifecycle, providing the architectural stability required for distributed, state-dependent workloads.