Running MongoDB in Kubernetes is becoming the norm. The most common use cases for running databases in Kubernetes are:
- Create a private Database as a Service (DBaaS).
- Maintain coherent infrastructure, where databases and applications run on the same platform.
- Avoid vendor lock-in and be able to run their databases anywhere utilizing the power of Kubernetes and containers.
There are multiple solutions that allow you to run MongoDB in Kubernetes, and in this blog post, we are going to compare these solutions and review the pros and cons of each of them.
Solutions that we are going to review are:
The summary and comparison table can be found in our documentation.
Bitnami Helm chart
Bitnami was acquired by VMWare in 2019 and is known for its Helm charts to deploy various applications in Kubernetes. The key word here is deploy, as there are no management capabilities in this solution.
All Bitnami Helm charts are under Apache 2.0 license, pure open source. The community around Bitnami is quite big and active.
Deployment
Installation is a usual two-step process: add Helm repository, and deploy the chart.
Add the repository:
$ helm repo add bitnami https://charts.bitnami.com/bitnami
You can tweak the chart installation through values. I decided to experiment with it and deploy a replica set vs the default standalone setup:
$ helm install my-mongo bitnami/mongodb --set architecture="replicaset" --set replicaCount=2
This command deploys a MongoDB replica set with two nodes and one arbiter.
It is worth noting that Github readme is not the only piece of documentation, but there are official Bitnami docs with more examples and details.
Features
Management capabilities are not the strong part of this solution, but it is possible to scale the replica set horizontally (add more nodes to it) and vertically (add more resources to nodes).
Monitoring is represented by mongodb-exporter
as a sidecar. It is described in the Metrics parameters section. It’s a straightforward approach that would be enough for most of the use cases.
What I love about all Bitnami Helm charts is that they provide you with lots of flexibility for tuning Kubernetes primitives and components: labels, annotations, images, resources, and all.
If we look into MongoDB-related functionality in this solution, there are a few that are worth noting:
- Create users and databases during database provisioning. It is a bit weird, that you cannot create roles and assign them right away. But a nice move.
- Hidden node – you will not find it in any other solution in this blog post.
- TLS – you can encrypt the traffic flowing between the replica set nodes. Good move, but for some reason, it is disabled by default.
I have not found any information about supported MongoDB versions. The latest Helm chart version was deploying MongoDB 5.0.
You can deploy sharded clusters, but it is a separate Helm chart – MongoDB Sharded. But still, you cannot easily integrate it with your enterprise solutions – let’s say LDAP or Hashicorp vault. At least this is not going to be a straightforward integration.
KubeDB
KubeDB, created by AppsCode, is a Swiss-army knife Operator to deploy various databases in Kubernetes including MongoDB.
This solution follows an open-core model, where limited functionality is available for free, but good stuff comes after you purchase the license. Here you can find a comparison of the Community vs Enterprise versions.
The focus of our review would be on the Community version, but we are going to mention which features are available in the Enterprise version.
Deployment
I found deployment a bit cumbersome as it requires downloading the license first, even for the Community version.
Add the Helm repo:
$ helm repo add appscode https://charts.appscode.com/stable/
Install the Operator:
$ helm install kubedb appscode/kubedb \ --version v2022.05.24 \ --namespace kubedb --create-namespace \ --set-file global.license=/path/to/the/license.txt
Deploy the database with the command below. It is worth mentioning that with the Community version you can deploy the database only in the demo namespace.
$ kubectl create -f https://github.com/kubedb/docs/raw/v2022.05.24/docs/examples/mongodb/clustering/mongo-sharding.yaml
This deploys a sharded cluster. You can find a bunch of examples in github.
Features
The Community version comes with almost no management capabilities. You can add and remove resources and nodes, so perform basic scaling, but nothing else.
Backups, restores, upgrades, encryption, and many more are all available in the Enterprise version only.
For monitoring, KubeDB follows the same approach as Bitnami and allows you to deploy a mongodb-exporter
container as a sidecar. Read more here.
Definitely, the Community version comes with limited functionality which is not enough to run it in production. At the same time there are some interesting features:
- One Operator, many databases. I like this approach as it can simplify your operational landscape if you run various database flavors.
- Pick your MongoDB version. You can easily find various supported MongoDB versions and pick the one you need through custom resource:
$ kubectl get mongodbversions NAME VERSION DISTRIBUTION DB_IMAGE DEPRECATED AGE 3.4.17-v1 3.4.17 Official mongo:3.4.17 20m 3.4.22-v1 3.4.22 Official mongo:3.4.22 20m 3.6.13-v1 3.6.13 Official mongo:3.6.13 20m 3.6.8-v1 3.6.8 Official mongo:3.6.8 20m 4.0.11-v1 4.0.11 Official mongo:4.0.11 20m 4.0.3-v1 4.0.3 Official mongo:4.0.3 20m 4.0.5-v3 4.0.5 Official mongo:4.0.5 20m 4.1.13-v1 4.1.13 Official mongo:4.1.13 20m 4.1.4-v1 4.1.4 Official mongo:4.1.4 20m 4.1.7-v3 4.1.7 Official mongo:4.1.7 20m 4.2.3 4.2.3 Official mongo:4.2.3 20m 4.4.6 4.4.6 Official mongo:4.4.6 20m 5.0.2 5.0.2 Official mongo:5.0.2 20m 5.0.3 5.0.3 Official mongo:5.0.3 20m percona-3.6.18 3.6.18 Percona percona/percona-server-mongodb:3.6.18 20m percona-4.0.10 4.0.10 Percona percona/percona-server-mongodb:4.0.10 20m percona-4.2.7 4.2.7 Percona percona/percona-server-mongodb:4.2.7-7 20m percona-4.4.10 4.4.10 Percona percona/percona-server-mongodb:4.4.10 20m
As you can see, it even supports Percona Server for MongoDB.
- Sharding. I like that the Community version comes with sharding support as it helps to experiment and understand the future fit of this solution for your environment.
MongoDB Community Operator
Similar to KubeDB, MongoDB Corp follows the open core model. The Community version of the Operator is free, and there is an enterprise version available (MongoDB Enterprise Kubernetes Operator), which is more feature rich.
Deployment
Helm chart is available for this Operator, but at the same time, there is no helm chart to deploy the Custom Resource itself. This makes onboarding a bit more complicated.
Add the repository:
$ helm repo add mongodb https://mongodb.github.io/helm-charts
Install the Operator:
$ helm install community-operator mongodb/community-operator
To deploy the database you need to modify this example and set the password. Once done apply it to deploy the replica set of three nodes:
$ kubectl apply -f mongodb.com_v1_mongodbcommunity_cr.yaml
Features
There are no expectations that anyone would run MongoDB Communty Operator in production as it lacks basic features: backups and restores, sharding, upgrades, etc. But at the same time as always there are interesting ideas that are worth mentioning:
- User provisioning. Described here. You can create a MongoDB database user to authenticate to your MongoDB replica set using SCRAM. You create the Secret object and list users and their corresponding roles.
- Connection string in the secret. Once a cluster is created, you can get the connection string, without figuring out the service endpoints or fetching the user credentials.
"connectionString.standard": "mongodb://my-user:mySupaPass@example-mongodb-0.example-mongodb-svc.default.svc.cluster.local:27017,example-mongodb-1.example-mongodb-svc.default.svc.cluster.local:27017,example-mongodb-2.example-mongodb-svc.default.svc.cluster.local:27017/admin?replicaSet=example-mongodb&ssl=false", "connectionString.standardSrv": "mongodb+srv://my-user:mySupaPass@example-mongodb-svc.default.svc.cluster.local/admin?replicaSet=example-mongodb&ssl=false", "password": "mySupaPass", "username": "my-user"
Percona Operator for MongoDB
Last but not least in our solution list – a fully open source Percona Operator for MongoDB. It was created in 2018 and went through various stages of improvements reaching GA in 2020. The latest release came out in May 2022.
If you are a Percona customer, you will get 24/7 support for the Operator and clusters deployed with it.
Deployment
There are various ways to deploy Percona Operators, and one of them is through Helm charts. One chart for Operator, another one for a database.
Add repository:
$ helm repo add percona https://percona.github.io/percona-helm-charts/
Deploy the Operator:
$ helm install my-operator percona/psmdb-operator
Deploy the cluster:
$ helm install my-db percona/psmdb-db
Features
Operator leverages Percona Distribution for MongoDB and this unblocks various enterprise capabilities right away. The Operator itself is feature rich and provides users with various features that would simplify the migration from your regular MongoDB deployment to Kubernetes: sharding, arbiters, backups and restores, and many more.
Some key features that I would like to mention:
- Automated upgrades. You can set up the schedule of upgrades and the Operator will automatically upgrade your MongoDB cluster’s minor version with no downtime to operations.
- Point-in-time recovery. Percona Backup for MongoDB is part of our Distribution and provides backup and restore functionality in our Operator, and this includes the ability to store oplogs on an object storage of your choice. Read more about it in our documentation.
- Multi-cluster deployment. Percona Operator supports complex topologies with cross-cluster replication capability. The most common use cases are disaster recovery and migrations.
Conclusion
Choosing a solution to deploy and manage MongoDB is an important technical decision, which might impact various business metrics in the future. In this blog post, we summarized and highlighted the pros and cons of various open source solutions to run MongoDB in Kubernetes.
An important thing to remember is that the solution you choose should not only provide a way to deploy the database but also enable your teams to execute various management and maintenance tasks without drowning in MongoDB complexity.