I have a java application that writes data to MnogoDB database which so far I run it in a monolithic approach for Production.

We consider moving it to Kubernetes cluster: the data should not be lost and should be persistent.

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?

CodePudding user response：

I recommend you to use MongoDB Atlas for Database Deployments.

CodePudding user response：

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.

The choices are:

1) Keep your database outside k8s.

pros:

• easier and simple
• you dont need k8s for scaling and redundancy in mongoDB database , mongoDB support internally horizontal scaling via sharding and redundancy via replication
• keep the persistency layer outside k8s make the k8s apps maintenace alot simpler

cons:

• you will need to take care yourself about upgrades/maintenance/monitoring for something that is outside k8s

2) Go to ATLAS(mongoDB SaaS).

pros:

• mongoDB support it for you , so you dont have to do too much by yourself.

cons:

• could be expensive when your data size and usage grow.

3) Use mongoDB k8s enterprise operator.

pros:

• It supports sharded cluster and it use ops manager to deploy and re-configure sharded cluster components.

cons:

• there is a price.

4) Use mongoDB k8s community operator.

pros:

• free

cons:

• 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)

5) Use 3th party community operator.

pros:

• there is some options out there , bitnami , percona etc.

cons:

• there is learning curve to understand 3th party company intentions.

6) Deploy via custom helm chart statefulset.

pros:

• you can customize as per your needs

cons:

• complex and will require alot of effort to mitigate the default k8s native behaviour

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) ...