StatefulSets and PersistentVolumes for Stateful Java Services

Intermediate·3 min read·

Fast recall

Quick revision

Core answer

StatefulSets are for workloads where each replica is not interchangeable — stable network identity (postgres-0 remains postgres-0), stable per-replica storage (each pod gets its own PVC via volumeClaimTemplates), and ordered operations. Databases, Kafka, Elasticsearch need this. Most Spring Boot services are stateless and belong on Deployments — even those that use a database. PersistentVolumes provide durable storage provisioned dynamically via StorageClass and survive Pod deletion.

Interview Answer3 min

Persistent Volumes and StatefulSets together solve running stateful workloads in Kubernetes — databases or message brokers that need durable storage and stable network identity across Pod restarts.

Persistent Volumes — storage abstraction

A PersistentVolumeClaim (PVC) requests storage by size and access mode (ReadWriteOnce, ReadWriteMany); Kubernetes binds it to a PersistentVolume either pre-provisioned by an admin or dynamically created by a StorageClass.
ReadWriteOnce means only one node can mount the volume at a time — the constraint for most block storage (AWS EBS, GCE Persistent Disk); a StatefulSet with 3 replicas and ReadWriteOnce means each replica gets its own PVC, not one shared.
The PVC lifecycle is independent of the Pod — delete the Pod or even the StatefulSet and the PVC (and the data) survive; explicitly delete the PVC to release storage; this is intentional for durability.

StatefulSet — ordered, stable pods

StatefulSets give each pod a stable identity: db-0, db-1, db-2; the DNS name for db-0 is db-0.db-service.namespace.svc.cluster.local — this stability is what PostgreSQL, Kafka, Elasticsearch require for cluster membership and leader election.
StatefulSets scale and update in order: db-0 starts before db-1; during a rolling update db-2 updates first, then db-1, then db-0 — this ensures the primary (usually db-0) is updated last, minimizing failover window.
volumeClaimTemplates automatically creates a PVC for each pod; db-0 gets data-db-0 and restarting db-0 always reattaches to the same volume.

When to use StatefulSets

Use Deployments for stateless Spring Boot services — simpler, roll back more cleanly, no PVCs needed.
Use StatefulSets for databases (if running in Kubernetes at all), Kafka brokers, Elasticsearch nodes, or any process requiring stable network identity or per-instance durable storage.
Most teams run databases outside Kubernetes on managed services (RDS, Cloud Spanner) — the operational complexity of StatefulSets and storage is worth avoiding when a managed service handles it.

Operational gotchas

Scaling down a StatefulSet removes pods but leaves PVCs — orphaned disks accumulate cloud cost over time; add a cleanup runbook or use an operator.
Use volumeBindingMode: WaitForFirstConsumer on the StorageClass so volumes are provisioned in the same availability zone as the scheduled pod.
Replication is not backup — a DROP TABLE replicates instantly; schedule pg_dump or snapshots stored in a different region/account for real durability.

Interview-ready guide

Interview answer

Persistent Volumes and StatefulSets together solve running stateful workloads in Kubernetes — databases or message brokers that need durable storage and stable network identity across Pod restarts.

Persistent Volumes — storage abstraction

A PersistentVolumeClaim (PVC) requests storage by size and access mode (ReadWriteOnce, ReadWriteMany); Kubernetes binds it to a PersistentVolume either pre-provisioned by an admin or dynamically created by a StorageClass.
ReadWriteOnce means only one node can mount the volume at a time — the constraint for most block storage (AWS EBS, GCE Persistent Disk); a StatefulSet with 3 replicas and ReadWriteOnce means each replica gets its own PVC, not one shared.
The PVC lifecycle is independent of the Pod — delete the Pod or even the StatefulSet and the PVC (and the data) survive; explicitly delete the PVC to release storage; this is intentional for durability.

StatefulSet — ordered, stable pods

StatefulSets give each pod a stable identity: db-0, db-1, db-2; the DNS name for db-0 is db-0.db-service.namespace.svc.cluster.local — this stability is what PostgreSQL, Kafka, Elasticsearch require for cluster membership and leader election.
StatefulSets scale and update in order: db-0 starts before db-1; during a rolling update db-2 updates first, then db-1, then db-0 — this ensures the primary (usually db-0) is updated last, minimizing failover window.
volumeClaimTemplates automatically creates a PVC for each pod; db-0 gets data-db-0 and restarting db-0 always reattaches to the same volume.

When to use StatefulSets

Use Deployments for stateless Spring Boot services — simpler, roll back more cleanly, no PVCs needed.
Use StatefulSets for databases (if running in Kubernetes at all), Kafka brokers, Elasticsearch nodes, or any process requiring stable network identity or per-instance durable storage.
Most teams run databases outside Kubernetes on managed services (RDS, Cloud Spanner) — the operational complexity of StatefulSets and storage is worth avoiding when a managed service handles it.

Operational gotchas

Scaling down a StatefulSet removes pods but leaves PVCs — orphaned disks accumulate cloud cost over time; add a cleanup runbook or use an operator.
Use volumeBindingMode: WaitForFirstConsumer on the StorageClass so volumes are provisioned in the same availability zone as the scheduled pod.
Replication is not backup — a DROP TABLE replicates instantly; schedule pg_dump or snapshots stored in a different region/account for real durability.

03 · Deep dive