StatefulSets: Stable Identity and Storage
Run a workload that needs a stable identity: a headless Service plus a StatefulSet gives each Pod a sticky name (web-0, web-1) and its own PersistentVolumeClaim from a volumeClaimTemplate — the pattern every database on Kubernetes is built on.
Your mission
A Deployment treats its Pods as interchangeable: same spec, random names, any Pod can be replaced by any other. That's perfect for stateless web servers and wrong for anything that keeps data — a database replica needs to be itself across restarts, with the same name and the same disk.
A StatefulSet gives Pods a stable identity:
- Sticky names. Pods are
web-0,web-1,web-2— ordinal, not random. A restartedweb-0comes back asweb-0. - Stable DNS, via a headless Service (
clusterIP: None). Each Pod gets its own record:web-0.web,web-1.web. The Service's job here isn't load balancing — it's naming. This is why a StatefulSet always names a headless Service inserviceName. - Per-Pod storage, via a
volumeClaimTemplate. Instead of one shared volume, the StatefulSet stamps out a PersistentVolumeClaim per Pod —data-web-0,data-web-1— and a Pod keeps its own claim across rescheduling.
In this lab you build the identity half first (headless Service + StatefulSet), then add the storage half — and meet the gotcha that makes the second step a recreate, not an edit.
Useful aliases
In your terminal, k is aliased to kubectl and completion is configured. The
jumpbox also has k9s, jq and yq installed.