<p>I have a java application that writes data to MnogoDB database which so far I run it in a monolithic approach for Production.</p>
<p>We consider moving it to Kubernetes cluster:
the data should not be lost and should be persistent.</p>
<p>should we deploy the MongoDB inside the Kubernetes cluster as a pod with persistent volume pod? is it safe ? what happens if the cluster is crushed?
Or should I deploy only the Java application to the cluster and the database will be outside of the cluster?</p>

Ohad
<p>Kubernetes is a stateless container orchestrator by its nature ( meaning it is not designed for databases by intension )   ,  later it was extended and adapted for databases with the statefullset API and you can customize and adapt it for mongoDB , but the statefull deployments become alot complex and difficult to support and mantain so it become alot easier to use k8s operator for the task.</p>
<p>The choices are:</p>
<p><strong>1) Keep your database outside k8s.</strong></p>
<p>pros:</p>
<ul>
<li>easier and simple</li>
<li>you dont need k8s for scaling and redundancy in  mongoDB database , mongoDB support internally horizontal scaling via sharding and redundancy via replication</li>
<li>keep the persistency layer outside k8s make the k8s apps maintenace alot simpler</li>
</ul>
<p>cons:</p>
<ul>
<li>you will need to take care yourself about upgrades/maintenance/monitoring for something that is outside k8s</li>
</ul>
<p><strong>2) Go to ATLAS(mongoDB SaaS).</strong></p>
<p>pros:</p>
<ul>
<li>mongoDB support it for you , so you dont have to do too much by yourself.</li>
</ul>
<p>cons:</p>
<ul>
<li>could be expensive when your data size and usage grow.</li>
</ul>
<p><strong>3) Use mongoDB k8s enterprise operator.</strong></p>
<p>pros:</p>
<ul>
<li>It supports sharded cluster and it use ops manager to deploy and re-configure sharded cluster components.</li>
</ul>
<p>cons:</p>
<ul>
<li>there is a price.</li>
</ul>
<p><strong>4) Use mongoDB k8s community operator.</strong></p>
<p>pros:</p>
<ul>
<li>free</li>
</ul>
<p>cons:</p>
<ul>
<li>It is limited to replicaSet ( In general means that if your database grow above certain size you will not be able to split and distribute to shards)</li>
</ul>
<p><strong>5) Use 3th party community operator.</strong></p>
<p>pros:</p>
<ul>
<li>there is some options out there , bitnami , percona etc.</li>
</ul>
<p>cons:</p>
<ul>
<li>there is learning curve to understand 3th party company intentions.</li>
</ul>
<p><strong>6) Deploy via custom statefulset helm chart.</strong></p>
<p>pros:</p>
<ul>
<li>you can customize as per your needs</li>
</ul>
<p>cons:</p>
<ul>
<li>complex and will require alot of effort to mitigate the default k8s native behaviour</li>
</ul>
<p>I will not sound very modern if I say keep it outside k8s for reliability , but this is my choice , if you need to be modern it is best to use the SaaS provided by the vendor(mongoDB ATLAS) ...</p>
