Application Deployment in Kubernetes with the MongoDB Atlas Operator
Joel Lord, Cedric ClyburnPublished Aug 16, 2022 • Updated Sep 21, 2022
Rate this tutorial
Kubernetes is now an industry-wide standard when it comes to all things containers, but when it comes to deploying a database, it can be a bit tricky! However, tasks like adding persistence, ensuring redundancy, and database maintenance can be easily handled with MongoDB Atlas. Fortunately, the MongoDB Atlas Operator gives you the full benefits of using MongoDB Atlas, while still managing everything from within your Kubernetes cluster. In this tutorial, we’ll deploy a MERN stack application in Kubernetes, install the Atlas operator, and connect our back end to Atlas using a Kubernetes secret.
When it comes to deploying a database on Kubernetes, there’s no simple solution. Apart from persistence and redundancy challenges, you may need to move data to specific geolocated servers to ensure that you comply with GDPR policies. Thus, you’ll need a reliable, scalable, and resilient database once you launch your application into production.
MongoDB Atlas is a full developer data platform that includes the database you love, which takes care of many of the database complexities you’re used to. But, there is a gap between MongoDB Atlas and your Kubernetes cluster. Let’s take a look at the MongoDB Atlas Operator by deploying the example MERN application with a back end and front end.
This application uses a three-tier application architecture, which will have the following layout within our Kubernetes cluster:
To briefly overview this layout, we’ve got a back end with a deployment that will ensure we have two pods running at any given time, and the same applies for our front end. Traffic is redirected and configured by our ingress, meaning
/apirequests route to our back end and everything else will go to the front end. The back end of our application is responsible for the connection to the database, where we’re using MongoDB Atlas Operator to link to an Atlas instance.
To simplify the installation process of the application, we can use a single
kubectlcommand to deploy our demo application on Kubernetes. The single file we’ll use includes all of the deployments and services for the back end and front end of our application, and uses containers created with the Dockerfiles in the folder.
First, start by cloning the repository that contains the starting source code.
Secondly, as part of this tutorial, you’ll need to run
minikube tunnelto access our services at
Now, let’s go ahead and deploy everything in our Kubernetes cluster by applying the following
You can take a look at what you now have running in your cluster by using the
You should see multiple pods, services, and deployments for the back end and front end, as well as replicasets. At the moment, they are more likely in a ContainerCreating status. This is because Kubernetes needs to pull the images to its local registry. As soon as the images are ready, the pods will start.
To see the application in action, simply head to
localhostin your web browser, and the application should be live!
However, you’ll notice there’s no way to add entries to our application, and this is because we haven’t provided a connection string yet for the back end to connect to a MongoDB instance. For example, if we happen to check the logs for one of the recently created backend pods, we can see that there’s a placeholder for a connection string.
We’ve ran into a slight issue, as this demo application is using a placeholder (
$ATLAS_CONNECTION_STRING) for the MongoDB connection string, which needs to be replaced by a valid connection string from our Atlas cluster. This issue can be taken care of with the MongoDB Atlas Operator, which allows you to manage everything from within Kubernetes and gives you the full advantages of using MongoDB Atlas, including generating a connection string as a Kubernetes secret.
As there’s currently a gap between your Kubernetes cluster and MongoDB Atlas, let’s use the Atlas Operator to remedy this issue. Through the operator, we’ll be able to manage our Atlas projects and clusters from Kubernetes. Specifically, getting your connection string to fix the error we received previously can be done now through Kubernetes secrets, meaning we won’t need to retrieve it from the Atlas UI or CLI.
The Atlas Operator bridges the gap between Atlas, the MongoDB data platform, and your Kubernetes cluster. By using the operator, you can use
kubectland your familiar tooling to manage and set up your Atlas deployments. Particularly, it allows for most of the Atlas functionality and tooling to be performed without having to leave your Kubernetes cluster. Installing the Atlas operator creates the Custom Resource Definitions that will connect to the MongoDB Atlas servers.
The installation process for the Atlas Operator is as simple as running a
kubectlcommand. All of the source code for the operator can be found on the Github repository.
This will create new custom resources in your cluster that you can use to create or manage your existing Atlas projects and clusters.
If you haven't already, head to the Atlas Registration page to create your free account. This account will let you create a database on a shared server, and you won't even need a credit card to use it.
In order for the operator to be able to manage your cluster, you will need to provide it with an API key with the appropriate permissions. Firstly, let’s retrieve the organization ID.
In the upper left part of the Atlas UI, you will see your organization name in a dropdown. Right next to the dropdown is a gear icon. Clicking on this icon will open up a page called Organization Settings. From this page, look for a box labeled Organization ID.
Save that organization ID somewhere for future use. You can also save it in an environment variable.
Note: If using Windows, use:
Next, let’s create an API key. From the same screen, look for the Access Manager option in the left navigation menu. This will bring you to the Organization Access screen. In this screen, follow the instructions to create a new API key.
The key will need the Organization Project Creator role in order to create new projects and clusters. If you want to manage existing clusters, you will need to provide it with the Organization Owner role. Save the API private and public keys. You can also add them to the environment.
Note: If using Windows, use:
Now that you have created the API key, you can specify those values to the MongoDB Atlas Operator. By creating this secret in our Kubernetes cluster, this will give the operator the necessary permissions to create and manage projects and clusters for our specific Atlas account.
You can create the secret with
kubectl, and to keep it simple, let’s name our secret
mongodb-atlas-operator-api-key. For the operator to be able to find this secret, it needs to be within the namespace
Next, we’ll need to label this secret, which helps the Atlas operator in finding the credentials.
We’ll need a password for our database user in order to access our databases, create new databases, etc. However, you won't want to hard code this password into your yaml files. It’s safer to save it as a Kubernetes secret. Just like the API key, this secret will need to be labeled too.
Congrats! You are now ready to manage your Atlas projects and deployments from Kubernetes. This can be done with the three new CRDs that were added to your cluster. Those CRDs are
AtlasProjectto manage projects,
AtlasDeploymentto manage deployments, and
AtlasDatabaseUserto manage database users within MongoDB Atlas.
- Projects: Allows you to isolate different database environments (for instance, development/qa/prod environments) from each other, as well as users/teams.
- Deployments: Instance of MongoDB running on a cloud provider.
- Users: Database users that have access to MongoDB database deployments.
The process of creating a project, user, and deployment is demonstrated below, but feel free to skip down to simply apply these files by using the
Start by creating a new project in which the new cluster will be deployed. In a new file called
/operator/project.yaml, add the following:
This will create a new project called "MERN K8s" in Atlas. Now, this project will be open to anyone on the web. It’s best practice to only open it to known IP addresses as mentioned in the comment.
Now, in order for your application to connect to this database, you will need a database user. To create this user, open a new file called
/operator/user.yaml, and add the following:
You can see how the password uses the secret we created earlier,
atlaspassword, in the
Finally, as you have a project setup and user to connect to the database, you can create a new deployment inside this project. In a new file called
/operator/deployment.yaml, add the following yaml.
This will create a new M0 (free) deployment on AWS, in the US_EAST_1 region. Here, we’re referencing the
mern-k8s-projectin our Kubernetes namespace, and creating a cluster named
Cluster0. You can use a similar syntax to deploy in any region on AWS, GCP, or Azure. To create a serverless instance, see the serverless instance example.
You now have everything ready to create this new project and cluster. You can apply those new files to your cluster using:
This will take a couple of minutes. You can see the status of the cluster and project creation with
In the meantime, you can go to the Atlas UI. The project should already be created, and you should see that a cluster is in the process of being created.
Getting your connection string to that newly created database can now be done through Kubernetes. Once your new database has been created, you can use the following command that uses
jqto view the connection strings, without using the Atlas UI, by converting to JSON from Base64.
Now that your project and cluster are created, you can access the various properties from your Atlas instance. You can now access the connection string, and even configure your backend service to use that connection string. We’ll go ahead and connect our back end to our database without actually specifying the connection string, instead using the Kubernetes secret we just created.
Now that you can find your connection string from within Kubernetes, you can use that as part of your deployment to specify the connection string to your back end.
/k8s/application.yamlfile, change the
envsection of the containers template to the following:
This will use the same connection string you've just seen in your terminal.
Since we’ve changed our deployment, you can apply those changes to your cluster using
Now, if you take a look at your current pods:
You should see that your backend pods have been restarted. You should now be able to test the application with the back end connected to our newly created Atlas cluster. Now, just head to
localhostto view the updated application once the deployment has restarted. You’ll see the application fully running, using this newly created cluster.
In addition, as you add items or perhaps clear the entries of the travel planner, you’ll notice the entries added and removed from the “Collections” tab of the
Cluster0database within the Atlas UI. Let’s take a look at our database using MongoDB Compass, with username
mernk8sas we set previously.
Let’s finish off by using
kubectlto delete the Atlas cluster and project and clean up our workspace. We can delete everything from the current namespace by using
You now know how to leverage the MongoDB Atlas Operator to create and manage clusters from Kubernetes. We’ve only demonstrated a small bit of the functionality the operator provides, but feel free to head to the documentation to learn more.
If you are using MongoDB Enterprise instead of Atlas, there is also an Operator available, which works in very similar fashion.
To go through the full lab by Joel Lord, which includes this guide and much more, check out the self-guided Atlas Operator Workshop.