Comparison
Persistent volumevsStatefulSet
Persistent volume
the pod died, came back on another node, and the data was still there because the disk followed it.
Storage whose lifetime is independent of any pod, requested by a claim and attached wherever the workload is scheduled. It is what makes a stateful workload survivable, and it drags real constraints in with it: most block storage attaches to one node at a time and lives in one availability zone, which silently pins the workload to that zone. Reclaim behaviour is the other trap — a claim deleted with the wrong policy takes the data with it.
Full entry →StatefulSet
the replicas are named zero, one and two rather than randomly, and each one gets its own disk back after a restart.
A workload type giving each replica a stable identity, a stable network name and its own persistent volume, and rolling them in order. It exists for software that cares which member it is — databases, brokers, consensus systems — where interchangeable replicas would be wrong. It is markedly harder to operate than a stateless deployment, which is the usual argument for running data stores as a managed service instead.
Full entry →