It’s easy to run an application on Kubernetes that does not use storage. They can be scaled with ease to dozens of replicas, they often can be killed multiple times without a major impact on user experience.
How about those applications which do require some storage? Often persistent storage is placed outside the cluster somewhere on traditional infrastructure. Why is that? Is it because Kubernetes is not suitable to host those stateful workloads?
It turns out that we have everything we need to launch even the most sophisticated applications, including databases. There is a dedicated object for defining containers (StatefulSet), objects for managing and defining storage pools (PersistentVolume, PersistentVolumeClaim), and yet many are still afraid of using them.
For organizations that can use the cloud, it is understandable that Database-as-a-Service (e.g. AWS RDS, GCP Cloud SQL) is more convenient and more practical than hosting your own service. For on-premise environments, however, containers can be an easy path to automate the deployment of test/dev workloads, and in most cases can increase the reliability of production environments by leveraging the ephemeral nature of Kubernetes nodes and their ability to recover after a failure.
Also many databases or queuing software projects aren’t available "as a service" and this is also a good case for launching them on Kubernetes using either Helm charts or dedicated operators.
Let’s not forget that containers are just a fancy way to run processes and every application or service can run in a container. In many cases, the benefits of putting them in containers running on Kubernetes outweigh the potential risk. It also seems that the biggest impediment here is simply the fear of containers and that will go away with more software running in this way.
So yes - it is not only possible to run stateful workloads on Kubernetes, but in many cases it also increases reliability by leveraging auto-heal feature and makes it very easy to setup complex configurations with operators (e.g. Cassandra operator, Postgresql, MySQL). By deciding to use stateful workloads like databases on Kubernetes you embrace the Cloud Native approach on a completely new level.
It's no longer the question IF, but rather WHEN.
and find out more detailed information!