StatefulSets are valuable for applications that require one or more of the following.
Stable, unique network identifiers.
Stable, persistent storage.
Ordered, graceful deployment and scaling.
Ordered, automated rolling updates.
[1] https://kubernetes.io/docs/concepts/workloads/controllers/st...
And I would guess the doc is a bit of after the fact justification for a design choice already made.
I believe that's only partially true, since even if one has a PVC in something like a Deployment (the antipattern I see *a lot* in folks new to k8s trying to run mysql or whatever), then "k scale --replicas=10 deploy/my-deploy" will not allocate new PVCs for the new pods
That's why I think StatefulSets are valuable as their own resource type: they represent _future_ storage needs
When do you not need automated rolling updates? Or stable network identifiers? I'm sure there are cases, but it seems like supporting them should be the default -- are statefulsets somehow expensive?
Stateful apps can be a bit more exceptional because they often have client libraries that require you to hardcode network addresses via connection strings and other tooling that makes that glue automation more tricky and worth the added guarantee around consistent naming.
Most of the time with stateless apps.
In regards to automated rolling updates, the key word there is "ordered." It will always select the same ordinal index first(reverse order starting with highest ordinal.)[1] This is different than the regular deployment strategy of "rolling update" which is also one by one but will select any pod to whack first.
Regular pods don't have stable network identifiers as they are inherently unstable. In regular pods stable network identifiers are provided by either the cluterIP or a load balancer service.
[1] https://kubernetes.io/docs/tutorials/stateful-application/ba...