<p>I am having a stateful application - I am keeping data in user's sessions (basically data in <code>HttpSession</code> object) - but I do not have any requirement to write anything to persistent disk.</p>
<p>From what I have read so far - StatefulSet workloads are meant for stateful applications, but my understanding so far is that even though my application is a stateful application but Deployment workloads can also suffice my requirement because I do not want to write anything to persistent disks.</p>
<p>However, one point I am not sure about is that suppose I use Deployment workload and a lot of user data is present in my <code>HttpSession</code> object, now due to some reason Kubernetes restarts my Pod then of course all that user session data will be lost. So, my question are following:</p>
<ul>
<li>Does StatefulSet handles this situation any better than Deployment workload?</li>
<li>So, only difference between Deployment workload and StatefulSet workload is about absence/presence of persistent disk or there is something to do with application session management as well in case of StatefulSet?</li>
</ul>

pjj
<blockquote>
<p>Does StatefulSet handles this situation any better than Deployment workload?</p>
</blockquote>
<p>No. Neither <code>Deployment</code> nor <code>StatefulSet</code> will preserve memory contents. To preserve session information, you'll need to store it somewhere. One common approach is to use <a href="https://en.wikipedia.org/wiki/Redis" rel="nofollow noreferrer">Redis</a>.</p>
<blockquote>
<p>So, only difference between Deployment workload and StatefulSet workload is about absence/presence of persistent disk or there is something to do with application session management as well in case of StatefulSet?</p>
</blockquote>
<p>No, there are other differences:</p>
<ul>
<li>StatefulSets create (and re-create) deterministic, consistent pod names (identifiers).</li>
<li>StatefulSets, are deployed, scaled, and updated <strong>one by one</strong> in a deterministic, consistent order. The next pod will be created only after the previous one reached the <code>Running</code> state.</li>
</ul>
<p>Additionally, it's worth mentioning that persistent disks can be attached to pods that aren't part of a <code>StatefulSet</code>. It's just that it's convenient to have disks always be attached to a pod with a consistent id. For instance if you have pods running a replicated database, you can use StatefulSets to ensure that the master replica's disk is always attached to pod #1.</p>
<p>Edit:</p>
<p><a href="https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/" rel="nofollow noreferrer">Link to official documentation about StatefulSets</a></p>
<p>From the documentation:</p>
<blockquote>
<p>Like a Deployment, a StatefulSet manages Pods that are based on an
identical container spec. Unlike a Deployment, a StatefulSet maintains
a sticky identity for each of their Pods. These pods are created from
the same spec, but are not interchangeable: each has a persistent
identifier that it maintains across any rescheduling.</p>
</blockquote>
<p>...</p>
<blockquote>
<p>StatefulSets are valuable for applications that require one or more of
the following.</p>
<ul>
<li>Stable, unique network identifiers.</li>
<li>Stable, persistent storage.</li>
<li>Ordered, graceful deployment and scaling.</li>
<li>Ordered, automated rolling updates.</li>
</ul>
<p>In the above, stable is synonymous with persistence across Pod
(re)scheduling. If an application doesn't require any stable
identifiers or ordered deployment, deletion, or scaling, you should
deploy your application using a workload object that provides a set of
stateless replicas. Deployment or ReplicaSet may be better suited to
your stateless needs.</p>
</blockquote>
