skip to Main Content

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?

2

Answers


  1. I recommend you to use MongoDB Atlas for Database Deployments.

    Login or Signup to reply.
  2. 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 statefulset helm chart.

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

    Login or Signup to reply.
Please signup or login to give your own answer.
Back To Top
Search