<p>I am some kind of new to Kubernetes and Docker and I was studying the concept of statelessness and statefulness and I understand that stateless microservices don't store data on the host, whereas stateful microservices require some kind of storage on the host who serves the requests but if it's up to me I will always use a stateful one why should I ever use a stateless pod? what is the advantage of statelessness?</p>

melina
<p>For a typical Kubernetes Pod, it will be managed by a higher-level controller like a Deployment.  You might set the Deployment to have <code>replicas: 3</code> so that if one of them fails the other two can pick up the load.  On an update the existing Pods will get deleted and recreated.  If there's heavy load, you can set up a HorizontalPodAutoscaler to increase that replica count for you, which will create more pods when needed.</p>
<p>All of this is really straightforward if your containers are stateless, and there are no consequences to <code>kubectl delete pod</code>.</p>
<p>The problem with a stateful pod is, well, the state.  Kubernetes gives you some <a href="https://kubernetes.io/docs/concepts/storage/persistent-volumes/#types-of-persistent-volumes" rel="nofollow noreferrer">choices on where to store data</a>, but most of them can only be used on one pod at a time; if you have multiple replicas then each generally needs its own local storage, and the application needs to know how to reconcile the multiple copies of it.  (Or, if you can set up something like an NFS server, the application needs to know how to handle concurrent writes.)  Operationally, you need to know how to back up and restore all of the individual little volumes that are getting created along the way.</p>
<p>A standard approach is to minimize the number of places where state is stored, and use network I/O from stateless applications to put things in places.  The state doesn't even need to be in the cluster: if your application is running in AWS, you could have containers that principally store data in RDS hosted relational databases and Amazon's S3 object store but keep nothing locally, and you can then use normal backup and management approaches for those out-of-cluster stores.</p>
