Why StatefulSet? about zammad-helm

[zoomoid]

As you can observe in zammad/templates/statefulset.yaml, the application shares some persistent state across its containers.

Managing updates to deployments with attached volumes with access modes other than "ReadWriteMany" becomes problematic, where the new pod will only start up if it can attach the volume claim, which is never free'd by the existing pod, causing the upgrade to deadlock.

This is why Deployments are not meant for applications that maintain any persistent state, whereas the StatefulSet controller ensures that a pod with a volume attached is terminated before starting up the new one.

In addition, StatefulSetSpec contains a field for creating PersistentVolumeClaims from inside the STS spec, which conveniently concentrates configuration and removes the need to create explicit PersistentVolume/PVC objects.

For more information about the benefits of StatefulSets for applications that need to maintain internal state, please refer to https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/.

[bronger]

I know of very few deployments without persistent state. If two instances running at the same time are problematic, use {strategy: {type: Recreate}}.

With only one replica, technically you can use both StatefulSet and Deployment. So, it is mainly a documentation issue. (And I asked it mainly to understand Zammad better in order to deploy it at my company.)

With StatefulSet, you declare that your application needs distinguishable pods, with unique and stable network names and each with a distinct pesistent storage. (Or at least, one of these properties.) Like with memcached: The client chooses which memcached pod to contact. It does matter.

Once Zammad grows the ability to scale horizontally, I would have naively expected the Deployment approach: Each pod storing its persistence in PostgreSQL (with soft persistence in Elasicsearch/memcached), so that the loadbalancer does not have to worry to which pod it should route the request. It does not matter.

Which way will Zammad go?

[zoomoid]

The usage of PVs for state is due to Zammad storing its entire source files and runtime in /opt/zammad, serving static assets from subdirectories of that path, and also not being able to store user-uploaded static assets in any external object storage or database, thus storing files inside its operations directory to remain persistent. To be honest, this could be split up to externalize such assets from the particular application but requires larger refactoring, I assume. Hence, it needs to store them locally. This again makes Zammad a stateful application, for which StatefulSets are the designated resource kind to use.

The partitioning of such uploaded static assets is what I would suspect the largest limiting factor in scaling out.
This is, to my understanding, more of a conceptual issue of Zammad itself and less of the corresponding Helm chart, which uses a StatefulSet because it solves the hassle with coupling PVCs and Pods for you.

When any state can be assumed to be external, Deployments will semantically be the right choice, but until then, StatefulSet will likely remain the best choice to counteract design shortcomings in the main application.

[bronger]

Thank you for your information! I understand it now, and stay tuned for future improvements on the scaling matter.