✅ Subscribe to MongoDB Atlas on Google Cloud: <a href="https://bit.ly/3KOx4H9" target="_blank" rel="noreferrer">https://bit.ly/3KOx4H9</a>
The MongoDB Atlas Navigation has been enhanced to provide a more intuitive and streamlined experience. Discover the updates here: <a href="https://mdb.link/AtlasUpdate" target="_blank" rel="noreferrer">https://mdb.link/AtlasUpdate</a>

In this video, we’ll setup a MERN stack application in just minutes, and use the Kubernetes Atlas operator to connect our backend to Atlas using a Kubernetes secret.

📚 For readers, here is a written version:
<a href="https://www.mongodb.com/developer/products/atlas/kubernetes-operator-application-deployment/" target="_blank" rel="noreferrer">https://www.mongodb.com/developer/products/atlas/kubernetes-operator-application-deployment/</a>

😎 Connect with Cedric:
Twitter: <a href="https://twitter.com/cedricclyburn" target="_blank" rel="noreferrer">https://twitter.com/cedricclyburn</a>
LinkedIn: <a href="https://www.linkedin.com/in/cedricclyburn" target="_blank" rel="noreferrer">https://www.linkedin.com/in/cedricclyburn</a>

⏱️ Timestamps ⏱️
0:00 Introduction
00:24: Prerequisites
00:43: Getting started
04:13: Using the MongoDB Atlas Operator for Kubernetes
08:35: Create and manage an Atlas deployment
12:49: Configure the application back end using the Atlas operator

---
Subscribe to MongoDB  ➡️  <a href="https://bit.ly/3bpg1Z1" target="_blank" rel="noreferrer">https://bit.ly/3bpg1Z1</a>

#mongodb #kubernetes #database

JavaScript

Application Deployment in Kubernetes with the MongoDB Atlas Operator

✅ Try MongoDB 8.0 → <a href="https://mdb.link/9ARMhe_cV0Y" target="_blank" rel="noreferrer">https://mdb.link/9ARMhe_cV0Y</a>
✅ Sign-up for a free cluster → <a href="https://mdb.link/9ARMhe_cV0Y" target="_blank" rel="noreferrer">https://mdb.link/9ARMhe_cV0Y</a>-register
✅ Subscribe to MongoDB YouTube→ <a href="https://mdb.link/subscribe" target="_blank" rel="noreferrer">https://mdb.link/subscribe</a>
-
In this episode of the MongoDB Podcast, live from .local London, Shane McAllister and Luce Carter explore the latest advancements in MongoDB's developer tools and their new support for multi-cluster Kubernetes. They discuss how MongoDB integrates Kubernetes’ scalability and resiliency, developer tools like GitHub Copilot, generative AI in MongoDB Charts, and IntelliJ's integration. Learn how these tools empower developers to build better, faster applications with ease. Plus, insights into the future of cloud-native applications and automation.

MongoDB

Advancing Developer Tools and Multi-Cluster Kubernetes: Insights from MongoDB Experts

Introduction and World Tour Announcement

Developer Center Updates and Tutorials

Podcast Episodes and Community Highlights

Community Events and User Group Meetings

Hackathon Sponsorship and Global Meetups

Deep Dives into MongoDB Applications

Upcoming Events and Final Thoughts

✅ Sign-up for a free cluster at → <a href="https://www.mongodb.com/cloud/atlas/register" target="_blank" rel="noreferrer">https://www.mongodb.com/cloud/atlas/register</a>
✅ Get help on our Community Forums → <a href="https://www.mongodb.com/community/forums/" target="_blank" rel="noreferrer">https://www.mongodb.com/community/forums/</a>
✅ <a href="<a href="https://mdb.link/index/may20" target="_blank" rel="noreferrer">https://mdb.link/index/may20</a>" target="_blank" rel="noreferrer"><a href="https://mdb.link/index/may20" target="_blank" rel="noreferrer">https://mdb.link/index/may20</a></a>


In this MongoDB video, we'll explore the latest updates and educational content provided by MongoDB's Developer Relations Team. Megan, the editor, guides us through a variety of resources, including tutorials, podcasts, and community contributions that can help you stay informed and enhance your MongoDB skills. Whether you're interested in AI, database migration, or performance tuning, this video is packed with insights and tips directly from the experts.

📚 RESOURCES 📚
<a href="<a href="https://mdb.link/index/may20" target="_blank" rel="noreferrer">https://mdb.link/index/may20</a>" target="_blank" rel="noreferrer"><a href="https://mdb.link/index/may20" target="_blank" rel="noreferrer">https://mdb.link/index/may20</a></a>


⏱️ Timestamps ⏱️
Introduction and MongoDB Updates [00:00:00 - 00:02:06]
Megan from MongoDB's Developer Relations team welcomes viewers and encourages them to subscribe for updates. She highlights the MongoDB World Tour and shares a discount code for event registration.

Developer Center Highlights and Tutorials [00:02:07 - 00:04:13]
The chapter showcases new content on the Developer Center, including tutorials on EF Core, data capture from MySQL to MongoDB Atlas, and AI-assisted query conversion. It also covers MongoDB orchestration with Spring and Kubernetes.

Community Insights and Events [00:04:14 - 00:06:20]
Megan discusses the active MongoDB community, including podcasts, blog posts, and user group meetups around the world. She emphasizes the importance of community contributions and previews upcoming events and resources.

------
✅ Subscribe to our channel → <a href="https://mdb.link/subscribe" target="_blank" rel="noreferrer">https://mdb.link/subscribe</a>
#MongoDB #TheIndex #Tech

welcome back to the index I'm Megan the editor for mongod DB's developer relations team and I'm here to get you caught up on some of the cool stuff you might have missed lately before I dive in be sure to hit the Subscribe button so you never miss a new video from us and remember that if you want even more information about what we've been up to lately just scroll down and click the link in the description [Music] [Applause] below mongodb is heading out on a world tour to bring the best content directly to you with stops in Mexico City Berlin Paris Stockholm Sydney Austin and Singapore with even more cities being added soon use code Community 50 for 50% off your registration what's new on developer Center loose will show you what's happening in the mongodb provider for EF core in this tutorial annia will show you how to conduct change data captures from your relational data from MySQL to mongod B Atlas using confluent cloud and relational migrator in this introduction to query converter Nick will demonstrate how to migrate from an rdbms to mongod DB with the help of AI and asawari is talking about mongod DB orchestration with spring and Atlas kubernetes operator plus harad explores rag with Atlas Vector search Lang chain and open Ai and Baboo Igor and Eric launched a fully managed rag workflow with [ __ ] DB Atlas and Amazon Bedrock if you haven't spent much time on our YouTube channel lately why grab a snack get comfy and check out this video from Nick he'll show you how to easily translate SQL queries to mongod DB queries plus Jorge has also released Parts two and three of his intro to go series if you're in a hurry and want to watch something quickly be sure to check out our shorts where you can learn something new in 60 seconds or less looking for something to listen to on the drive to work our podcast is where you'll want to be in our latest episode host Michael sits down with verage a distinguished mongod DB Community Creator we delve into vj's fascinating Journey as a mongod DB Enthusiast and explore the depths of his recent presentation unified workloads with AWS and mongod DB which he gave at the AWS Community Day as always our community has been hard at work spreading the word about mongod DB we had an incred inredible time at mongod db. loal NC check out Community Creator Justin's blog post which highlights his key insights and top takeaways community champion aric published a new video tutorial boosting AI build a chatot with your data this also includes linkchain templates using the rag pattern and expands on his developer Center article on the same topic Community Creator Fabio published his second tutorial on developer Center efficient sync Solutions cluster to Cluster sync and live migration to Atlas Community Creator Danielle authored the article mongodb certification lessons and insights after one year Community Creator otavio was recently featured on our live stream where he shared insights on using mongodb alongside Java and Community Creator foso authored an article on no. JS and mongodb performance tuning tips mongodb recently sponsored the true era hackathon over 2,000 developers participated and 103 teams formed with 16 of 26 teams submitting projects utilizing Atlas Vector search congratulations to the winners and all who attended every month all around the globe folks in the mongodb community meet up for mongodb user groups or mugs as we like to call them mug Brisbane led by Thiago kicked off its first ever Meetup with a deep dive into nosql databases architecture and chatbot Frameworks Tate from Queensland Health shared insights into mongodb's role in healthcare while Thomas from mongodb unveiled the intricacies of building AI chatbots with our chatbot framework the Boston mug organized by Chuck happened in collaboration with the Boston user group at alaso attendees explored the practical application of generative AI on AWS with mongod Atlas alongside the integration of mongodb Atlas with awsam for enhanced security measures hosted by alaso a cyber security company the event offered insights into ransomware detection and data protection strategies eigor from AWS discussed building generative AI applications with mongodb Atlas on AWS while Scott Senior Solutions architect at mongodb delved into streamlining sec through mongodb Atlas and awsam integration at the London mug organized by Sonni attendees gained insights into Legacy system migration and advanced search techniques Community Creator John highlighted challenges and strategies in decommissioning Legacy Insurance systems while loose explored full text search and Vector search with blazer the Pune mug led by fisen and vishall organized its third Meetup in collaboration with the AWS user group The Event showcased topics such as cluster to Cluster sync in mongodb by fisen database migrations with AWS presented by rouf and securing mongodb data on AWS by vishall we are always adding new events to our calendar bookmark the main events page on developer Center so that you can always stay on top of what's happening in your neighborhood if you made it this far it means that you like this video and it would mean the world to me if you could give it a thumbs up and if you haven't already subscribe to our channel so you never miss an update and don't forget that if you want even more information about everything I shared in this video just scroll down and click the link in the description below to view the written version of the index all right that's all for today see you next time 

In this MongoDB video, we'll explore the latest updates and educational content provided by MongoDB's Developer Relations Team. Megan, the editor, guides us through a variety of resources, including tutorials, podcasts, and community contributions that can help you stay informed and enhance your MongoDB skills. Whether you're interested in AI, database migration, or performance tuning, this video is packed with insights and tips directly from the experts.

The Index: RAG With Atlas Vector Search, an Intro to Go, and More

Rutuja Rajwade

Product Marketing Manager

Tim Kelly

Developer Advocate

Learn how to deploy MongoDB Atlas Vector Search, Atlas Search, and Search Nodes using the Atlas Kubernetes Operator. This tutorial covers step-by-step instructions to integrate advanced search capabilities into Kubernetes clusters, enabling scalable, high-performance workloads with MongoDB Atlas.

How to Deploy Vector Search, Atlas Search, and Search Nodes With the Atlas Kubernetes Operator

Joel Lord

Cedric Clyburn

Developer Advocate Intern

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](https://www.mongodb.com/atlas/database). Fortunately, the [MongoDB Atlas Operator](https://www.mongodb.com/kubernetes/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](https://www.mongodb.com/languages/mern-stack-tutorial) stack application in Kubernetes, install the Atlas operator, and connect our back end to Atlas using a Kubernetes secret.

## Pre-requisites
* [`kubectl`](https://kubernetes.io/docs/tasks/tools/)
* [`minikube`](https://minikube.sigs.k8s.io/docs/)
* [`jq`](https://github.com/stedolan/jq/)

You can find the complete source code for this application on [Github](https://github.com/mongodb-developer/mern-k8s). It’s a mini travel planner application using MongoDB, Express, React, and Node ([MERN](https://www.mongodb.com/languages/mern-stack-tutorial)). While this tutorial should work for any Kubernetes cluster, we’ll be using Minikube for simplicity and consistency.

## Getting started

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 modern database 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:

![Kubernetes architecture with the Atlas Operator](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/kubernetes_layout_885ae9b68e.jpg)

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 `/api` requests 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. 


## Deploying the application on Kubernetes

To simplify the installation process of the application, we can use a single `kubectl` command 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.

```
git clone https://github.com/mongodb-developer/mern-k8s.git

cd mern-k8s
```

Secondly, as part of this tutorial, you’ll need to run `minikube tunnel` to access our services at `localhost`.

```
minikube tunnel
```

Now, let’s go ahead and deploy everything in our Kubernetes cluster by applying the following `application.yaml` file.

```
kubectl apply -f k8s/application.yaml
```

You can take a look at what you now have running in your cluster by using the `kubectl get` command.

```
kubectl get all
```

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 `localhost` in your web browser, and the application should be live!

![Browser view of the demo application](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/initial_demo_b606f20aad.jpg)

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.

```
kubectl logs pod/mern-k8s-back-d566cc88f-hhghl

Connecting to database using $ATLAS_CONNECTION_STRING
Server started on port 3000
MongoParseError: Invalid scheme, expected connection string to start with "mongodb://" or "mongodb+srv://"
```

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.

## Using the MongoDB Atlas Operator for Kubernetes

As there’s currently a gap between your Kubernetes cluster and MongoDB Atlas, let’s use the [Atlas Operator](https://www.mongodb.com/kubernetes/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.


### Why use the Operator?

The Atlas Operator bridges the gap between Atlas, the MongoDB data platform, and your Kubernetes cluster. By using the operator, you can use `kubectl` and 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.


### Installing the Atlas Operator

The installation process for the Atlas Operator is as simple as running a `kubectl` command. All of the source code for the operator can be found on the [Github repository](https://github.com/mongodb/mongodb-atlas-kubernetes).

```
kubectl apply -f https://raw.githubusercontent.com/mongodb/mongodb-atlas-kubernetes/main/deploy/all-in-one.yaml
```

This will create new custom resources in your cluster that you can use to create or manage your existing Atlas projects and clusters.

### Creating a MongoDB Atlas cluster 

If you haven't already, head to the [Atlas Registration](https://www.mongodb.com/cloud/atlas/register) 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.

### Set up access

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_. 

![Navigating to the organization settings page](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/organization_settings_home_7c3f0daa0e.jpg)

Save that organization ID somewhere for future use. You can also save it in an environment variable.

```
export ORG_ID=60c102....bd
```

>Note: If using Windows, use:

```
set ORG_ID=60c102....bd
```

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](https://www.mongodb.com/docs/atlas/configure-api-access/#std-label-create-org-api-key) to create a new API key.

![Creating a new API key from the access manager page](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/access_manager_tab_d4bf976fb7.jpg)

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.

![Storing the public and private API key information](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/api_key_credentials_bcc611f1f0.png)

```
export ATLAS_PUBLIC_KEY=iwpd...i
export ATLAS_PRIVATE_KEY=e13debfb-4f35-4...cb
```

>Note: If using Windows, use:

```
set ATLAS_PUBLIC_KEY=iwpd...i
set ATLAS_PRIVATE_KEY=e13debfb-4f35-4...cb
```

### Create the Kubernetes secrets

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 `mongodb-atlas-system`.

```
kubectl create secret generic mongodb-atlas-operator-api-key \
    --from-literal="orgId=$ORG_ID" \
    --from-literal="publicApiKey=$ATLAS_PUBLIC_KEY" \
    --from-literal="privateApiKey=$ATLAS_PRIVATE_KEY" \
    -n mongodb-atlas-system
```

Next, we’ll need to label this secret, which helps the Atlas operator in finding the credentials.

```
kubectl label secret mongodb-atlas-operator-api-key atlas.mongodb.com/type=credentials -n mongodb-atlas-system
```

### Create a user password

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.

```
kubectl create secret generic atlaspassword --from-literal="password=mernk8s"
kubectl label secret atlaspassword atlas.mongodb.com/type=credentials
```

## Create and manage an Atlas deployment

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 `AtlasProject` to manage projects, `AtlasDeployment` to manage deployments, and `AtlasDatabaseUser` to 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 `/atlas` folder.
### Create a project

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:
```
apiVersion: atlas.mongodb.com/v1
kind: AtlasProject
metadata:
  name: mern-k8s-project
spec:
  name: "MERN K8s"
  projectIpAccessList:
    - ipAddress: "0.0.0.0/0"
      comment: "Allowing access to database from everywhere (only for Demo!)"
```

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.

### Create a new database user

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:

```
apiVersion: atlas.mongodb.com/v1
kind: AtlasDatabaseUser
metadata:
  name: atlas-user
spec:
  roles:
    - roleName: "readWriteAnyDatabase"
      databaseName: "admin"
  projectRef:
    name: mern-k8s-project
  username: mernk8s
  passwordSecretRef:
    name: atlaspassword
```

You can see how the password uses the secret we created earlier, `atlaspassword`, in the `mern-k8s-project` namespace.

### Create a deployment

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.

```
apiVersion: atlas.mongodb.com/v1
kind: AtlasDeployment
metadata:
  name: mern-k8s-cluster
spec:
  projectRef:
    name: mern-k8s-project
  deploymentSpec:
    name: "Cluster0"
    providerSettings:
      instanceSizeName: M0
      providerName: TENANT
      regionName: US_EAST_1
      backingProviderName: AWS
```

This will create a new M0 (free) deployment on AWS, in the US_EAST_1 region. Here, we’re referencing the `mern-k8s-project` in 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. 


### Apply the new files

You now have everything ready to create this new project and cluster. You can apply those new files to your cluster using:

```
kubectl apply -f ./operator
```

This will take a couple of minutes. You can see the status of the cluster and project creation with `kubectl`.

```
kubectl get atlasprojects
kubectl get atlasdeployments
```

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.

![Viewing the newly created cluster](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/database_deployments_18fac98898.jpg)

### Get your connection string

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 `jq` to view the connection strings, without using the Atlas UI, by converting to JSON from Base64. 

```
kubectl get secret mern-k8s-cluster0-mernk8s -o json | jq -r '.data | with_entries(.value |= @base64d)'

{
…
  "connectionStringStandard": "![](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/api_key_credentials_bcc611f1f0.png)",
  "connectionStringStandardSrv": "mongodb+srv://mernk8s:mernk8s@cluster0.fb4qw.mongodb.net",
  "password": "mernk8s",
  "username": "mernk8s"
}
```

## Configure the application back end using the Atlas operator

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.

### Update the backend deployment

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.

In your `/k8s/application.yaml` file, change the `env` section of the containers template to the following:

```
          env: 
            - name: PORT
              value: "3000"
            - name: "CONN_STR"
              valueFrom:
                secretKeyRef:
                  name: mern-k8s-cluster0-mernk8s
                  key: connectionStringStandardSrv
```

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 `kubectl`:

```
​​kubectl apply -f k8s/application.yaml
```

Now, if you take a look at your current pods:

```
kubectl get 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 `localhost` to view the updated application once the deployment has restarted. You’ll see the application fully running, using this newly created cluster.  

![Fully functioning demo application, connected to MongoDB Atlas](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/Travel_Demo_3d8885d4a0.gif)

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 `Cluster0` database within the Atlas UI. Let’s take a look at our database using [MongoDB Compass](https://www.mongodb.com/products/compass), with username `mernk8s` and password `mernk8s` as we set previously.

![MongoDB Compass connected to our mern-k8s database](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/compass_entries_c4a8cb98ef.jpg)

### Delete project

Let’s finish off by using `kubectl` to delete the Atlas cluster and project and clean up our workspace. We can delete everything from the current namespace by using `kubectl delete`

 
```
kubectl delete atlasdeployment mern-k8s-cluster
kubectl delete atlasproject mern-k8s-project
```


## Summary

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](https://docs.atlas.mongodb.com/atlas-operator/) to learn more.

If you are using MongoDB Enterprise instead of Atlas, there is also an [Operator](https://www.mongodb.com/try/download/enterprise-kubernetes-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](https://joellord.github.io/mern-k8s/).

Get started with application deployment into a Kubernetes cluster using the MongoDB Atlas Operator.

How to Deploy an Application in Kubernetes With the MongoDB Atlas Operator

Rachelle Palmer

Product Lead, Developer Experience

Looking for a code example that has microservices in Go with Docker, Kubernetes and MongoDB? Look no further!

Cinema is an example project which demonstrates the use of microservices for a fictional movie theater. The Cinema backend is powered by 4 microservices, all of which happen to be written in Go, using MongoDB for manage the database and Docker to isolate and deploy the ecosystem.

Movie Service: Provides information like movie ratings, title, etc.
Show Times Service: Provides show times information.
Booking Service: Provides booking information.
Users Service: Provides movie suggestions for users by communicating with other services.

This project is available to clone or fork on [github](https://github.com/mmorejon/microservices-docker-go-mongodb) from [Manuel Morejón](https://twitter.com/morejon85). 


Looking for a code example that has microservices in Go with Docker, Kubernetes, and MongoDB? Look no further!

Cinema: Example Go Microservices Application

Pavel Duchovny

Lead Developer Advocate

## Introduction

Containerized applications are becoming an industry standard for virtualization. When we talk about managing those containers, [Kubernetes](https://kubernetes.io/) will probably be brought up extremely quickly.

Kubernetes is a known open-source system for automating the deployment, scaling, and management of containerized applications. Nowadays, all of the major cloud providers (AWS, Google Cloud, and Azure) have a managed Kubernetes offering to easily allow organizations to get started and scale their Kubernetes environments.

Not surprisingly, MongoDB Atlas also runs on all of those offerings to give your modern containerized applications the best database offering. However, ease of development might yield in missing some critical aspects, such as security and connectivity control to our cloud services.

In this article, I will guide you on how to properly secure your Kubernetes cloud services when connecting to MongoDB Atlas using the recommended and robust solutions we have.

## Prerequisites

You will need to have a cloud provider account and the ability to deploy one of the Kubernetes offerings:

* [Amazon EKS](https://aws.amazon.com/eks/)
* [Google Cloud GKE](https://cloud.google.com/kubernetes-engine)
* [Azure AKS](https://azure.microsoft.com/en-us/services/kubernetes-service)

And of course, you'll need a MongoDB Atlas project where you are a project owner.

> If you haven't yet set up your free cluster on [MongoDB Atlas](http://bit.ly/mongodbatlas), now is a great time to do so. You have all the instructions in this [blog post](https://www.mongodb.com/developer/products/atlas/free-atlas-cluster/). Please note that for this tutorial you are required to have a M10+ cluster.

## Step 1: Set Up Networks

Atlas connections, by default, use credentials and end-to-end encryption to secure the connection. However, building a trusted network is a must for closing the security cycle between your application and the database.

No matter what cloud of choice you decide to build your Kubernetes cluster in, the basic foundation of securing that deployment is creating its own network. You can look into the following guides to create your own network and gather the main information (Names, Ids, and subnet [Classless Inter-Domain Routing](https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing) \- CIDR\)\.

##### Private Network Creation

| AWS | GCP | Azure |
| --- | --- | ----- |
| [Create an AWS VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-getting-started.html#getting-started-create-vpc) | [Create a GCP VPC](https://cloud.google.com/vpc/docs/using-vpc) | [Create a VNET](https://docs.microsoft.com/en-us/azure/virtual-network/quick-create-portal) |

## Step 2: Create Network Peerings

Now, we'll configure connectivity of the virtual network that the Atlas region resides in to the virtual network we've created in Step 1. This connectivity is required to make sure the communication between networks is possible. We'll configure Atlas to allow connections from the virtual network from Step 1.

This process is called setting a Network Peering Connection. It's significant as it allows internal communication between networks of two different accounts (the Atlas cloud account and your cloud account).
<figure align="center"><img style="border-radius: 10px; width: 800px" src="https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/Atlas_peering_page_3e33f7d799.png" alt="Atlas peering page"></figure>The network peerings are established under our Projects > Network Access > Peering > "ADD PEERING CONNECTION." For more information, please read our [documentation](https://docs.atlas.mongodb.com/security-vpc-peering/).

However, I will highlight the main points in each cloud for a successful peering setup:

##### Private Network Creation
<div style="overflow-x:auto;">
<table style="
        border: 1px solid #B8C4C2;
        border-collapse: collapse;
        margin: 16px 0;
        table-layout: fixed;
"><thead style="border: inherit" valign="bottom"><tr style="border: inherit"><th style="width: 250px; border: inherit; padding: 10px">AWS</th><th style="width: 250px; border: inherit; padding: 10px">GCP</th><th style="width: 250px; border: inherit; padding: 10px">Azure</th></tr></thead><tbody style="border: inherit" valign="top"><tr style="border: inherit"><td style="border: inherit; padding: 10px"><ol><li>Allow outbound traffic to Atlas CIDR on 2015-27017.</li><li>Obtain VPC information (<code>Account ID</code>, <code>VPC Name</code>, <code>VPC Region</code>, VPC CIDR). Enable DNS and Hostname resolution on that VPC.</li><li>Using this information, initiate the VPC Peering.</li><li>Approve the peering on AWS side.</li><li>Add peering route in the relevant subnet/s targeting Atlas CIDR and add those subnets/security groups in the Atlas access list page.</li></ol></td><td style="border: inherit; padding: 10px"><ol><li>Obtain GCP VPC information (<code>Project ID</code>, <code>VPC Name</code>, <code>VPC Region</code>, and CIDR).</li><li>When you initiate a VPC peering on Atlas side, it will generate information you need to input on GCP VPC network peering page (<code>Atlas Project ID</code> and <code>Atlas VPC Name</code>).</li><li>Submit the peering request approval on GCP and add the GCP CIDR in Atlas access lists.</li></ol></td><td style="border: inherit; padding: 10px"><ol><li>Obtain the following azure details from your subscription (<code>Subscription ID</code>, Azure Active Directory <code>Directory ID</code>, VNET <code>Resource Group Name</code>, <code>VNet Name</code>, <code>VNet Region</code>).</li><li>Input the gathered information and get a list of commands to perform on Azure console.</li><li>Open Azure console and run the commands, which will create a custom role and permissions for peering.</li><li>Validate and initiate peering.</li></ol></td></tr></tbody></table>
</div>

## Step 3: Deploy the Kubernetes Cluster in Our Networks

The Kubernetes clusters that we launch must be associated with the
peered network. I will highlight each cloud provider's specifics.

## AWS EKS

When we launch our EKS via the AWS console service, we need to configure
the peered VPC under the "Networking" tab.

Place the correct settings:

* VPC Name
* Relevant Subnets (Recommended to pick at least three availability
zones)
* Choose a security group with open 27015-27017 ports to the Atlas
CIDR.
* Optionally, you can add an IP range for your pods.

![In this case, I placed my peered VPC name, chose three availability zones from my EU West region, and specified a security group allowing 27015 - 27017 access to Atlas CIDR.](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/AWS_Netoworking_Kube_ed6404dca2.png)

## GCP GKE

When we launch our GKE service, we need to configure the peered VPC under the "Networking" section.

Place the correct settings:

* VPC Name
* Subnet Name
* Optionally, you can add an IP range for your pod's internal network that cannot overlap with the peered CIDR.

![In this case, once I got to the network tab, I placed my Network name ](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/GCP_Kube_Clusterr_Network_6037204a1a.png)

## Azure AKS

When we lunch our AKS service, we need to use the same resource group as the peered VNET and configure the peered VNET as the [CNI network](https://docs.microsoft.com/en-us/azure/aks/configure-azure-cni) in the advanced Networking tab.

Place the correct settings:

* Resource Group
* VNET Name under "Virtual Network"
* Cluster Subnet should be the peered subnet range.
* The other CIDR should be a non-overlapping CIDR from the peered network.

![In this case, I checked the box ](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/Networking_AKS_Azure_5c9cc20768.png)

## Step 4: Deploy Containers and Test Connectivity

Once the cluster is up and running in your cloud provider, you can test the connectivity to our peered cluster.

First, we will need to get our connection string and method from the Atlas cluster UI. Please note that GCP and Azure have private connection strings for peering, and those must be used for peered networks.

![Connect to Peering Test: step 1](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/Private_Conn_String_d42ecbe933.png)

![Connect to Peering Test: step 2](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/Shell_Template_e101dd97bf.png)

Now, let's test our connection from one of the Kubernetes pods:
<figure align="center"><img style="border-radius: 10px; width: 800px" src="https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/Success_Shell_Private_3303fc8d3d.png" alt="Successful Shell Test"></figure>That's it. We are securely connected!

## Wrap-Up

Kubernetes-managed clusters offer a simple and modern way to deploy containerized applications to the vendor of your choice. It's great that we can easily secure their connections to work with the best cloud database offering there is, MongoDB Atlas, unlocking other possibilities to build incredible applications.

> If you have questions, please head to our [developer community website](https://community.mongodb.com/) where the MongoDB engineers and the MongoDB community will help you build your next big idea with MongoDB.

A high-level guide on how to securely connect MongoDB Atlas with the Kubernetes offerings from Amazon AWS, Google Cloud (GCP), and Microsoft Azure.

Securely Connect MongoDB to Cloud-Offered Kubernetes Clusters

Kubernetes, a container orchestration tool, enables developers to automate the deployment, scaling, and management of their containerized applications. Kubernetes is popular among developers for its security benefits and the fact that it comes in many different flavors, including AWS' EKS, Microsoft Azure's AKS, and Google Cloud’s GKE. MongoDB Atlas enables developers to seamlessly integrate Atlas into their current Kubernetes deployment pipeline through our MongoDB Atlas Kubernetes Operator. 

The Atlas Kubernetes Operator enables customers using Kubernetes to create and manage Atlas resources in one of the supported public clouds with exactly the same tools and processes that they use for their existing services in Kubernetes. The operator works by extending the Kubernetes API to support custom resources, enabling developers to manage MongoDB resources as native Kubernetes objects, even though Atlas is running outside of the cluster. Developers can create and apply custom resources into Kubernetes to define Atlas configuration, and the Atlas Kubernetes Operator automates the application of that configuration via the Atlas Admin API. 

There are many ways to get started with the Atlas Kubernetes Operator, such as [via the Atlas CLI](https://www.mongodb.com/docs/atlas/cli/current/command/atlas-kubernetes-operator-install/) or through a [Helm Chart](https://www.mongodb.com/docs/atlas/operator/current/ak8so-quick-start-helm/#std-label-ak8so-quick-start-helm-ref). This tutorial will walk you through how to get started using the MongoDB Atlas Kubernetes Operator [Quick Start](https://www.mongodb.com/docs/atlas/operator/current/ak8so-quick-start/). Let’s get started!  

## Pre-requisites
- A MongoDB [Atlas account](https://www.mongodb.com/cloud/atlas/register)
- A running Kubernetes cluster with nodes running processors with the x86-64, AMD64, or ARM64 architecture — you can use some like Minikube to test with
- [Kubectl](https://kubernetes.io/docs/tasks/tools/) and [jq](https://jqlang.github.io/jq/download/) (version 1.6 or higher) installed 

## 1. Set up your Organization ID and API keys
First, you will need to install the operator into a running Kubernetes cluster. Make sure that it’s running processors with the x86-64, AMD64, or ARM64 architecture. In this example, we are running a Kubernetes cluster using [Minikube](https://minikube.sigs.k8s.io/docs/start/?arch=%2Fmacos%2Farm64%2Fstable%2Fbinary+download) and Docker, and using Kubectl to apply commands.
 
If you don’t already have an Atlas account, you can [sign up for one](https://account.mongodb.com/account/register?_ga=2.256169867.1898390183.1720909380-1592895210.1668436484&_gac=1.180422485.1719957183.CjwKCAjwyo60BhBiEiwAHmVLJURlqXVVADnlIGLoEkPSRGZe51Zz6AiMfc2vm8WSHqM3lLHpcPI1phoCuLkQAvD_BwE).

Once you have logged into your Atlas account, you will first create API keys for use by the operator. 

In the top left-hand corner, click on the “Access Manager” drop-down and the API keys tab. Click on “Create API Key.” 

![Atlas Organization Access Manager Page][1]

>Note: If you want the Atlas Kubernetes Operator to create a new Atlas project to work in, you will need to create and use the API keys for [an organization](https://www.mongodb.com/docs/atlas/configure-api-access/#std-label-create-org-api-key). For an existing project, you will need to create them for [a project](https://www.mongodb.com/docs/atlas/configure-api-access/#std-label-create-project-api-key). For this example, we’ll be creating a new Atlas project. For either type of project, it is best practice to configure an [API access list](https://www.mongodb.com/docs/atlas/configure-api-access-project/#std-label-edit-project-api-key-access-list).

Here, you will input a name for your API keys (for example, AKO/Vector Search Keys) and select the organization role. You must assign the API key the Organization Project Creator organization role or higher.

![Atlas UI “Create API Keys” page][2]

From there, you will find a set of unique API keys generated for you. Be sure to save these somewhere secure. Once you leave this page, you will not be able to recover them!

## 2. Install the MongoDB Atlas Kubernetes Operator
Next, we will install/deploy the operator into the Kubernetes cluster you have running. 
Once deployed, the Atlas Kubernetes Operator can monitor resources and events across a single or multiple Kubernetes namespaces. This capability allows the operator to manage MongoDB Atlas custom resources comprehensively across the entire Kubernetes cluster or specific designated namespaces.

For this example, we’ll set up the operator to watch all namespaces in our cluster, but you can learn how to set up the operator to watch a single namespace in our documentation. 

Use the following command in your terminal: 

```bash
kubectl apply -f https://raw.githubusercontent.com/mongodb/mongodb-atlas-kubernetes/v2.3.1/deploy/all-in-one.yaml
```
Make sure to replace the `<version>` with the latest update in the following format: “v2.x.x”.

## 3. Create a secret with your API keys and Organization ID
Next, we’ll create a secret in Kubernetes. A Kubernetes secret is an object used to store and manage sensitive information, such as passwords, OAuth tokens, and SSH keys, securely within a Kubernetes cluster. In this case, it will be the API keys you created earlier. 

If you use external secret storage, you don't need to put sensitive information directly into Kubernetes [secrets](https://kubernetes.io/docs/concepts/configuration/secret/). To learn more, see [Configure Secret Storage](https://www.mongodb.com/docs/atlas/operator/current/ak8so-secret-storage/#std-label-ak8so-secret-storage).

Input the following command and replace `<atlas_organization_id>` with your organization ID, `<atlas_api_public_key>` with your public API key, and `<atlas_api_private_key>` with your private key. 

>Troubleshooting: If the following command produces an error, try to run the command without quotes (eg. `--from-literal=orgId=<atlas_organization_id> \`)

```bash
kubectl create secret generic mongodb-atlas-operator-api-key \
    --from-literal="orgId=<atlas_organization_id>" \
    --from-literal="publicApiKey=<atlas_api_public_key>" \
    --from-literal="privateApiKey=<atlas_api_private_key>" \
    -n mongodb-atlas-system
```

Next, use the following command to label your secret:
```bash
kubectl label secret mongodb-atlas-operator-api-key atlas.mongodb.com/type=credentials -n mongodb-atlas-system
```

## 4. Create an Atlas project custom resource
Projects allow you to isolate different database environments (for instance, development/qa/prod environments) from each other, as well as users/teams. Here, we’ll use the operator to create a project in the Atlas UI through an Atlas project custom resource.

Input the following command in your terminal. 

```bash
cat <<EOF | kubectl apply -f -
apiVersion: atlas.mongodb.com/v1
kind: AtlasProject
metadata:
  name: my-project
spec:
  name: Test Atlas Operator Project
  projectIpAccessList:
    - cidrBlock: "0.0.0.0/0"
      comment: "Allowing access to database from everywhere (only for Demo!)"
EOF
```
>Note: The above commands will add the CIDR 0.0.0.0/0 to your IP access list if input as is. This CIDR allows any client to connect to the Atlas cluster. Do not use this IP address in production. 

If you are working off an existing project in Atlas, be sure to change `name: my-project` to the name of your project in Atlas, and update the `cidrBlock` to your current IP address.

After entering this command, check your Atlas UI. You should see a project created in the Atlas UI called “Test Atlas Operator Project.” 

![Atlas UI “Projects” Page][3]

## 5. Create an Atlas deployment
Deployments are instances of MongoDB running on a cloud provider. This custom resource will create a free tier M0 cluster, but you can always adjust the size of your cluster depending on your workload needs in the custom resource. In your terminal, enter this command: 

```bash
cat <<EOF | kubectl apply -f -
apiVersion: atlas.mongodb.com/v1
kind: AtlasDeployment
metadata:
  name: my-test-cluster
spec:
  projectRef:
    name: my-project
  deploymentSpec:
    clusterType: REPLICASET
    name: test-atlas-operator-project
    replicationSpecs:
       - regionConfigs:
         - regionName: US_EAST_1
           providerName: TENANT
           backingProviderName: AWS
           electableSpecs:
              instanceSize: M0
              nodeCount: 3
EOF
```

Now, within Projects in the Atlas UI, you should see “1 Cluster” created under the Clusters column.

![Atlas UI “Projects” Page][4]

Next, you’ll want to create a secret for your password.

Input the following command. Make sure to replace `P@@ssword%` with a password of your choice. 

```bash
kubectl create secret generic the-user-password --from-literal="password=P@@sword%"
```

Next, use the following command to label your password.

```bash
kubectl label secret the-user-password atlas.mongodb.com/type=credentials
```

With the cluster configured, we’ll create a AtlasDatabaseUser custom resource using the following command. Make sure to replace the password you defined before in the code line that says `the-user-password`. 

```bash
cat <<EOF | kubectl apply -f -
apiVersion: atlas.mongodb.com/v1
kind: AtlasDatabaseUser
metadata:
  name: my-database-user
spec:
  roles:
    - roleName: "readWriteAnyDatabase"
      databaseName: "admin"
  projectRef:
    name: my-project
  username: theuser
  passwordSecretRef:
    name: the-user-password
EOF
```

You will need to keep running the following command until you get a `True` response. This may take some time and you may need to run it multiple times before you get the correct response. 

```bash
kubectl get atlasdatabaseusers my-database-user -o=jsonpath='{.status.conditions[?(@.type=="Ready")].status}'
```

## 6. Retrieve secret and create connection string
Finally, you’ll need to retrieve the secret that the operator created. Getting your connection string to the newly created database can also be done through Kubernetes. For this step, you will need to have [jq](https://jqlang.github.io/jq/download/) (version 1.6 or higher) installed. 

Input the following command after you’ve replaced the following parts of the code with what is in the metadata from the custom resources you applied before:

- `my-project`: Specify the value of the metadata field of your AtlasProject Custom Resource (in this example, `my-project`).
- `my-atlas-cluster`: Specify the value of the metadata field of your AtlasDeployment Custom Resource (in this example, `my-test-cluster`).
- `my-database-user`: Specify the value of the metadata field of your AtlasDatabaseUser Custom Resource (in this example, `my-database-user`)
 
```bash
kubectl get secret {my-project}-{my-atlas-cluster}-{my-database-user} -o json | jq -r '.data | with_entries(.value |= @base64d)';
```

Next, run this command to obtain a connection string. Make sure to input the password and username you had before next to the fields where you see `“password”` and `“username”`.

```bash
{
   "connectionStringStandard": "mongodb://theuser:P%40%40sword%25@test-cluster-shard-00-00.peqtm.mongodb.net:27017,test-cluster-shard-00-01.peqtm.mongodb.net:27017,test-cluster-shard-00-02.peqtm.mongodb.net:27017/?ssl=true&authSource=admin&replicaSet=atlas-pk82fl-shard-0",
   "connectionStringStandardSrv": "mongodb+srv://theuser:P%40%40sword%25@test-cluster.peqtm.mongodb.net",
   "password": "P@@sword%",
   "username": "theuser"
 }
```

Your connection strings will look different from the connection string in this example. 

Finally, you can consume the secret as an environment variable with your application:. 

```bash
containers:
 - name: test-app
   env:
    - name: "CONNECTION_STRING"
      valueFrom:
        secretKeyRef:
          name: test-atlas-operator-project-test-cluster-theuser
          key: connectionStringStandardSrv
```

With that, you have successfully leveraged the Atlas Operator to create and connect to a new Atlas cluster, via Kubernetes! 

To learn more about the Atlas Kubernetes Operator, you can go to the [Atlas Operator documentation](https://www.mongodb.com/docs/atlas/atlas-operator/?_ga=2.142396786.1582366874.1719839208-1592895210.1668436484&_gac=1.54601049.1719957183.CjwKCAjwyo60BhBiEiwAHmVLJURlqXVVADnlIGLoEkPSRGZe51Zz6AiMfc2vm8WSHqM3lLHpcPI1phoCuLkQAvD_BwE). If you are using MongoDB Enterprise Advanced instead of Atlas, we have the [Enterprise Kubernetes Operator](https://www.mongodb.com/try/download/enterprise-kubernetes-operator) available for running MongoDB within your own Kubernetes environment.

If you have questions or want to share your work, head to the [MongoDB Developer Community](https://www.mongodb.com/community/forums/)!


  [1]: https://images.contentstack.io/v3/assets/blt39790b633ee0d5a7/blt98e746cefdf2bd44/66a8bfd4d14106d14c555d3c/image3.png
  [2]: https://images.contentstack.io/v3/assets/blt39790b633ee0d5a7/blt1366d0b416b07a38/66a8bfd5c10344eae6067631/image2.png
  [3]: https://images.contentstack.io/v3/assets/blt39790b633ee0d5a7/blt328055b7b3bd4feb/66a8bfd5d141068402555d40/image4.png
  [4]: https://images.contentstack.io/v3/assets/blt39790b633ee0d5a7/bltc747a9108c60c28f/66a8bfd4adec839e912d0c84/image1.png

Learn how to deploy MongoDB Atlas with the Atlas Kubernetes Operator

How to Deploy MongoDB Atlas With the Atlas Kubernetes Operator

## Introduction
In the early days of software development, application development consisted of monolithic codebases. With challenges in scaling, singular points of failure, and inefficiencies in updating, a solution was proposed. A modular approach. A symphony of applications managing their respective domains in harmony. This is achieved using microservices.

Microservices are an architectural approach that promotes the division of applications into smaller, loosely coupled services. This allows application code to be delivered in manageable pieces, independent of each other. These services operate independently, addressing a lot of the concerns of monolithic applications mentioned above.

While each application has its own needs, microservices have proven themselves as a viable solution time and time again, as you can see in the success of the likes of Netflix.

In this tutorial, we are going to deploy a simple Java Spring Boot microservice application, hosted on the [Azure Kubernetes Service (AKS)](https://learn.microsoft.com/en-us/azure/aks/intro-kubernetes). AKS simplifies deploying a managed Kubernetes cluster in Azure by offloading the operational overhead to Azure. We'll explore containerizing our application and setting up communication between our APIs, a MongoDB database, and the external world. You can access the full code here:

```bash
git clone https://github.com/mongodb-developer/simple-movie-microservice.git
```

Though we won't dive into the most advanced microservice best practices and design patterns, this application gives a simplistic approach that will allow you to write reviews for the movies in the MongoDB sample data, by first communicating with the review API and that service, verifying that the user and the movie both exist. The architecture will look like this.

![The architecture diagram for the microservice application.][1]

Simple, right? Exactly! And AKS makes it even easier to communicate with other APIs managed on the service. In a microservices architecture, services need to discover each other dynamically. Kubernetes itself acts as a service registry, where each service in the cluster has a unique name. So when we communicate with our other services in [ReviewController.java](https://github.com/mongodb-developer/simple-movie-microservice/blob/main/reviews/src/main/java/com/example/reviews/controller/ReviewController.java), we simply send a request to `http://user-management-service/users/`. In this demo application, communication is done with RESTful HTTP/S requests, using [RestTemplate](https://www.baeldung.com/rest-template). 

## Prerequisites
Before you begin, you'll need a few prerequisites to follow along with this tutorial, including:
- A [MongoDB Atlas](https://www.mongodb.com/cloud/atlas) account, if you don't have one already, with a cluster ready with the [MongoDB sample data](https://www.mongodb.com/basics/sample-database).
- A [Microsoft Azure account](https://azure.microsoft.com/en-us/free) with an active subscription.
- [Azure CLI](https://learn.microsoft.com/en-us/cli/azure/), or you can [install Azure PowerShell](https://learn.microsoft.com/en-us/powershell/azure/), but this tutorial uses Azure CLI. Sign in and configure your command line tool following the steps in the documentation for [Azure CLI](https://learn.microsoft.com/en-us/cli/azure/azure-cli-configuration) and [Azure PowerShell](https://learn.microsoft.com/en-us/powershell/azure/configure-global-settings).
- [Docker](https://www.docker.com/get-started/) for creating container images of our microservices.
- Java 17.
- Maven 3.9.6.

## Set up an Azure Kubernetes Service cluster
Starting from the very beginning, set up an Azure Kubernetes Service (AKS) cluster.

### Install kubectl and create an AKS cluster
Install `kubectl`, the Kubernetes command-line tool, via the Azure CLI with the following command (you might need to sudo this command), or you can download the binaries from:
```bash
az aks install-cli
```

Log into your Azure account using the Azure CLI:
```bash
az login
```

Create an Azure Resource Group:
```bash
az group create --name myResourceGroup --location northeurope
```

Create an AKS cluster: Replace `myAKSCluster` with your desired cluster name. (This can take a couple of minutes.)
```bash
az aks create --resource-group myResourceGroup --name myAKSCluster --node-count 2 --enable-addons monitoring --generate-ssh-keys
```

### Configure kubectl to use your AKS cluster
After successfully creating your AKS cluster, you can proceed to configure `kubectl` to use your new AKS cluster. Retrieve the credentials for your AKS cluster and configure `kubectl`:
```bash
az aks get-credentials --resource-group myResourceGroup --name myAKSCluster
```

### Create an Azure Container Registry (ACR)
Create an ACR to store and manage container images across all types of Azure deployments:
```bash
az acr create --resource-group <your-resource-group> --name <your-container-registry> --sku Basic
```
> Note: Save the app service id here. We’ll need it later when we are creating a service principal.

Log into ACR:
```bash
az acr login --name <your-container-registry>
```
## Containerize your microservices application
Each of your applications (User Management, Movie Catalogue, Reviews) has a `Dockerfile`. Create a .jar by running the command `mvn package` for each application, in the location of the pom.xml file. Depending on your platform, the following steps are slightly different.

For those wielding an M1 Mac, a bit of tweaking is in order due to our image's architecture. As it stands, Azure Container Apps can only jive with linux/amd64 container images. However, the M1 Mac creates images as `arm` by default. To navigate this hiccup, we'll be leveraging Buildx, a handy Docker plugin. Buildx allows us to build and push images tailored for a variety of platforms and architectures, ensuring our images align with Azure's requirements.

### Build the Docker image (not M1 Mac)
To build your image, make sure you run the following command in the same location as the `Dockerfile`. Repeat for each application.
```bash
docker build -t movie-catalogue-service .
```
**Or** you can run the following command from the simple-movie-microservice folder to loop through all three repositories.

```bash
for i in movie-catalogue reviews user-management; do cd $i; ./mvnw clean package; docker build -t $i-service .; cd -; done
```
### Build the Docker image (M1 Mac)
If you are using an M1 Mac, use the following commands to use Buildx to create your images:
```bash
docker buildx install
```

Next, enable Buildx to use the Docker CLI:
```bash
docker buildx create --use
```

Open a terminal and navigate to the root directory of the microservice where the `Dockerfile` is located. Run the following command to build the Docker image, replacing `movie-catalogue-service` with the appropriate name for each service.
```bash
docker buildx build --platform linux/amd64 -t movie-catalogue-service:latest --output type=docker .
```

### Tag and push
Now, we're ready to tag and push your images. Replace `<your-acr-name>` with your actual ACR name. Repeat these two commands for each microservice. 
```bash
docker tag movie-catalogue-service <your-acr-name>.azurecr.io/movie-catalogue-service:latest
docker push <your-acr-name>.azurecr.io/movie-catalogue-service:latest
```
**Or** run this script in the terminal, like before:

```bash
ACR_NAME="<your-acr-name>.azurecr.io"

for i in movie-catalogue reviews user-management; do 
    # Tag the Docker image for Azure Container Registry
    docker tag $i-service $ACR_NAME/$i-service:latest
    # Push the Docker image to Azure Container Registry
    docker push $ACR_NAME/$i-service:latest
done
```

## Deploy your microservices to AKS
Now that we have our images ready, we need to create Kubernetes deployment and service YAML files for each microservice. We are going to create one *mono-file* to create the Kubernetes objects for our deployment and services. We also need one to store our MongoDB details. It is good practice to use secrets for sensitive data like the MongoDB URI.

### Create a Kubernetes secret for MongoDB URI
First, you'll need to create a secret to securely pass the MongoDB connection string to your microservices. In Kubernetes, the data within a secret object is stored as [base64-encoded](https://en.wikipedia.org/wiki/Base64) strings. This encoding is used because it allows you to store binary data in a format that can be safely represented and transmitted as plain text. It's not a form of encryption or meant to secure the data, but it ensures compatibility with systems that may not handle raw binary data well.

Create a Kubernetes secret that contains the MongoDB URI and database name. You will encode these values in Base64 format, but Kubernetes will handle them as plain text when injecting them into your [pods](https://kubernetes.io/docs/concepts/workloads/pods/). You can encode them with the bash command, and copy them into the YAML file, next to the appropriate data keys:

```bash
echo -n 'your-mongodb-uri' | base64
echo -n 'your-database-name' | base64
```

This is the [mongodb-secret.yaml](https://github.com/mongodb-developer/simple-movie-microservice/blob/main/mongodb-secret.yaml).
```yaml
apiVersion: v1
kind: Secret
metadata:
  name: mongodb-secret
type: Opaque
data:
  MONGODB_URI: <Base64 encoded MongoDB URI>
  MONGODB_DATABASE: <Base64 encoded MongoDB database name>

```

Run the following command to apply your secrets:
```bash
kubectl apply -f mongodb-secret.yaml
```

So, while base64 encoding doesn't secure the data, it formats it in a way that's safe to store in the Kubernetes API and easy to consume from your applications running in pods.

### Authorize access to the ACR
If your ACR is private, you'll need to ensure that your Kubernetes cluster has the necessary credentials to access it. You can achieve this by creating a Kubernetes secret with your registry credentials and then using that secret in your deployments. 

The next step is to create a service principal or use an existing one that has access to your ACR. This service principal needs the `AcrPull` role assigned to be able to pull images from the ACR. Replace  `<your-service-principal-name>`, `<your-subscription-id>`, `<your-resource-group-name>`, and `<your-acr-name>` with your own values.
<your-service-principal-name>: This can be any unique identifier you want to give this service principal.
<your-subscription-id>: You can get the id for the subscription you’re using with `az account show --query id --output tsv`.
<your-resource-group-name>: Use the same resource group you have your AKS set up in.
<your-acr-name>: This is the Azure Container Registry you have your images stored in.

```bash
az ad sp create-for-rbac --name <your-service-principal-name> --role acrPull --scopes /subscriptions/<your-subscription-id>/resourceGroups/<your-resource-group-name>/providers/Microsoft.ContainerRegistry/registries/<your-acr-name>
```

This command will output JSON that looks something like this:
```bash
{   
	"appId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",   
	"displayName": "<your-service-principal-name>",   
	"password": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx",   
	"tenant": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" 
}
```

- `appId` is your `<your-service-principal-app-id>`.
- `password` is your `<your-service-principal-password>`.

**Note:** It's important to note that the `password` is only displayed once at the creation time. Make sure to copy and secure it.

**Create a Kubernetes secret with the service principal's credentials.** You can do this with the following command:

```bash
kubectl create secret docker-registry acr-auth \
  --namespace default \
  --docker-server=<your-acr-name>.azurecr.io \
  --docker-username=<your-service-principal-app-id> \
  --docker-password=<your-service-principal-password> \
  --docker-email=<your-email>
```

### Create Kubernetes deployment and service YAML files
There are a couple of points to note in the [YAML file](https://github.com/mongodb-developer/simple-movie-microservice/blob/main/all-microservices.yaml) for this tutorial, but these points are not exhaustive of everything happening in this file. If you want to learn more about configuring your YAML for Kubernetes, check out the documentation for [configuring Kubernetes objects](https://kubernetes.io/docs/concepts/overview/working-with-objects/).
- We will have our APIs exposed externally. This means you will be able to access the endpoints from the addresses we'll receive when we have everything running. Setting the `type: LoadBalancer` triggers the cloud provider's load balancer to be provisioned automatically. The external load balancer will be configured to route traffic to the Kubernetes service, which in turn routes traffic to the appropriate pods based on the service's selector.
- The `containers:` section defines a single container named `movie-catalogue-service`, using an image specified by `<your-container-registry>/movie-catalogue-service:latest`.
- `containerPort: 8080` exposes port 8080 inside the container for network communication.
- Environment variables `MONGODB_URI` and `MONGODB_DATABASE` are set using values from secrets (`mongodb-secret`), enhancing security by not hardcoding sensitive information.
- `imagePullSecrets: - name: acr-auth` allows Kubernetes to authenticate to a private container registry to pull the specified image, using the secret we just created.

```yaml
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: movie-catalogue-service-deployment
spec:
  replicas: 1
  selector:
    matchLabels:
      app: movie-catalogue-service
  template:
    metadata:
      labels:
        app: movie-catalogue-service
    spec:
      containers:
      - name: movie-catalogue-service
        image: <your-container-registry>/movie-catalogue-service:latest
        ports:
        - containerPort: 8080
        env:
        - name: MONGODB_URI
          valueFrom:
            secretKeyRef:
              name: mongodb-secret
              key: MONGODB_URI
        - name: MONGODB_DATABASE
          valueFrom:
            secretKeyRef:
              name: mongodb-secret
              key: MONGODB_DATABASE
      imagePullSecrets:
      - name: acr-auth
---
apiVersion: v1
kind: Service
metadata:
  name: movie-catalogue-service
spec:
  selector:
    app: movie-catalogue-service
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080
  type: LoadBalancer
---
```

Remember, before applying your Kubernetes YAML files, make sure your Kubernetes cluster has access to your ACR. You can configure this by granting AKS the ACRPull role on your ACR:

```bash
az aks update -n <your-AKS-Cluster> -g <your-resource-group> --attach-acr <your-ACR>
```

Replace `<your-AKS-Cluster>`, `<your-resource-group>`, and `<your-ACR>` with your AKS cluster name, Azure resource group name, and ACR name, respectively.

### Apply the YAML file
Apply the YAML file with `kubectl`:
```bash
kubectl apply -f all-microservices.yaml
```
## Access your services
Once deployed, it may take a few minutes for the LoadBalancer to be provisioned and for the external IP addresses to be assigned. You can check the status of your services with:
```bash 
kubectl get services
```

Look for the external IP addresses for your services and use them to access your microservices.

After deploying, ensure your services are running:
```bash
kubectl get pods
```
Access your services based on the type of Kubernetes service you've defined (e.g., LoadBalancer in our case) and perform your tests.

You can test if the endpoint is running with the CURL command:
```bash
curl -X POST http://<ReviewAPI-External-IP>/reviews \
     -H "Content-Type: application/json" \
     -d '{"movieId": "573a1391f29313caabcd68d0", "userId": "59b99db5cfa9a34dcd7885b8", "rating": 4}'
```

And this review should now appear in your database. You can check with a simple:
```bash
curl -X GET http://<ReviewAPI-External-IP>/reviews
```

Hooray!

## Conclusion
As we wrap up this tutorial, it's clear that embracing microservices architecture, especially when paired with the power of Kubernetes and Azure Kubernetes Service (AKS), can significantly enhance the scalability, maintainability, and deployment flexibility of applications. Through the practical deployment of a simple microservice application using Java Spring Boot on AKS, we've demonstrated the steps and considerations involved in bringing a microservice architecture to life in the cloud.

Key takeaways:
- **Modular approach**: The transition from monolithic to microservices architecture facilitates a modular approach to application development, enabling independent development, deployment, and scaling of services.
- **Simplified Kubernetes deployment**: AKS abstracts away much of the complexity involved in managing a Kubernetes cluster, offering a streamlined path to deploying microservices at scale.
- **Inter-service communication**: Utilizing Kubernetes' internal DNS for service discovery simplifies the communication between services within a cluster, making microservice interactions more efficient and reliable.
- **Security and configuration best practices**: The tutorial underscored the importance of using Kubernetes secrets for sensitive configurations and the Azure Container Registry for securely managing and deploying container images.
- **Exposing services externally**: By setting services to `type: LoadBalancer`, we've seen how to expose microservices externally, allowing for easy access and integration with other applications and services.

The simplicity and robustness of Kubernetes, combined with the scalability of AKS and the modularity of microservices, equip developers with the tools necessary to build complex applications that are both resilient and adaptable. If you found this tutorial useful, find out more about what you can do with MongoDB and Azure on our [Developer Center](https://www.mongodb.com/developer/technologies/azure/).

Are you ready to start building with Atlas on Azure? Get started for free today with [MongoDB Atlas on Azure Marketplace](https://azuremarketplace.microsoft.com/en-us/marketplace/apps/mongodb.mongodb_atlas_self_serve_prod_2022).


  [1]: https://images.contentstack.io/v3/assets/blt39790b633ee0d5a7/blt7bcbee53fc14653b/661808089070f0c0a8d50771/AKS_microservices.png

Learn how to deploy your Java Spring Boot microservice to Azure Kubernetes Services.

Using Azure Kubernetes Services for Java Spring Boot Microservices

Champion

Arek Borucki

Principal SRE Database Engineer

Learn how to deploy MongoDB across multiple Kubernetes clusters using the operator and the MongoDBMulti CRD.

Deploying the MongoDB Enterprise Kubernetes Operator on Google Cloud

Mastering MongoDB Ops Manager on Kubernetes

Deploying MongoDB Across Multiple Kubernetes Clusters With MongoDBMulti

Deploying MongoDB Across Multiple Kubernetes Clusters

Michael Lynn

Principal Developer Advocate

Join Michael Lynn and Nic Raboy as they chat with Gaspard Petit of Square Enix to learn how one of the largest and best-loved gaming brands in the world is using MongoDB to scale and grow.

Scaling the Gaming Industry with Gaspard Petit of Square Enix

Robert Walters

Senior Product Manager

Introducing a Kubernetes Operator (beta) that integrates with Ops Manager, the enterprise management platform for MongoDB.

Introducing the MongoDB Enterprise Operator for Kubernetes and OpenShift

Partner

Eric Betts

Staff Backend Engineer

Jen Kagan

Backend Engineer

We recently needed to backfill nearly two million documents in our MongoDB database with a new attribute and wanted to share our process. First, some context on why we were doing this: This backfill was to support Netlify's Growth team, which builds prototypes into Netlify's core product and then evaluates how those prototypes impact user conversion and retention rates. 

If we find that a prototype positively impacts growth, we use that finding to shape deeper investments in a particular area of the product. In this case, to measure the impact of a prototype, we needed to add an attribute that didn't previously exist to one of our database models.

With that out of the way, let's dive into how we did it!

Backend engineer Eric Betts and I started with a script from a smaller version of this task: backfilling 130,000 documents. The smaller backfill had taken about 11 hours, including time to tweak the script and restart it a few times when it died. At a backfill rate of 175-200 documents per minute, we were looking at a best-case scenario of eight to nine days straight of backfilling for over two million total documents, and that's assuming everything went off without a hitch. With a much bigger backfill ahead of us, we needed to see if we could optimize.

The starting script took two arguments—a `batch_size` and `thread_pool_size` size—and it worked like this:

1. Create a new queue.
2. Create a variable to store the number of documents we've processed.
3. Query the database, limiting returned results to the `batch_size` we passed in.
4. Push each returned document into the queue.
5. Create the number of worker threads we passed in with the `thread_pool_size` argument.
6. Each thread makes an API call to a third-party API, then writes our new attribute to our database with the result from the third-party API.
7. Update our count of documents processed.
8. When there are no more documents in the queue to process, clean up the threads.

The script runs on a Kubernetes pod with memory and CPU constraints. It reads from our production MongoDB database and writes to a secondary.

## More repos, more problems

When scaling up the original script to process 20 times the number of documents, we quickly hit some limitations:

**Pod memory constraints.** Running the script with `batch_size` of two million documents and `thread_pool_size` of five was promptly killed by the Kubernetes pod:
```rb
Backfill.run(2000000, 5)
```

**Too much manual intervention.** Running with `batch_size` of 100 and `thread_pool` of five worked much better:
```rb
Backfill.run(100, 5)
```

It ran super fast 🚀 there were no errors ✨... but we would have had to manually run it 20,000 times.

**Third-party API rate limits.** Even with a reliable `batch_size`, we couldn't crank the `thread_pool_size` too high or we'd hit rate limits at the third-party API. Our script would finish running, but many of our documents wouldn't actually be backfilled, and we'd have to iterate over them again.

## Brainstorming solutions

Eric and I needed something that met the following criteria:

* Doesn't use so much memory that it kills the Kubernetes pod.
* Doesn't use so much memory that it noticeably increases database read/write latency.
* Iterates through a complete batch of objects at a time; the job shouldn't die before at least attempting to process a full batch.
* Requires minimal babysitting. Some manual intervention is okay, but we need a job to run for several hours by itself.
* Lets us pick up where we left off. If the job dies, we don't want to waste time re-processing documents we've already processed once.

With this list of criteria, we started brainstorming solutions. We could:

1. Dig into why the script was timing out before processing the full batch.
2. Store references to documents that failed to be updated, and loop back over them later.
3. Find a way to order the results returned by the database.
4. Automatically add more jobs to the queue once the initial batch was processed.

## Optimizations
### You're in time out

#1 was an obvious necessity. We started logging the thread index to see if it would tell us anything:
```rb
def self.run(batch_size, thread_pool_size)
  jobs = Queue.new
  
  # get all the documents that meet these criteria
  objs = Obj.where(...)
  # limit the returned objects to the batch_size
  objs = objs.limit(batch_size)
  # push each document into the jobs queue to be processed
  objs.each { |o| jobs.push o }
  
  # create a thread pool
  workers = (thread_pool_size).times.map do |i|
    Thread.new do
      begin
        while j = jobs.pop(true)
          # log the thread index and object ID
          Rails.logger.with_fields(thread: i, obj: obj.id)
          begin
            # process objects
          end
...
```
This new log line let us see threads die off as the script ran. We'd go from running with five threads:
```
thread="4" obj="939bpca..."
thread="1" obj="939apca..."
thread="5" obj="939cpca..."
thread="2" obj="939dpca..."
thread="3" obj="939fpca..."
thread="4" obj="969bpca..."
thread="1" obj="969apca..."
thread="5" obj="969cpca..."
thread="2" obj="969dpca..."
thread="3" obj="969fpca..."
```
to running with a few:
```
thread="4" obj="989bpca..."
thread="1" obj="989apca..."
thread="4" obj="979bpca..."
thread="1" obj="979apca..."
```
to running with none. 

We realized that when a thread would hit an error in an API request or a write to our database, we were rescuing and printing the error, but not continuing with the loop. This was a simple fix: When we `rescue`, continue to the `next` iteration of the loop.
```rb
          begin
            # process documents
          rescue
            next
          end
```

### Order, order

In a new run of the script, we needed a way to pick up where we left off. Idea #2—keeping track of failures across iterations of the script—was technically possible, but it wasn't going to be pretty. We expected idea #3—ordering the query results—to solve the same problem, but in a better way, so we went with that instead. Eric came up with the idea to order our query results by `created_at` date. This way, we could pass a `not_before` date argument when running the script to ensure that we weren't processing already-processed objects. We could also print each document's `created_at` date as it was processed, so that if the script died, we could grab that date and pass it into the next run. Here's what it looked like:

```rb
def self.run(batch_size, thread_pool_size, not_before)
  jobs = Queue.new
  
  # order the query results in ascending order
  objs = Obj.where(...).order(created_at: -1)
  # get documents created after the not_before date
  objs = objs.where(:created_at.gte => not_before)
  # limit the returned documents to the batch_size
  objs = objs.limit(batch_size)
  # push each document into the jobs queue to be processed
  objs.each { |o| jobs.push o }

  workers = (thread_pool_size).times.map do |i|
    Thread.new do
      begin
        while j = jobs.pop(true)
          # log each document's created_at date as it's processed
          Rails.logger.with_fields(thread: i, obj: obj.id, created_at: obj.created_at)
          begin
            # process documents
          rescue
            next
          end
...
```

So a log line might look like:
`thread="6" obj="979apca..." created_at="Wed, 11 Nov 2020 02:04:11.891000000 UTC +00:00"`

And if the script died after that line, we could grab that date and pass it back in:
`Backfill.run(50000, 10, "Wed, 11 Nov 2020 02:04:11.891000000 UTC +00:00")`

Nice!

Unfortunately, when we added the ordering, we found that we unintentionally introduced a new memory limitation: the query results were sorted in memory, so we couldn't pass in too large of a batch size or we'd run out of memory on the Kubernetes pod. This lowered our batch size substantially, but we accepted the tradeoff since it eliminated the possibility of redoing work that had already been done.

### The job is never done
The last critical task was to make our queue add to itself once the original batch of documents was processed. 

Our first approach was to check the queue size, add more objects to the queue when queue size reached some threshold, and re-run the original query, but skip all the returned query results that we'd already processed. We stored the number we'd already processed in a variable called `skip_value`. Each time we added to the queue, we would increase `skip_value` and skip an increasingly large number of results. 

You can tell where this is going. At some point, we would try to skip too large of a value, run out of memory, fail to refill the queue, and the job would die.

```rb
  skip_value = batch_size
  step = batch_size
  
  loop do
    if jobs.size < 1000
      objs = Obj.where(...).order(created_at: -1)
      objs = objs.where(:created_at.gte => created_at)
      objs = objs.skip(skip_value).limit(step) # <--- job dies when this skip_value gets too big ❌
      objs.each { |r| jobs.push r }
      
      skip_value += step # <--- this keeps increasing as we process more objects ❌
  
      if objs.count == 0
        break
      end
    end
  end
```

We ultimately tossed out the increasing `skip_value`, opting instead to store the `created_at` date of the last object processed. This way, we could skip a constant, relatively low number of documents instead of [slowing down](https://docs.mongodb.com/manual/reference/method/cursor.skip/#using-skip--) and eventually killing our query by skipping an increasing number:

```rb
  refill_at = 1000
  step = batch_size
  
  loop do
    if jobs.size < refill_at
      objs = Obj.where(...).order(created_at: -1)
      objs = objs.where(:created_at.gte => last_created_at) # <--- grab last_created_at constant from earlier in the script ✅
      objs = objs.skip(refill_at).limit(step) # <--- skip a constant amount ✅
      objs.each { |r| jobs.push r }
  
      if objs.count == 0
        break
      end
    end
  end
```

So, with our existing loop to create and kick off the threads, we have something like this:
```rb
def self.run(batch_size, thread_pool_size, not_before)
  jobs = Queue.new
  
  objs = Obj.where(...).order(created_at: -1)
  objs = objs.where(:created_at.gte => not_before)
  objs = objs.limit(step)
  objs.each { |o| jobs.push o }

  updated = 0
  last_created_at = "" # <--- we update this variable... 
  
  workers = (thread_pool_size).times.map do |i|
    Thread.new do
      begin
        while j = jobs.pop(true)
          Rails.logger.with_fields(thread: i, obj: obj.id, created_at: obj.created_at)
          begin
            # process documents
            updated += 1
            last_created_at = obj.created_at # <--- ...with each document processed
          rescue
            next
          end
        end
      end
    end
  end
      
  loop do
    skip_value = batch_size
    step = 10000
  
    if jobs.size < 1000
      objs = Obj.where(...).order(created: -1)
      objs = objs.where(:created_at.gte => not_before)
      objs = objs.skip(skip_value).limit(step)
  
      objs.each { |r| jobs.push r }
      skip_value += step
  
      if objs.count == 0
        break
      end
    end
  end 
  workers.map(&:join)
end
```

With this, we were finally getting the queue to add to itself when it was done. But the first time we ran this, we saw something surprising. The initial batch of 50,000 documents was processed quickly, and then the next batch that was added by our self-adding queue was processed very slowly. We ran `top -H` to check CPU and memory usage of our script on the Kubernetes pod and saw that it was using 90% of the system's CPU:

![](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/output_showing_cpu_usage_f67af92926.png)

Adding a few `sleep` statements between loop iterations [helped us get CPU usage down](https://stackoverflow.com/a/38440489) to a very reasonable 6% for the main process.

With these optimizations ironed out, Eric and I were able to complete our backfill at a processing rate of 800+ documents/minute with no manual intervention. Woohoo!

Learn how the Netlify growth team reduced the time it took to backfill nearly two million documents in our MongoDB database with a new attribute.

How We Backfilled 2 Million Database Documents

This article is part of a three-parts series on deploying MongoDB across multiple Kubernetes clusters using the operators.

-   Deploying the MongoDB Enterprise Kubernetes Operator on Google Cloud

-   [Mastering MongoDB Ops Manager](https://www.mongodb.com/developer/products/connectors/mastering-ops-manager)

-   [Deploying MongoDB Across Multiple Kubernetes Clusters With MongoDBMulti](https://www.mongodb.com/developer/products/connectors/deploying-across-multiple-kubernetes-clusters)

Deploying and managing MongoDB on Kubernetes can be a daunting task. It requires creating and configuring various Kubernetes resources, such as persistent volumes, services, and deployments, which can be time-consuming and require a deep understanding of both Kubernetes and MongoDB products. Furthermore, tasks such as scaling, backups, and upgrades must be handled manually, which can be complex and error-prone. This can impact the reliability and availability of your MongoDB deployment and may require frequent manual intervention to keep it running smoothly. Additionally, it can be hard to ensure that your MongoDB deployment is running in the desired state and is able to recover automatically from failures.

Fortunately, MongoDB offers operators, which are software extensions to the Kubernetes API that use custom resources to manage applications and their components. The MongoDB Operator translates human knowledge of creating a MongoDB instance into a scalable, repeatable, and standardized method, and leverages Kubernetes features to operate MongoDB for you. This makes it easier to deploy and manage MongoDB on Kubernetes, providing advanced features and functionality for running MongoDB in cloud-native environments.

There are three main Kubernetes operators available for deploying and managing MongoDB smoothly and efficiently in Kubernetes environments:

-   [The MongoDB Community Kubernetes Operator](https://github.com/mongodb/mongodb-kubernetes-operator) is an open-source operator that is available for free and can be used to deploy and manage MongoDB Replica Set on any Kubernetes cluster. It provides basic functionality for deploying and managing MongoDB but does not include some of the more advanced features available in the Enterprise and Atlas operators.

-   [The MongoDB Enterprise Kubernetes Operator ](https://github.com/mongodb/mongodb-enterprise-kubernetes)is a commercial Kubernetes operator included with the MongoDB Enterprise subscription. It allows you to easily deploy and manage any type of MongoDB deployment (standalone, replica set, sharded cluster) on Kubernetes, providing advanced features and functionality for deploying and managing MongoDB in cloud-native environments.

-   [The MongoDB Atlas Kubernetes Operator](https://github.com/mongodb/mongodb-atlas-kubernetes) is an operator that is available as part of the Atlas service. It allows you to quickly deploy and manage MongoDB on the Atlas cloud platform, providing features such as automatic provisioning and scaling of MongoDB clusters, integration with Atlas features and services, and automatic backups and restores. You can learn more about this operator in our blog post on [application deployment in Kubernetes](https://www.mongodb.com/developer/products/atlas/kubernetes-operator-application-deployment/).

This article will focus on the Enterprise Operator. [The MongoDB Enterprise Kubernetes Operator](https://www.mongodb.com/docs/kubernetes-operator/master/) seamlessly integrates with other MongoDB Enterprise features and services, such as MongoDB Ops Manager (which can also run on Kubernetes) and MongoDB Cloud Manager. This allows you to easily monitor, back up, upgrade, and manage your MongoDB deployments from a single, centralized location, and provides access to a range of tools and services for managing, securing, and optimizing your deployment.

## MongoDB Enterprise Kubernetes Operator

The MongoDB Enterprise [Kubernetes Operator](https://kubernetes.io/docs/concepts/extend-kubernetes/operator/) automates the process of creating and managing MongoDB instances in a scalable, repeatable, and standardized manner. It uses the Kubernetes API and tools to handle the lifecycle events of a MongoDB cluster, including provisioning storage and computing resources, configuring network connections, setting up users, and making changes to these settings as needed. This helps to ease the burden of manually configuring and managing stateful applications, such as databases, within the Kubernetes environment.

![The Kubernetes Operator manages the typical lifecycle events for a MongoDB cluster: provisioning storage and computing power, configuring network connections, setting up users, and changing these settings as needed](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/kubernetes_operator_bakedsvg_1c1a6d427b.svg)

## Kubernetes Custom Resource Definitions

[Kubernetes CRDs](https://kubernetes.io/docs/tasks/extend-kubernetes/custom-resources/custom-resource-definitions/) (Custom Resource Definitions) is a feature in Kubernetes that allows users to create and manage custom resources in their Kubernetes clusters. [Custom resources](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/) are extensions of the Kubernetes API that allow users to define their own object types and associated behaviors. With CRDs, you can create custom resources that behave like built-in Kubernetes resources, such as StatefulSets, Deployments, Pods, and Services, and manage them using the same tools and interfaces. This allows you to extend the functionality of Kubernetes and tailor it to their specific needs and requirements.

The MongoDB Enterprise Operator currently provides the following custom resources for deploying MongoDB on Kubernetes:

-   [MongoDBOpsManager Custom Resource](https://github.com/mongodb/mongodb-enterprise-kubernetes/tree/master/samples/ops-manager)

-   [MongoDB Custom Resource](https://www.mongodb.com/docs/kubernetes-operator/master/tutorial/mdb-resources-arch/#the-mongodb-custom-resource-definition)

    -   Standalone

    -   ReplicaSet

    -   ShardedCluster

-   [MongoDBUser Custom Resource](https://www.mongodb.com/docs/kubernetes-operator/master/tutorial/mdb-resources-arch/#reconciling-the-mongodbuser-custom-resource)

-   [MongoDBMulti](https://www.mongodb.com/docs/kubernetes-operator/master/multi-cluster-arch/#deployment-architecture-and-diagram)

![The following diagram describes how the Kubernetes Operator behaves if you make changes to a sharded cluster's](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/Mongo_DB_2d08c18419.png)

[Example of Ops Manager and MongoDB Custom Resources on Kubernetes](https://drive.google.com/file/d/1q7dvZ9PT9YU2EtJNyeYyl00DjKvQajl9/view)

## Installing and configuring Enterprise Kubernetes Operator

For this tutorial, we will need the following tools: 

-   [gcloud](https://cloud.google.com/sdk/docs/install)[ ](https://go.dev/dl/)

-   [gke-cloud-auth-plugin](https://cloud.google.com/blog/products/containers-kubernetes/kubectl-auth-changes-in-gke)

-   [Helm](https://helm.sh/docs/intro/install/)

-   [kubectl](https://kubernetes.io/docs/tasks/tools/)

-   [kubectx](https://github.com/ahmetb/kubectx)

-   [Git](https://git-scm.com/downloads)

## GKE Kubernetes cluster creation 

To start, let's create a Kubernetes cluster in a new [project](https://cloud.google.com/resource-manager/docs/creating-managing-projects). We will be using [GKE Kubernetes](https://cloud.google.com/kubernetes-engine). I use this script to create the cluster. The cluster will have four worker nodes and act as Ops Manager and MongoDB Enterprise Operators Kubernetes Cluster.

```bash
CLUSTER_NAME=master-operator
ZONE=us-south1-a
K8S_VERSION=1.23
MACHINE=n2-standard-2
gcloud container clusters create "${CLUSTER_NAME}" \
  --zone "${ZONE}" \
  --machine-type "${MACHINE}" --cluster-version="${K8S_VERSION}" \
  --disk-type=pd-standard --num-nodes 4
```

Now that the cluster has been created, we need to obtain the credentials.

```bash
gcloud container clusters get-credentials "${CLUSTER_NAME}" \
  --zone "${ZONE}"
```


Display the newly created cluster.

```bash
gcloud container clusters list

NAME                LOCATION       MASTER_VERSION    NUM_NODES  STATUS
master-operator     us-south1-a    1.23.14-gke.1800      4      RUNNING
```

We can also display Kubernetes full cluster name using [`kubectx`](https://github.com/ahmetb/kubectx).

```bash
kubectx
```

You should see your cluster listed here. Make sure your context is set to master cluster.

```bash
kubectx $(kubectx | grep "master-operator" | awk '{print $1}')
```


We are able to start MongoDB Kubernetes Operator installation on our newly created Kubernetes cluster! 

## Enterprise Kubernetes Operator 

We can install the MongoDB Enterprise Operator with a single line Helm command. The first step is to  add the [MongoDB Helm Charts for Kubernetes](https://mongodb.github.io/helm-charts/) repository to Helm.

```bash
helm repo add mongodb https://mongodb.github.io/helm-charts
```


I want to create the operator in a separate, dedicated Kubernetes namespace (the operator uses `default` namespace by default). This will allow me to isolate the operator and any resources it creates from other resources in my cluster. The following command will install the CRDs and the Enterprise Operator in the `mongodb-operator`namespace. The operator will be watching only the `mongodb-operator` namespace. You can read more about [setting up the operator to watch more namespaces](https://www.mongodb.com/docs/kubernetes-operator/master/tutorial/set-scope-k8s-operator/#operator-uses-a-subset-of-namespaces) in the official MongoDB documentation.

Start by creating the `mongodb-operator`namespace.

```bash
NAMESPACE=mongodb-operator
kubectl create ns "${NAMESPACE}"
```


Install the MongoDB Kubernetes Operator and set it to watch only the `mongodb-operator` namespace.

```bash
HELM_CHART_VERSION=1.16.3
helm install enterprise-operator mongodb/enterprise-operator \
  --namespace "${NAMESPACE}" \
  --version="${HELM_CHART_VERSION}" \
  --set operator.watchNamespace="${NAMESPACE}"
```


The namespace has been created and the operator is running! You can see this by listing the pods in the newly created namespace.

```bash
kubectl get ns

NAME               STATUS   AGE
default            Active   4m9s
kube-node-lease    Active   4m11s
kube-public        Active   4m12s
kube-system        Active   4m12s
mongodb-operator   Active   75s
```

```bash
kubectl get po -n "${NAMESPACE}"

NAME                                    READY   STATUS   RESTARTS   AGE
mongodb-enterprise-operator-649bbdddf5   1/1    Running   0         7m9s
```


You can see that the helm chart is running with this command.

```bash
helm list --namespace "${NAMESPACE}"

NAME                NAMESPACE     REVISION       VERSION
enterprise-operator mongodb-operator 1 deployed enterprise-operator-1.17.2
```

### Verify the installation

You can verify that the installation was successful and is currently running with the following command.

```bash
helm get manifest enterprise-operator --namespace "${NAMESPACE}"
```

Let's display Custom Resource Definitions installed in the step above in the watched namespace.

```bash
kubectl -n "${NAMESPACE}" get crd | grep -E '^(mongo|ops)'

mongodb.mongodb.com                              2022-12-30T16:17:07Z
mongodbmulti.mongodb.com                         2022-12-30T16:17:08Z
mongodbusers.mongodb.com                         2022-12-30T16:17:09Z
opsmanagers.mongodb.com                          2022-12-30T16:17:09Z
```


All required service accounts has been created in watched namespace.

```bash
kubectl -n "${NAMESPACE}" get sa | grep -E '^(mongo)'

mongodb-enterprise-appdb           1         36s
mongodb-enterprise-database-pods   1         36s
mongodb-enterprise-operator        1         36s
mongodb-enterprise-ops-manager     1         36s
```

Validate if the Kubernetes Operator was installed correctly by running the following command and verify the output.

```bash
kubectl describe deployments mongodb-enterprise-operator -n \
  "${NAMESPACE}"
```


Finally, double-check watched namespaces.

```bash
kubectl describe deploy mongodb-enterprise-operator -n "${NAMESPACE}" | grep WATCH

      WATCH_NAMESPACE:               mongodb-operator
```


The MongoDB Enterprise Operator is now running in your GKE cluster.

## MongoDB Atlas Kubernetes Operator

It's worth mentioning another operator here --- a new service that integrates Atlas resources with your Kubernetes cluster. Atlas can be deployed in multi-cloud environments including Google Cloud. The Atlas Kubernetes Operator allows you to deploy and manage cloud-native applications that require data services in a single control plane with secure enterprise platform integration.

This operator is responsible for managing resources in Atlas using Kubernetes custom resources, ensuring that the configurations of projects, database deployments, and database users in Atlas are consistent with each other. The Atlas Kubernetes Operator uses the `AtlasProject`, `AtlasDeployment`, and `AtlasDatabaseUser` Custom Resources that you create in your Kubernetes cluster to manage resources in Atlas.

These custom resources allow you to define and configure the desired state of your projects, database deployments, and database users in Atlas. To learn more, head over to our blog post on [application deployment in Kubernetes](https://www.mongodb.com/developer/products/atlas/kubernetes-operator-application-deployment/) with the MongoDB Atlas Operator.

## Conclusion

Upon the successful installation of the Kubernetes Operator, we are able to use the capabilities of the MongoDB Enterprise Kubernetes Operator to run MongoDB objects on our Kubernetes cluster. The Operator enables easy deploy of the following applications into Kubernetes clusters:

-   MongoDB --- replica sets, sharded clusters, and standalones --- with authentication, TLS, and many more options.

-   Ops Manager --- enterprise management, monitoring, and backup platform for MongoDB. The Operator can install and manage Ops Manager in Kubernetes for you. Ops Manager can manage MongoDB instances both inside and outside Kubernetes. Installing Ops Manager is covered in the [second article](https://www.mongodb.com/developer/products/connectors/mastering-ops-manager) of the series.

-   MongoMulti --- Multi-Kubernetes-cluster deployments allow you to add MongoDB instances in global clusters that span multiple geographic regions for increased availability and global distribution of data. This is covered in the [final part](https://www.mongodb.com/developer/products/connectors/deploying-across-multiple-kubernetes-clusters) of this series.

Want to see the MongoDB Enterprise Kubernetes Operator in action and discover all the benefits it can bring to your Kubernetes deployment? Continue reading the [next blog](https://www.mongodb.com/developer/products/connectors/mastering-ops-manager) of this series and we'll show you how to best utilize the Operator for your needs

Learn how to deploy the MongoDB Enterprise Kubernetes Operator in this tutorial.

This article is part of a three-parts series on deploying MongoDB across multiple Kubernetes clusters using the operators.

-   [Deploying the MongoDB Enterprise Kubernetes Operator on Google Cloud](https://www.mongodb.com/developer/products/connectors/deploying-kubernetes-operator)

-   Mastering MongoDB Ops Manager

-   [Deploying MongoDB Across Multiple Kubernetes Clusters With MongoDBMulti](https://www.mongodb.com/developer/products/connectors/deploying-across-multiple-kubernetes-clusters)

Managing MongoDB deployments can be a rigorous task, particularly when working with large numbers of databases and servers. Without the right tools and processes in place, it can be time-consuming to ensure that these deployments are running smoothly and efficiently. One significant issue in managing MongoDB clusters at scale is the lack of automation, which can lead to time-consuming and error-prone tasks such as backups, recovery, and upgrades. These tasks are crucial for maintaining the availability and performance of your clusters.

Additionally, monitoring and alerting can be a challenge, as it may be difficult to identify and resolve issues with your deployments. To address these problems, it's essential to use software that offers monitoring and alerting capabilities. Optimizing the performance of your deployments also requires guidance and support from the right sources.

Finally, it's critical for your deployments to be secure and compliant with industry standards. To achieve this, you need features that can help you determine if your deployments meet these standards.

[MongoDB Ops Manager](https://www.mongodb.com/products/ops-manager) is a web-based application designed to assist with the management and monitoring of MongoDB deployments. It offers a range of features that make it easier to deploy, manage, and monitor MongoDB databases, such as:

-   [Automated backups and recovery](https://www.mongodb.com/docs/ops-manager/current/application/#backup): Ops Manager can take automated backups of your MongoDB deployments and provide options for recovery in case of failure.

-   [Monitoring and alerting](https://www.mongodb.com/docs/ops-manager/current/application/#monitoring): Ops Manager provides monitoring and alerting capabilities to help identify and resolve issues with your MongoDB deployments.

-   [Performance optimization](https://www.mongodb.com/docs/ops-manager/current/tutorial/performance-advisor/): Ops Manager offers tools and recommendations to optimize the performance of your MongoDB deployments.

-   [Upgrade management](https://www.mongodb.com/docs/ops-manager/current/tutorial/change-mongodb-version/): Ops Manager can help you manage and plan upgrades to your MongoDB deployments, including rolling upgrades and backups to ensure data availability during the upgrade process.

-   [Security and compliance](https://www.mongodb.com/docs/ops-manager/current/tutorial/nav/security/): Ops Manager provides features to help you secure your MongoDB deployments and meet compliance requirements.

However, managing Ops Manager can be a challenging task that requires a thorough understanding of its inner workings and how it interacts with the internal MongoDB databases. It is necessary to have the knowledge and expertise to perform upgrades, monitor it, audit it, and ensure its security. As Ops Manager is a crucial part of managing the operation of your MongoDB databases, its proper management is essential.

Fortunately, the MongoDB Enterprise Kubernetes Operator enables us to run Ops Manager on Kubernetes clusters, using native Kubernetes capabilities to manage Ops Manager for us, which makes it more convenient and efficient.

## Kubernetes: MongoDBOpsManager custom resource

The [MongoDB Enterprise Kubernetes Operator](https://www.mongodb.com/docs/kubernetes-operator/master/) is software that can be used to deploy Ops Manager and MongoDB resources to a Kubernetes cluster, and it's responsible for managing the lifecycle of each of these deployments. It has been developed based on years of experience and expertise, and it's equipped with the necessary knowledge to properly install, upgrade, monitor, manage, and secure MongoDB objects on Kubernetes.

The Kubernetes Operator uses the [MongoDBOpsManager custom resource](https://github.com/mongodb/mongodb-enterprise-kubernetes/tree/master/samples/ops-manager) to manage Ops Manager objects. It constantly monitors the specification of the custom resource for any changes and, when changes are detected, the operator validates them and makes the necessary updates to the resources in the Kubernetes cluster.

MongoDBOpsManager custom resources specification defines the following Ops Manager components:

-   The [Application Database](https://www.mongodb.com/docs/kubernetes-operator/master/tutorial/om-arch/#application-database)

-   The [Ops Manager application](https://www.mongodb.com/docs/kubernetes-operator/master/tutorial/om-arch/#application)

-   The [Backup Daemon](https://www.mongodb.com/docs/kubernetes-operator/master/tutorial/om-arch/#backup-daemon)

![MongoDBOpsManager custom resources specification defines the following Ops Manager components:
the Application Database,
the Ops Manager application, and
the Backup Daemon.](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/meko_arch_a94d843eaa.svg)

When you use the Kubernetes Operator to create an instance of Ops Manager, the Ops Manager MongoDB Application Database will be deployed as a replica set. It's not possible to configure the Application Database as a standalone database or a sharded cluster.

The Kubernetes Operator automatically sets up Ops Manager to monitor the Application Database that powers the Ops Manager Application. It creates a project named  `<ops-manager-deployment-name>-db` to allow you to monitor the Application Database deployment. While Ops Manager monitors the Application Database deployment, it does not manage it.

When you deploy Ops Manager, you need to configure it. This typically involves using the [configuration wizard](https://www.mongodb.com/docs/ops-manager/current/reference/config/ui-settings/). However, you can bypass the configuration wizard if you set certain essential settings in your object specification before deployment. I will demonstrate that in this post.

The Operator automatically enables backup. It deploys a StatefulSet, which consists of a single pod, to host the Backup Daemon Service and creates a Persistent Volume Claim and Persistent Volume for the Backup Daemon's head database. The operator uses the Ops Manager API to enable the Backup Daemon and configure the head database.

## Getting started

Alright, let's get started using the operator and build something! For this tutorial, we will need the following tools: 

-   [gcloud](https://cloud.google.com/sdk/docs/install)[ ](https://go.dev/dl/)

-   [gke-cloud-auth-plugin](https://cloud.google.com/blog/products/containers-kubernetes/kubectl-auth-changes-in-gke)

-   [Helm](https://helm.sh/docs/intro/install/)

-   [kubectl](https://kubernetes.io/docs/tasks/tools/)

-   [kubectx](https://github.com/ahmetb/kubectx)

-   [git](https://git-scm.com/downloads)

To get started, we should first create a Kubernetes cluster and then install the MongoDB Kubernetes Operator on the cluster. [Part 1](https://www.mongodb.com/developer/products/connectors/deploying-kubernetes-operator) of this series provides instructions on how to do so.

> **Note**
> For the sake of simplicity, we are deploying Ops Manager in the same namespace as our MongoDB Operator. In a production environment, you should deploy Ops Manager in its own namespace.

### Environment pre-checks 

Upon successful creation of a cluster and installation of the operator (described in [Part 1](https://www.mongodb.com/developer/products/connectors/deploying-kubernetes-operator)), it's essential to validate their readiness for use.

```bash
gcloud container clusters list

NAME                LOCATION       MASTER_VERSION    NUM_NODES  STATUS\
master-operator     us-south1-a    1.23.14-gke.1800      4      RUNNING
```

Display our new Kubernetes full cluster name using `[kubectx](https://github.com/ahmetb/kubectx)`.

```bash
kubectx
```

You should see your cluster listed here. Make sure your context is set to master cluster.

```bash
kubectx $(kubectx | grep "master-operator" | awk '{print $1}')
```

In order to continue this tutorial, make sure that the operator is in the `running`state.

```bash
kubectl get po -n "${NAMESPACE}"

NAME                                    READY   STATUS   RESTARTS   AGE\
mongodb-enterprise-operator-649bbdddf5   1/1    Running   0         7m9s
```

## Using the MongoDBOpsManager CRD

Create a secret containing the username and password on the master Kubernetes cluster for accessing the Ops Manager user interface after installation.

```bash
kubectl -n "${NAMESPACE}" create secret generic om-admin-secret \
  --from-literal=Username="opsmanager@example.com" \
  --from-literal=Password="p@ssword123" \
  --from-literal=FirstName="Ops" \
  --from-literal=LastName="Manager"
```
​​
### Deploying Ops Manager 

Then, we can [deploy Ops Manger on the master Kubernetes](https://github.com/mongodb/mongodb-enterprise-kubernetes/tree/master/samples/ops-manager) cluster with the help of `opsmanagers`  Custom Resource, creating `MongoDBOpsManager` object, using the following manifest:

```bash
OM_VERSION=6.0.5
APPDB_VERSION=5.0.5-ent
kubectl apply -f - <<EOF
apiVersion: mongodb.com/v1
kind: MongoDBOpsManager
metadata:
  name: ops-manager
  namespace: "${NAMESPACE}"
spec:
  version: "${OM_VERSION}"
  # the name of the secret containing admin user credentials.
  adminCredentials: om-admin-secret
  externalConnectivity:
    type: LoadBalancer
  configuration:
    mms.ignoreInitialUiSetup: "true"
    automation.versions.source: mongodb
    mms.adminEmailAddr: support@example.com
    mms.fromEmailAddr: support@example.com
    mms.replyToEmailAddr: support@example.com
    mms.mail.hostname: example.com
    mms.mail.port: "465"
    mms.mail.ssl: "false"
    mms.mail.transport: smtp
  # the Replica Set backing Ops Manager.
  applicationDatabase:
    members: 3
    version: "${APPDB_VERSION}"
EOF
```
 
 After a few minutes, we should see our Ops Manager and Ops Manager MongoDB application database pods running.

```​​bash
kubectl -n "${NAMESPACE}" get pods

NAME                                       READY      STATUS     RESTARTS
ops-manager-0                           1/1      Running      0
ops-manager-db-0                        3/3      Running      0
ops-manager-db-1                        3/3      Running      0
ops-manager-db-2                        3/3      Running      0
```

Storage part creation has been orchestrated by the operator. [Persistent Volumes Claims ](https://kubernetes.io/docs/concepts/storage/persistent-volumes/) are created and can be displayed via

```bash
kubectl -n "${NAMESPACE}" get pvc

NAME       STATUS   VOLUME     CAPACITY  ACCESS MODES   STORAGE CLASS   AGE
data-ops-manager-db-0 Bound pvc-d5a1b385-6d1b  15Gi  RWO  standard  59m
data-ops-manager-db-1 Bound pvc-db0e89dc-d73a  15Gi  RWO  standard  58m
data-ops-manager-db-2 Bound pvc-c7e124a2-917   15Gi  RWO  standard  57m
```

[Kubernetes StatefulSets](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/) has also been created by the Operator.

```bash
kubectl -n "${NAMESPACE}" get sts

NAME             READY   AGE
ops-manager      1/1     29m31s
ops-manager-db   3/3     30m29s
```

The operator has created all required network services, including a Load Balancer service type for the Ops manager access, so we now have an external IP address and can log into the Ops Manager from outside the Kubernetes cluster. You can verify IPs by viewing the services.

```bash
kubectl -n "${NAMESPACE}" get svc

NAME                  TYPE    CLUSTER-IP    EXTERNAL-IP  PORT(S)
ops-manager-db-svc  ClusterIP    None        <none>      27017/TCP
ops-manager-svc     ClusterIP    None        <none       8080/TCP,25999/TCP
ops-manager-svc-ext LoadBalancer 10.76.10.231 34.174.54.103 8080:32078/TCP ,25999:31961/TCP    
```

The following diagram describes how the Kubernetes Operator reconciles changes to the  MongoDBOpsManager CustomResourceDefinition.

![The following diagram describes how the Kubernetes Operator reconciles changes to the MongoDBOpsManager CustomResourceDefinition](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/Ops_Manager_objects_5e8862d468.png)

To generate Ops Manager URL address, execute:

```bash
URL=http://$(kubectl -n "${NAMESPACE}" get svc ops-manager-svc-ext -o jsonpath='{.status.loadBalancer.ingress[0].ip}:{.spec.ports[0].port}')
echo $URL
```

The URL address will look similar to the example provided, but IP address may vary depending on the Kubernetes cluster.

```bash
http://34.174.54.105:8080
```

The final step is to update the Ops Manager Kubernetes manifest to include an external IP address created by Load Balancer in `spec.configuration.mms.centralUrl`  via `kubectl patch`.

```bash
kubectl -n "${NAMESPACE}" patch om ops-manager --type=merge -p "{\"spec\":{\"configuration\":{\"mms.centralUrl\":\"${URL}\"}}}"
```

We should wait a few minutes. The Ops Manager pod must be restarted, so wait until the `ops-manager-0` pod is in the `running` state again.

Using the username and password stored in the `om-admin-secret` (opsmanager@example.com : p@ssword123), we can log in to the Ops Manager User Interface using the address in the `$URL` variable.

![Enter your username and password and click Login](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/Ops_Manager_c44549fd1e.png)

The Kubernetes Operator was in the Ops Manager `ops-manager-db` organization and the `ops-manager-db` project.

![Select Ops Manager organization](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/Ops_Manager_UI_834b2820aa.png)

If we click on the project `ops-manager-db`, we will be redirected to the panel where we can see the database pods of the Ops Manager application. Ops Manager monitors this database.

![Manage your MongoDB cluster from Ops Manager](https://mongodb-devhub-cms.s3.us-west-1.amazonaws.com/Ops_Manager_App_DB_5f3ae3ae3e.png)

## Basic troubleshooting

If you run through issues during the installation, here are some clues to help you investigate what went wrong.

If you want to display an Ops Manager cluster, use this command. It will show you a general overview of `om` objects, including internal database and Backup Daemon state.

```bash
kubectl -n "${NAMESPACE}" get om

NAME REPLICAS VERSION STATE(OPSMANAGER) STATE(APPDB) STATE (BACKUP)   AGE
ops-manager     6.0.5     Running        Running     Pending          18m  
```
 

You can use `describe` to get a detailed overview.

```bash
kubectl -n "${NAMESPACE}" describe om ops-manager
```

It's always a good idea to check the Ops Manager logs

```bash
kubectl -n "${NAMESPACE}" logs -f po/ops-manager-0
```

or current `events` from the namespace.

```bash
kubectl -n "${NAMESPACE}" get events
```

## Summary

We have just installed Ops Manager on our Kubernetes cluster. This gives us many benefits. The operator has properly installed and configured the Ops Manager instance with the internal database, took care of the storage portion, and created network services, including a Load Balancer. We can now use Ops Manager and easily create any kind of MongoDB database on the Kubernetes cluster following the best practices, monitor instances of our databases, introduce query optimizations with the help of the Ops Manager performance advisor, and provide backup, restore, or rolling upgrades through automation.

In the [next part](https://www.mongodb.com/developer/products/connectors/deploying-across-multiple-kubernetes-clusters), I will demonstrate how to run the latest type of MongoDB Kubernetes Custom Resource, a Multi Cluster Replica Set. This replica set will be deployed across three separate Kubernetes clusters located in different regions, providing the ideal solution for critical applications that require continuous availability, even in the event of a Kubernetes cluster failure.
Want to get started with the MongoDB Ops Manager on your own Kubernetes cluster? [Install  it now](https://github.com/mongodb/helm-charts/tree/main/charts/enterprise-operator) and see for yourself how it can simplify your operations. Make sure to visit the [MongoDB community forum](https://www.mongodb.com/community/forums/) for the latest discussions and resources

Learn how to deploy the MongoDB Ops Manager in a Kubernetes cluster with the MongoDB Kubernetes Operators.

Kubernetes

Featured

How to Deploy Vector Search, Atlas Search, and Search Nodes With the Atlas Kubernetes Operator

Advancing Developer Tools and Multi-Cluster Kubernetes: Insights from MongoDB Experts

How to Deploy MongoDB Atlas With the Atlas Kubernetes Operator

All Kubernetes Content