5

I find tons of articles and documentation describing the advantages of StatefulSets over Deployments for stateful applications on Kubernetes. What I haven't been able to figure out is the opposite: the disadvantages of StatefulSets when compared to Deployments, in particular for stateless applications.

Could someone please explain why not simply always use StatefulSets for both stateful and stateless applications?

chrisvdb
  • 2,080
  • 2
  • 20
  • 28
  • We use statefulsets for our stateless application most because of the sequence naming suffix. It works nicely yet except for failure situation, you have to manually delete failure pod to recover. – a.l. Jun 19 '20 at 04:04
  • Hi @a.l. can you please explain a bit more on your comment "you have to manually delete failure pod to recover." how is it different from deployment in your case ? – Taj Uddin Apr 03 '23 at 17:40
  • Hi @TajUddin, sometimes, we released a version which contains some error which makes the pod's state to be error, then we fixed it and release a new version, however, the error pod won't automatic be updated to the new good version, but has to be deleted first. see https://github.com/kubernetes/kubernetes/issues/60164 – a.l. Apr 04 '23 at 09:44

1 Answers1

4

The most basic difference is that you would get ability to persist pod level state with statefulsets. Using volumeClaimTemplates, each replica will get a unique PersistentVolumeClaim with statefulset whereas all replicas would share the PersistentVolumeClaim with a deployment. This comes at a cost of slow scale ups and scale downs for statefulsets.

Deployments also have cool features related to "deployment" like rolling update with maxSurge and maxUnavailable.

Shashank V
  • 10,007
  • 2
  • 25
  • 41