This blog was originally published in August 2022 and was updated in January 2024.
In this blog, we’ll examine the increasingly popular practice of deploying MongoDB on Kubernetes and explore various approaches to this setup. From direct deployments as a stateful application to utilizing specialized operators and considering cloud-based solutions, we’ll guide you through the key factors and considerations.
The most common use cases for running databases on 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 on 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. Before we dive into the specific MongoDB Kubernetes solutions, we will first explore the different use cases and benefits.
Use cases of MongoDB on Kubernetes
Using MongoDB on Kubernetes for large-scale applications that require dynamic scaling is one of the most compelling use cases. In contexts with unpredictable and fluctuating workloads, Kubernetes performs exceptionally well. An e-commerce platform, for instance, may see fluctuations in traffic, particularly during periods of peak shopping seasons or promotional events. MongoDB on Kubernetes can automatically scale up to handle increased load and then scale down during quieter periods, ensuring efficient resource utilization and consistent performance.
Another key scenario is businesses that prioritize high availability for their databases. Kubernetes is an excellent choice for any industry where maintaining database uptime is crucial, such as finance, healthcare, or any other business. By deploying MongoDB on Kubernetes, these businesses can leverage the platform’s ability to manage multiple replicas of MongoDB instances, ensuring that if one instance goes down, others can seamlessly take over, thus minimizing downtime and maintaining service availability.
In situations where Kubernetes is already an integral part of the infrastructure, MongoDB on Kubernetes is highly advantageous. It makes sense for businesses that have invested in Kubernetes to expand its capabilities to include database management for their apps. This approach leads to a more unified and streamlined infrastructure, where both applications and databases benefit from Kubernetes’ features like self-healing, automated rollouts and rollbacks, and easy management of deployment patterns.
Why run MongoDB on Kubernetes?
Running MongoDB on Kubernetes brings together the robust, feature-rich capabilities of MongoDB and the operational efficiency of Kubernetes. This integration leverages a combination that significantly enhances database management and operations.
Scalability:
One of the standout benefits of Kubernetes is the effortless scaling of MongoDB instances, particularly valuable in handling fluctuating workloads. Kubernetes can dynamically allocate resources based on current demands, which means it can seamlessly scale MongoDB instances up during peak loads and scale down when demand wanes.
High availability:
Kubernetes manages MongoDB replicas across different nodes, ensuring that if one instance fails, others are readily available to take over without disrupting service. This setup minimizes downtime and ensures continuous database availability, crucial for maintaining uninterrupted operations.
For more in-depth information on database high availability, you might find these resources valuable: The Ultimate Guide to Database High Availability and Percona’s High Availability Support Services.
Efficient resource utilization:
In addition to streamlining MongoDB operations, Kubernetes maximizes resource use. Based on real-time requirements, it dynamically distributes hardware resources, such as CPU and memory, to MongoDB instances, ensuring that the database operates efficiently without overutilizing or underutilizing resources.
Flexibility:
Running MongoDB on Kubernetes offers the flexibility to deploy MongoDB in various environments, be it cloud-based, on-premises, or a hybrid of both. This versatility is crucial for businesses operating in diverse IT environments or those transitioning between them.
Watch Now: MongoDB in the Cloud: How to Reduce Costs Using Open-Source Components and Kubernetes
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:
1 | $ 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:
1 | $ 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:
1 | $ helm repo add appscode https://charts.appscode.com/stable/ |
Install the Operator:
1 2 3 4 | $ 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.
1 | $ 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:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 | $ 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:
1 | $ helm repo add mongodb https://mongodb.github.io/helm-charts |
Install the Operator:
1 | $ 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:
1 | $ kubectl apply -f mongodb.com_v1_mongodbcommunity_cr.yaml |
Features
There are no expectations that anyone would run MongoDB Community 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.
1 2 3 4 | "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:[email protected]/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:
1 | $ helm repo add percona https://percona.github.io/percona-helm-charts/ |
Deploy the Operator:
1 | $ helm install my-operator percona/psmdb-operator |
Deploy the cluster:
1 | $ 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.
Tips for tuning MongoDB performance in Kubernetes
Optimizing MongoDB performance within a Kubernetes environment is crucial for ensuring efficient database operation and maintaining application responsiveness. Here are some key tips for tuning MongoDB performance in Kubernetes:
1. Proper resource allocation for MongoDB pods:
Ensuring your MongoDB Kubernetes pods have enough CPU, memory, and network resources is essential for optimal performance. Allocate resources in accordance with the workload and performance indicators observed. It’s important to avoid over or under-provisioning; over-provisioning can lead to wasted resources, while under-provisioning can result in poor database performance. Regular monitoring and adjustments based on performance data can help maintain a balance.
2. Choosing high-performance storage solutions:
Storage plays a vital role in how well MongoDB performs in Kubernetes. To greatly increase I/O performance, choose high-performance storage options like Solid State Drives, or SSDs. Compared to conventional HDDs (Hard Disk Drives), SSDs provide faster data access speeds. This results in faster read/write operations, which are essential for databases like MongoDB that handle large volumes of data transactions
3. Improving MongoDB indexes:
Optimizing indexes is a key factor in enhancing MongoDB’s query performance in Kubernetes. Well-thought-out indexes offer efficient query processing and minimize unnecessary data scanning. Review and update the indexes regularly based on current usage patterns and query performance metrics. To improve query performance, get rid of any unnecessary or duplicate indexes and, if needed, consider creating compound indexes.
4. Configuring sharding appropriately:
A powerful feature for handling large data sets and high throughput operations in MongoDB is sharding. Properly configuring sharding involves distributing data across multiple MongoDB instances, which helps balance the load and improve performance. Selecting the appropriate shard key is crucial because an effective shard key evenly distributes data and operations across shards. Maintain a close eye on query performance and data distribution to make sure the sharding strategy holds up as data volumes increase and access patterns change.
Discover multi-database support your team can count on. Learn about Percona Support.
Get started with Percona Operator for MongoDB
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 on Kubernetes.
An important thing to remember is that the MongoDB Kubernetes 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.
Designed with both efficiency and simplicity in mind, the Percona Operator for MongoDB not only streamlines the deployment of MongoDB on Kubernetes but also automates the entire lifecycle of cloud-native MongoDB database operations. It offers a range of functionalities like installation, configuration, high availability, and expanded clustering. With our operator, you gain enterprise-grade features, unrestricted portability, and compatibility with popular Kubernetes flavors. Choose the Percona Operator for MongoDB for a seamless, automated, and efficient MongoDB management experience on Kubernetes.
Learn More About Percona Operator for MongoDB
MongoDB Kubernetes FAQs
What are the key benefits of running MongoDB on Kubernetes?
Running MongoDB on Kubernetes offers significant benefits, such as enhanced scalability that allows MongoDB instances to adapt quickly to changing workloads, high availability through distributed replicas across nodes, and automated management of routine tasks like deployment and backups.
How does Kubernetes enhance the scalability of MongoDB deployments?
Kubernetes significantly enhances the scalability of MongoDB deployments by enabling horizontal scaling, which allows for the effortless addition or removal of MongoDB instances in response to workload changes. This is complemented by Kubernetes’ load balancing capabilities, which evenly distribute traffic and workload across all available instances, ensuring optimal performance and efficiency.
What are the primary challenges of implementing MongoDB in Kubernetes environments?
Implementing MongoDB in Kubernetes environments presents challenges such as ensuring data persistence in a dynamic containerized environment, managing stateful applications in what is primarily a stateless system, and configuring efficient storage solutions.
Can MongoDB on Kubernetes ensure high availability for databases?
Yes, MongoDB on Kubernetes can ensure high availability for databases. Kubernetes’ architecture supports the deployment of MongoDB replicas across different nodes, providing redundancy and failover capabilities. This setup allows for continuous database operation, even in the event of individual node failures, thereby maintaining high availability and minimizing downtime.
How does Kubernetes impact the performance of MongoDB?
Kubernetes positively impacts the performance of MongoDB by providing a robust and flexible infrastructure that allows for efficient management of resources. The orchestration system automatically adjusts resource allocation based on demand, ensuring MongoDB runs optimally under varying loads
