<p>Back when Kubernetes announced the new StatefulSet feature with K8s v1.5 (converting it from the old <code>PetSet</code> name), they put out a really good blog post walking through an example of its usage: <a href="https://kubernetes.io/blog/2016/12/statefulset-run-scale-stateful-applications-in-kubernetes/" rel="nofollow noreferrer">https://kubernetes.io/blog/2016/12/statefulset-run-scale-stateful-applications-in-kubernetes/</a></p>

<p>The first paragraph has a really good description of differentiating features that always stuck out in my mind:</p>

<blockquote>
  <p>...“at most one pod per index” for deployment of the Pods in the set. Along with ordered deployment, ordered termination, unique network names, and persistent stable storage ...</p>
</blockquote>

<p>Break down the important ones:</p>

<h2>Unique network names</h2>

<p>In a deployment, it doesn't matter the network name as any pod should be able to pick up the work. However, when you are running things like a stateful cluster, you might have the concept of 'masters' and 'slaves'. This unique network naming will allow you to keep the distinction by referencing a <em>specific</em> pod, with a predictable incremental name.</p>

<h2>Ordered Termination</h2>

<p>This is important for re-deployments in a stateful cluster as you could have critical machines that need to stay up longer. If you have coordinator or 'leader' nodes, those should be the last to be restarted. StatefulSets allows you to do this. The linked blog post even shows an example of this.</p>

<h2>Persistent stable storage</h2>

<p>Arguably, this is the <em>most</em> crucial difference. By default, StatefulSets retain their storage. Kubernetes does <em>not</em> automatically delete the storage that was attached to a StatefulSet. The same <em>can</em> be achieved with deployments, but its not the default.</p>

CC BY-SA 4.0
2018-03-02T16:17:03.803Z
2019-01-03T10:31:58.260Z
2019-01-03T10:31:58.260Z
BoomShadow
<p><a href="http://whatis.techtarget.com/definition/stateless-app" rel="nofollow noreferrer">The definition of a stateless app</a> seems to apply to database servers like MongoDB or MySQL. I found <a href="https://github.com/kubernetes/charts" rel="nofollow noreferrer">Helm Charts</a> as a kind of template-repository for Kubernetes. However, the stable builds all use deployments. Only in the incubator, which are not provided as stable. </p>

<p><strong>What is the impact of using Deployments for DB Servers?</strong></p>

<p>Are there any issues like sync/replication issues, when running multiple instances in a cluster, for example?</p>

<p>Background: I want to run MongoDB in a failover-cluster, so at least 2 instances are running.</p>

<kubernetes><databases><helm>
What is the impact of using Helm Deployments instead of StatefulSets for Databases like MongoDB or MySQL?
Daniel
# What is the impact of using Helm Deployments instead of StatefulSets for Databases like MongoDB or MySQL?

(Asked by: username_0 on 2018-03-02)

[The definition of a stateless app](http://whatis.techtarget.com/definition/stateless-app) seems to apply to database servers like MongoDB or MySQL. I found [Helm Charts](https://github.com/kubernetes/charts) as a kind of template-repository for Kubernetes. However, the stable builds all use deployments. Only in the incubator, which are not provided as stable.

**What is the impact of using Deployments for DB Servers?**

Are there any issues like sync/replication issues, when running multiple instances in a cluster, for example?

Background: I want to run MongoDB in a failover-cluster, so at least 2 instances are running.

**Tags:** kubernetes, databases, helm


---

## 1 answers

### Answer by username_1 on 2018-03-02. Score: 5

Back when Kubernetes announced the new StatefulSet feature with K8s v1.5 (converting it from the old `PetSet` name), they put out a really good blog post walking through an example of its usage: <https://kubernetes.io/blog/2016/12/statefulset-run-scale-stateful-applications-in-kubernetes/>

The first paragraph has a really good description of differentiating features that always stuck out in my mind:

> ...“at most one pod per index” for deployment of the Pods in the set. Along with ordered deployment, ordered termination, unique network names, and persistent stable storage ...

Break down the important ones:

## Unique network names

In a deployment, it doesn't matter the network name as any pod should be able to pick up the work. However, when you are running things like a stateful cluster, you might have the concept of 'masters' and 'slaves'. This unique network naming will allow you to keep the distinction by referencing a *specific* pod, with a predictable incremental name.

## Ordered Termination

This is important for re-deployments in a stateful cluster as you could have critical machines that need to stay up longer. If you have coordinator or 'leader' nodes, those should be the last to be restarted. StatefulSets allows you to do this. The linked blog post even shows an example of this.

## Persistent stable storage

Arguably, this is the *most* crucial difference. By default, StatefulSets retain their storage. Kubernetes does *not* automatically delete the storage that was attached to a StatefulSet. The same *can* be achieved with deployments, but its not the default.


---

