1

I am exploring the Kubernetes toolset and have now my dedicated 3 nodes cluster up and running.

Next steps are migrating our company projects to the cluster. As we use MongoDB and ElasticSearch and want to host multiple projects within the cluster, I am not sure how to handle the persistance correctly.

I will use glusterfs with replication running directly on the nodes (not in kubernetes) and mount volumes to the pods using

https://github.com/kubernetes/examples/tree/master/staging/volumes/glusterfs

Should I install the MongoDB as ReplicaSet directly on the nodes as well or run one MongoDB instance for each project inside a corresponding pod using glusterfs for replicated storage and backup?

As a requirement the lost of one (worker-) node should allow running the lost pods on other nodes without the loss of data.

How should I preserve the database data among multiple nodes? Even replication (MongoDB ReplicaSet e.q.) needs a persistant storage for each pod.

0

Okay after some researching I found this article quite helpful:

https://portworx.com/ha-mongodb-kubernetes/

They usey portworx as a sds but gluster should work as well.

So my intended solution is to run the databases for each project in a seperate pod/container. With our 3 nodes cluster I will replicate the database volume but only run one instance of the database at a time. This way the failover and starting the db container on another node should not be a problem at all.

When we add more nodes to the cluster or the application needs more database instances for better scaling I will provide a replicated volume for each db instance and connect the databases using a ReplicaSet.

0

I'd recommend using a custom operator to handle stateful apps like databases on Kubernetes. There's a lot of ways you can shoot yourself in the foot when handling stateful apps.

Have a look at kubedb.com, they have operators for both ElasticSearch and MongoDB. Custom operators programmatically take care of replication, handling pod failure (e.g. promote new master), scaling etc.

Mongo -> https://kubedb.com/docs/0.8.0-beta.0/guides/mongodb/overview/

Elastic Search -> https://kubedb.com/docs/0.8.0-beta.0/guides/elasticsearch/overview/

You should of course deploy a staging version and test it against your workload before considering pushing to production.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.