The combination of MongoDB and Kubernetes is a game-changer in database administration. This article will walk you through the process of deploying MongoDB using the Kubernetes MongoDB Operator. Learn how this dynamic combination of Kubernetes MongoDB reduces the difficult task of configuring and managing databases in a complex environment.
Kubernetes represents an open-source container orchestration platform that transforms the manner in which applications are deployed, expanded, and administered within a distributed environment. It offers a remarkably scalable and resilient system to automate the lifecycle management of applications packaged in containers. By utilizing elements such as pods, services, and controllers, Kubernetes abstracts the underlying infrastructure and provides an explicit strategy for deploying and enlarging applications.
This framework incorporates sophisticated scheduling methodologies, load balancing, and mechanisms for discovering services to ensure optimal utilization of resources and peak efficiency. Through its robust API, expandable structure, and integration with cloud-native technologies, Kubernetes has emerged as the industry standard for container orchestration. It enables enterprises to build and run strong, scalable applications with great efficiency.
Kubernetes operators simplify database management. They’re specialized tools automating tasks like provisioning, scaling, and security. Operators enable developers to delegate database management, fostering cloud-native DevOps practices. Leveraging custom resources, operators simplify provisioning through familiar Kubernetes interfaces, while automating upgrades, scalability, security configuration, and disaster recovery.
Developers can experience seamless database management without vendor lock-in by Implementing Kubernetes operators. Operators enable efficient database handling within Kubernetes, reducing the need for extensive Kubernetes knowledge and manual configuration.
MongoDB is a cross-platform, open-source NoSQL database management system. It is designed to be scalable and adaptable while managing and storing massive amounts of data. One of MongoDB’s distinctive features is its document-oriented data model, which stores information as documents with optional JSON-like syntax. As a result, there is greater flexibility and faster development because changing the schema is simple and does not require significant data migrations.
MongoDB uses a distributed design in which data is distributed across multiple servers or shards. This offers horizontal scaling, allowing the database to support increasing data volumes, read and write workloads, and workloads without requiring large hardware changes. MongoDB also includes a number of built-in high availability capabilities, such as replica sets and automatic failover. Even in the event of hardware failures or other disruptions, the database remains accessible and functional.
MongoDB is unique among NoSQL databases in that it uses the whole NoSQL technology while maintaining certain critical features from traditional database systems. MongoDB is well-suited to manage the needs of high-performance, large-scale applications because of its document-oriented design, replication and sharding capabilities, and robust developer ecosystem.
It is simple to work with and integrate into existing systems due to the use of BSON encoding, a flexible schema, and widely available drivers. MongoDB provides a powerful and scalable framework for organizing and storing data in today’s fast-paced environment, whether for corporate or personal use.
Deploying MongoDB in Kubernetes offers a host of advantages for modern database management. Dynamic scalability, automatic load balancing, and efficient resource allocation of Kubernetes align seamlessly with MongoDB’s flexible document-based structure. This combination improves enterprises to effortlessly scale their databases to handle their workloads, enhancing application flexibility and performance. Kubernetes MongoDB enabling organizations to focus more on developing innovative applications rather than dealing with complex infrastructure issues.
We have to set up the environment to deploy MongoDB on Kubernetes using a Kubernetes MongoDB operator. A running Kubernetes cluster and a fundamental understanding of MongoDB queries are required to conduct this tutorial. Here we are using Kind to create our Kubernetes cluster. Additionally, you should install Helm to your Kubernetes cluster.
In this tutorial, We will use the Kubernetes MongoDB operator KubeDB to deploy MongoDB on Kubernetes. First, We must install KubeDB in our Kubernetes cluster. We requires a license to setup KubeDB in our Kubernetes cluster. We can obtain a free enterprise license via the Appscode License Server. To obtain the license we must provide our Kubernetes cluster ID. Run the following command to get the cluster ID.
$ kubectl get ns kube-system -o jsonpath='{.metadata.uid}'
60b010fb-9ad6-4ac6-89f4-7321e697f469
After giving the required information, the license server will send us an email with a “license.txt” file attached. We will run the following commands listed below to install KubeDB.
$ helm repo add appscode https://charts.appscode.com/stable/
$ helm repo update
$ helm install kubedb appscode/kubedb \
--version v2023.06.19 \
--namespace kubedb --create-namespace \
--set kubedb-provisioner.enabled=true \
--set kubedb-ops-manager.enabled=true \
--set kubedb-autoscaler.enabled=true \
--set kubedb-dashboard.enabled=true \
--set kubedb-schema-manager.enabled=true \
--set-file global.license=/path/to/the/license.txt
Verify the installation by the following command,
$ kubectl get pods --all-namespaces -l "app.kubernetes.io/instance=kubedb"
NAMESPACE NAME READY STATUS RESTARTS AGE
kubedb kubedb-kubedb-autoscaler-5d4d9db7b-7tvjx 1/1 Running 0 94s
kubedb kubedb-kubedb-dashboard-7b848bb7c-lk2s5 1/1 Running 0 94s
kubedb kubedb-kubedb-ops-manager-86786bfd4f-bcccw 1/1 Running 0 94s
kubedb kubedb-kubedb-provisioner-7657456794-dmdcs 1/1 Running 0 94s
kubedb kubedb-kubedb-schema-manager-bb9f7b758-7pz5m 1/1 Running 0 94s
kubedb kubedb-kubedb-webhook-server-7f5cbfb695-jndmv 1/1 Running 0 94s
If all of the pod status is running, we can move to the next step.
Now we’ll create a new namespace in which we will deploy MongoDB. We can run the following command to create a namespace,
$ kubectl create namespace mongons
namespace/mongons created
We need to create a yaml manifest to Deploy MongoDB on Kubernetes. And we will apply this yaml manifest below,
apiVersion: kubedb.com/v1alpha2
kind: MongoDB
metadata:
name: mongodb-rs
namespace: mongons
spec:
version: "5.0.3"
replicas: 3
replicaSet:
name: rs0
storage:
storageClassName: "standard"
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 1Gi
terminationPolicy: WipeOut
You can see the detailed yaml specifications in the Kubernetes MongoDB documentation.
We will save this yaml configuration to mongodb.yaml
. Then create the above MongoDB object.
$ kubectl create -f mongodb.yaml
mongodb.kubedb.com/mongodb-rs created
If all the above steps are handled correctly and the MongoDB is deployed, you will see that the following objects are created:
$ kubectl get all -n mongons
NAME READY STATUS RESTARTS AGE
pod/mongodb-rs-0 2/2 Running 0 3m40s
pod/mongodb-rs-1 2/2 Running 0 2m50s
pod/mongodb-rs-2 2/2 Running 0 119s
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
service/mongodb-rs ClusterIP 10.8.1.145 <none> 27017/TCP 3m44s
service/mongodb-rs-pods ClusterIP None <none> 27017/TCP 3m44s
NAME READY AGE
statefulset.apps/mongodb-rs 3/3 3m45s
NAME TYPE VERSION AGE
appbinding.appcatalog.appscode.com/mongodb-rs kubedb.com/mongodb 5.0.3 72s
NAME VERSION STATUS AGE
mongodb.kubedb.com/mongodb-rs 5.0.3 Ready 4m10s
We have successfully deployed MongoDB to Kubernetes via the Kubernetes MongoDB operator. Now, we will connect to the MongoDB database to insert some sample data and verify whether our MongoDB is usable or not. First, check the database status,
$ kubectl get mongodb -n mongons mongodb-rs
NAME VERSION STATUS AGE
mongodb-rs 5.0.3 Ready 5m31s
Here, we should have to obtain necessary credentials in order to connect to the database. Let’s export the credentials as environment variable to our current shell: KubeDB will create Secret and Service for the database mongodb-rs
that we have deployed. Let’s check them,
$ kubectl get secret -n mongons -l=app.kubernetes.io/instance=mongodb-rs
NAME TYPE DATA AGE
mongodb-rs-auth kubernetes.io/basic-auth 2 6m20s
mongodb-rs-key Opaque 1 6m20s
$ kubectl get service -n mongons -l=app.kubernetes.io/instance=mongodb-rs
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
mongodb-rs ClusterIP 10.8.1.145 <none> 27017/TCP 6m39s
mongodb-rs-pods ClusterIP None <none> 27017/TCP 6m39s
Now we’ll use’mongodb-rs-auth’ to export credentials. To make future commands more reusable, export ‘USER’ and ‘PASSWORD’ as environment variables.
$ export USER=$(kubectl get secrets -n mongons mongodb-rs-auth -o jsonpath='{.data.\username}' | base64 -d)
$ export PASSWORD=$(kubectl get secrets -n mongons mongodb-rs-auth -o jsonpath='{.data.\password}' | base64 -d)
Now, we will connect to the MongoDB database using the required credentials and insert some sample data,
$ kubectl exec -it -n mongons mongodb-rs-0 -- mongo admin -u $USER -p $PASSWORD
Defaulted container "mongodb" out of: mongodb, replication-mode-detector, copy-config (init)
MongoDB shell version v5.0.3
rs0:PRIMARY> show dbs
admin 0.000GB
config 0.000GB
kubedb-system 0.000GB
local 0.000GB
rs0:PRIMARY> use musicdb
switched to db musicdb
rs0:PRIMARY> db.songs.insert({"name":"Take Me Home Country Roads"});
WriteResult({ "nInserted" : 1 })
rs0:PRIMARY> db.songs.find().pretty()
{
"_id" : ObjectId("6426c44cdf79c82c76cd3e44"),
"name" : "Take Me Home Country Roads"
}
rs0:PRIMARY> exit
bye
We’ve successfully deployed MongoDB to Kubernetes via Kubernetes MongoDB operator KubeDB. We also connect to the database and insert some sample data into it.
To ensure the stability of your application when deploying MongoDB on Kubernetes, there are some best practices that you should follow:
Version Upgrade: Plan and test version upgrades carefully. MongoDB versions and Kubernetes versions should be compatible, and rolling upgrades are often recommended. A well-executed upgrade strategy avoids disruptions.
Replica Sets for High Availability: Implement MongoDB replica sets for high availability. Each replica set node runs on a separate Kubernetes node, reducing the risk of data loss during node failures. This will upgrade fault tolerance.
Monitoring and Health Checks: Set up health checks and monitoring for MongoDB pods. Kubernetes and MongoDB provide metrics that can be collected and analyzed to identify performance bottlenecks or issues. This proactive monitoring aids in maintaining optimal performance.
Disaster Recovery Options: Develop comprehensive disaster recovery options, including procedures for recovering from data corruption, pod failures, and cluster-wide outages. Having a clear roadmap during crises minimizes downtime.
MongoDB for Kubernetes is a robust and comprehensive solution for managing databases in a Kubernetes context. Here, you have successfully deployed a MongoDB database on Kubernetes using the Kubernetes MongoDB operator, which is appropriate for a wide range of use cases. You can visit the official MongoDB documentation for further details. Managing database operations with the optimal performance and uptime requires substantial expertise and consistent practice. Whether your database infrastructure is hosted on-premises, regionally distributed, or via cloud services or database-as-a-service providers, you can use KubeDB to help you manage the entire process in a production-grade environment.
Trusted by top engineers at the most ambitious companies
InterSystems was delighted to engage with AppsCode in the delicate, yet fundamental task of supporting durable, non-ephemeral workloads with Kubernetes. We needed the best-prepared, most-proficient database operator consulting in the industry. Given AppsCode's pedigree of database building operators, the decision was easy. No time was wasted and all objectives reached in an amazingly short period of time. I would recommend AppsCode consulting for any Kubernetes related work.
Voyager made it simple and efficient for us to protect and initiate our bare metal Kubernetes workload. Its underlying technology and extensive L4 support along with seamless SSL integration is what made us choose Voyager over others. Voyager team is also very responsive when it comes to support. Great product!
Voyager is the easiest way to use the fast and reliable HAProxy as our ingress controller. At PriceHubble, it is the corner-stone of our blue/green deployments.
I work with a few Kubernetes clusters and we use Voyager as our preferred ingress controller. We really like the ease of configuration. Documentation is pretty good. Also the use of HaProxy is important for us because it works really well with both L4 and L7 load balancing. One of our TCP services, Wayk Now, is able to withstand thousands of persistent connections very smoothly at the same time.
We really like using Voyager. Its straightforward and well-documented config and SSL (especially Let's Encrypt) has made our migration of services to Kubernetes a breeze. Each major version has been a very welcome update!
We're using Voyager as part of most Astarte deployments and it's orchestrated also by our brand new Operator. We are glad to showcase that.
Here are a few of the questions we get the most. If you don't see what's on your mind, contact us anytime.
Yes, you can manage as many databases as you want within a single subscription to KubeDB, and there is no extra charge for that!
Yes, of course! KubeDB is platform-independent. You can use KubeDB in any cloud or on-premises.
KubeDB is running in production by multiple Governments and large organizations. Your data is always safe within KubeDB.
We offer 24x7 technical system and maintain SLA to provide 100% reliability to our customers.
Yes, Stash is seemingly integrated with KubeDB. There is no extra charge for using Stash. It is complimentary with KubeDB.
Of course! We offer a 30 days license free of cost to try all features of KubeDB Enterprise Edition.
Yes, you can seemlessly upgrade from the Community edition to the Enterprise Edition without any downtime.
There is no cancellation fee. But plans are subject to minimum duration (1 year) as stated above.
We prefer ACH transfer for US based customers and international wire transfer for everyone else. We can also accept all popular credit/debit cards such as Visa, Mastercard, American Express, Discover, etc.
Yes! For ACH transfer and wire transfer you work with your bank for payment. Our credit card processing is powerd by Stripe. You credit card data never touches our servers. For more information, please visit stripe.com.
KubeDB community edition is FREE to use on any supported Kubernetes engines. You can deploy and manage your database in Kubernetes using KubeDB. There is no up-front investment required. We offer a 30 days license FREE of cost to try KubeDB Enterprise edition.