<p>I understood that </p>

<ul>
<li><code>StatefulSet</code> - manages/maintains stable hostname, network ID and persistent storage. </li>
<li><code>HeadlessService</code> - stable network ID you need to define a headless service for stateful applications</li>
</ul>

<blockquote>
  <p>FROM K8s Docs -> Sometimes you don’t need or want load-balancing and a single service
  IP. In this case, you can create “headless” services by specifying
  "None" for the cluster IP (.spec.clusterIP).</p>
</blockquote>

<p><strong>My thoughts on "Statefull vs Stateless" Apps/components</strong></p>

<ol>
<li><p><code>UI</code> comes under stateless application/component because, it doesn't maintain any data. But it gets from DB and displays</p></li>
<li><p><code>DB</code>, <code>Cache</code>(Redis) are Statefull application/components,because it has to maintain data </p></li>
</ol>

<p><strong>My Questions.</strong></p>

<ol>
<li><p><code>Persistence storage in Apps</code> - Why should I consider to deploy postgress (for example) as <code>StatefulSet</code>? I can define <code>PV</code>s and <code>PVC</code> in <code>Deployement</code> to store the data in PV. Even if pods restart, it will gets it PV, thus there is no lose of data.</p></li>
<li><p><code>Network</code> - Redis(for example) should deploy as <code>StatefulSet</code>, so that we can get unique "Network ID"/Name everytime even after restart of pods. For example; <code>Redis-0</code>, <code>Redis-1</code> are in <code>StatefulSet</code>, I can define <code>Redis-0</code> as master, so master <code>name</code> never changes. Now why should I consider <code>Headless Service</code> for <code>StatefulSet</code> apps? I can directly access/connect the PODs itself, right? What is the use of <code>Headless Service</code>?</p></li>
<li><p>I heard about <code>Operators</code>, a best way to manage <code>StatefulSet</code> apps. I found some example below. Why those(or some other) are important to deploy as <code>StatefulSet</code>. For example, <code>Prometheus</code> or <code>ElasticSearch</code>; I can define <code>PVs</code> and <code>PVC</code> to store data without lose.</p>

<ul>
<li><a href="https://github.com/krallistic/kafka-operator" rel="noreferrer">https://github.com/krallistic/kafka-operator</a></li>
<li><a href="https://github.com/coreos/prometheus-operator" rel="noreferrer">https://github.com/coreos/prometheus-operator</a></li>
<li><a href="https://github.com/upmc-enterprises/elasticsearch-operator" rel="noreferrer">https://github.com/upmc-enterprises/elasticsearch-operator</a></li>
</ul></li>
</ol>

<p>Why/When should I care about <code>StatefulSet</code> and <code>Headless Serivice</code>?</p>

Veerendra K
<p>Before trying to answer some of your questions I must add disclaimer: there are different ways to skin a cat. And since we are discussing StatefulSets here note that not all approaches are best suited for all stateful applications. In case that you need a single database pod with single PV, you could have one approach, if your api pod needs some shared and some separated PV then another and so on..</p>

<blockquote>
  <p>Persistence storage in Apps - Why should I consider to deploy postgress (for example) as StatefulSet? I can define PVs and PVC in Deployement to store the data in PV.</p>
</blockquote>

<p>This hold true if all your pods are using same persistent volume claim across all replicas (and provisioner allows that). If you try to increase number of replicas based on Deployment all your pods will use the very same PVC. On the other hand, StatefulSet as defined in <a href="https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.10/#statefulset-v1-apps" rel="noreferrer">api documentation</a> has <code>volumeClaimTemplates</code> allowing for each replica to have own generated PVC, securing separately provisioned PV for each pod in replica set.</p>

<blockquote>
  <p>Now why should I consider Headless Service for StatefulSet apps?</p>
</blockquote>

<p>Because of ease of discovery. Again, you don't need to know how many replicas you have in Headless Service, checking service DNS you will get ALL replicas (caveat - that are up and running in that moment). You can do it manually, but in this case you rely on different mechanism of counting/keeping tabs on replicas (replicas are self registered to master for example). Here is nice example of <a href="https://akomljen.com/stateful-applications-on-kubernetes/" rel="noreferrer">pod discovery with nslookup</a> that can shed some light on why headless can be a nice idea.</p>

<blockquote>
  <p>Why those(or some other) are important to deploy as StatefulSet</p>
</blockquote>

<p>To my understanding, very Operators you listed are deployed using the Deployment themselves. They handle StatefulSets though, so lets consider ElasticSearch for example. If it was not deployed as StatefulSet you would end up with two pods targeting same PV (if provisioner allows it) and that would heavily mess up things. With StatefulSet each pod gets its very own persistent volume claim (from template) and consequently separate persistent volume from other ElasticSearch pods in same StatefulSet. This is just a tip of the iceberg since ElasticSearch is more complex for setup/handling and operators are helping with that.</p>

<blockquote>
  <p>Why/When should I care about StatefulSet and Headless Serivice?</p>
</blockquote>

<ul>
<li><p>Stateful set you should use in any case where replicated pods need to have separate PV from each other (created from PVC template, and automatically provisioned).</p></li>
<li><p>Headless Service you should use in any case where you want to automatically discover all pods under the service as opposed to regular Service where you get ClusterIP instead. As an illustration from above mentioned <a href="https://akomljen.com/stateful-applications-on-kubernetes/" rel="noreferrer">example</a> here is difference between DNS entries for Service (with ClusterIP) and Headless Service (without ClusterIP):</p>

<ul>
<li><p>Standard service - you will get the clusterIP value:</p>

<pre><code>kubectl exec zookeeper-0 -- nslookup zookeeper
Server:        10.0.0.10
Address:    10.0.0.10#53

Name:    zookeeper.default.svc.cluster.local
Address: 10.0.0.213
</code></pre></li>
<li><p>Headless service - you will get the IP of each Pod:</p>

<pre><code>kubectl exec zookeeper-0 -- nslookup zookeeper
Server:        10.0.0.10
Address:    10.0.0.10#53

Name:    zookeeper.default.svc.cluster.local
Address: 172.17.0.6
Name:    zookeeper.default.svc.cluster.local
Address: 172.17.0.7
Name:    zookeeper.default.svc.cluster.local
Address: 172.17.0.8
</code></pre></li>
</ul></li>
</ul>
