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.

chrstnwhlrt
  • 325
  • 6
  • 15

2 Answers2

1

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.

chrstnwhlrt
  • 325
  • 6
  • 15
1

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.

shrumm
  • 116
  • 1
  • 9