Give it durable state with StatefulSets and volumes
Continues from the last build: The storefront is reachable over HTTPS via Ingress now, but its datastore lives in an ephemeral pod, so a single restart wipes every cart and order.
Your storefront looks production-ready from the outside: TLS, a clean hostname, a healthy Deployment behind the Ingress.
What you'll build
A datastore running as a StatefulSet with a per-pod PersistentVolumeClaim provisioned by a StorageClass, a stable DNS identity served by a headless Service, an ordered and predictable rollout, and a verified backup/restore path. You will have deleted the pod, watched it come back to the same disk with the same data, and restored from a snapshot, so durability is something you have seen, not something you assume.
See how we teach, before you sign up
You don't just get code dumped on you. Every starter file and every solution is explained line-by-line, in plain English. Here's one real file from this project:
apiVersion: v1
kind: Service
metadata:
name: db
labels:
app: db
spec:
clusterIP: None # headless: DNS resolves to each pod, not a VIP
selector:
app: db
ports:
- port: 5432
name: postgresReading this file
clusterIP: NoneMakes the Service headless, instead of one virtual IP, DNS returns the address of each pod so clients can target a specific replica.name: dbThe StatefulSet references this Service by name as its serviceName, which is what builds the stable per-pod DNS names.selector:Picks the datastore pods by label so the headless Service governs exactly the StatefulSet it belongs to.
A headless Service: no cluster IP, so DNS returns per-pod addresses instead of one load-balanced VIP.
That's 1 of 8 explained code blocks in this single project.
The build, milestone by milestone
- 1
Move the datastore from a Deployment to a StatefulSet
5 guided stepsA Deployment treats pods as interchangeable and gives them random names, which is wrong for a datastore that owns data and needs a stable identity. The StatefulSet is the controller built for that, and the move is the foundation everything else stands on.
- 2
Back it with a PersistentVolumeClaim and StorageClass
5 guided stepsThis is the line between ephemeral and durable. A volumeClaimTemplate makes the StatefulSet request a real disk per pod from a StorageClass, so the data lives on a PersistentVolume that the pod merely mounts, rather than inside the pod itself.
- 3
Prove durability by deleting the pod
5 guided stepsDurability you have not tested is a guess. The whole reason for the StatefulSet and PVC is that the disk survives the pod, and the only way to trust that is to destroy the pod and watch the data come back.
- 4
Give it stable identity and an ordered rollout
5 guided stepsStateful workloads care about order and identity in a way stateless ones never do: a replica that is meant to be a primary must come up before its followers, and each must keep the same name across restarts so peers can find it. The StatefulSet gives you that, but only if you configure it deliberately.
- 5
Make it recoverable with backup and restore
5 guided stepsA PersistentVolume survives a pod, but it does not survive a dropped table, a corrupt write, or a deleted PVC. Replication protects against a node dying; only a real backup protects against bad data and human error, and a backup you have never restored is a wish, not a plan.
What's inside when you start
You'll walk away with
This is portfolio-grade. Build it free.
Sign up to unlock every milestone step-by-step, the code skeletons, full reference solutions, and checkable tasks, with your progress saved as you build.
Start building