AnnouncementIntroducing MongoDB 8.0, the fastest MongoDB ever! Read more >
NEWSLearn why MongoDB was named a leader in the 2024 Gartner® Magic Quadrant™ Read the report >
AnnouncementIntroducing Search Demo Builder, the newest addition to the Atlas Search Playground Learn more >

The MongoDB Kubernetes Operators

Kubernetes operators are powerful tools for managing stateful applications in Kubernetes environments. They simplify the process by leveraging the operator pattern, custom resource definitions (CRDs), and custom resources to handle application-specific tasks such as scaling, backups, and configuration. These custom resource definitions extend the Kubernetes API, enabling it to manage stateful applications like MongoDB effectively.

The MongoDB Kubernetes Operators integrate seamlessly with its clusters, leveraging tools like the Operator SDK and the control plane to automate complex tasks. By defining custom controllers, they ensure MongoDB instances maintain their desired state throughout their entire life cycle. This approach eliminates the need for extensive manual intervention, making it easier to manage complex applications even in a cloud-native environment.

In this article, we’ll explore how MongoDB Kubernetes Operators enhance application management by using CRDs, runtime Kubernetes tools, and the Kubernetes control plane to simplify the deployment and scaling of MongoDB in containerized environments.


Table of contents

What is a Kubernetes operator?

A Kubernetes operator is an application-specific controller that extends Kubernetes functionality to manage applications by using custom resource definitions to automate management. Operators promote self-servicing and automation, leading to faster application development. A Kubernetes operator can automate:

  • The process of deploying an application on demand.
  • Application installation and upgrades with the required configuration.
  • The scaling and monitoring of applications.
  • Taking restore and backup of the application state.
  • Recovery from failures.

For example, a database operator might extend the Kubernetes API with custom resources such as AtlasProject and AtlasDatabaseUser. These resources are deployed to Kubernetes clusters and are managed by the operator.

The operator can:

  • Be used to configure the number of members in a replica set by reconfiguring the database deployment, thus automating the scaling.
  • Manage authentication across different environments with a centralized configuration.

An image of how Kubernetes operators work including custom resource definition.

How Kubernetes operators simplify application management

Kubernetes is an open-source orchestrator for containers that lets you:

  • Better manage and scale your applications. You describe the pods and how they should interact with each other, and it takes care of the rest.

  • Orchestrate many containers across several hosts, scale them as micro-services, and deploy updates and rollbacks with zero downtime.

  • Use stateless applications—you provide a configuration that describes the “desired state” of your deployment, letting it do the heavy lifting.

    • For example, you can create a pod that spins up your static website. Then, you can instruct it to manage three replicas of the application. In case a pod fails or goes down, Kubernetes will automatically restart it to achieve the desired state—three running replicas. You can also scale up or down the number of replicas while the application is running.

But what about stateful applications that need a persistent storage solution—for example, database systems like MongoDB, cloud storage services like AWS, or network access storage (NAS) that needs to persist the data and state?


MongoDB deploys its own distributed systems

MongoDB is designed to be deployed in its own distributed systems, with replica sets for high availability and sharding for scalability. Kubernetes is designed to be a general-purpose container orchestrator—it doesn't have the knowledge to manage MongoDB topologies. Nor does it know how to provision database users or control other internal aspects of MongoDB. How can we manage a MongoDB cluster, or any database, with Kubernetes?

Why do you need a Kubernetes operator?

To answer the above questions, let us understand how a stateful application works.

  • Stateful applications require data to be persisted.
  • If a pod is restarted, it is attached to the same data.
  • For this, Kubernetes provides the StatefulSets API.
  • You can access the physical storage devices in the form of PersistentVolume objects, wherein each volume is associated with one pod through its entire life cycle.

Common issues: The problem comes when you have to upscale or downscale the application. Removing or adding pods becomes tough, as StatefulSets provide generic methods and may not be able to handle application-specific data migration and replication. Also, your application might still need human operators with deep knowledge of the specific domain to handle version upgrades and configuration changes.

Possible solutions: Kubernetes operators solve this problem by automating the management of object types and applications that require domain knowledge. Kubernetes operators track and manage object types, applications, and objects called custom resources (CRs) that extend capabilities with domain-specific functionality.

Components of the Kubernetes operator


Kubernetes API server

The kube-apiserver is a core component of the default control plane that lets you extend the functionality of your application via the Kubernetes API. The API server communicates with other Kubernetes controllers, like the operator controller, to automate application-specific tasks.


Custom resource

A custom resource is anything that your kubernetes application needs or wants to run but the standard Kubernetes API does not provide by default. It can be an application-specific deployment, service, application configuration, database instance, declarative API, or API objects. While using the Kubernetes operator, the operator acts as a custom controller that watches a custom resource and encodes the domain-specific functionalities in the CR.


Custom resource definition

Kubernetes provides two ways to add custom resources, one of which is through the CustomResourceDefinitions (CRD). Using the other method—API aggregation—requires programming language knowledge, but it allows for more control over the resources.

CRDs are API objects that are easy to create and do not need any programming language knowledge.

When you install a custom resource into the Kubernetes API using CRD, the Kubernetes API server (kube-apiserver) creates a new RESTful resource path (endpoint). You can then create and manage custom objects through this endpoint URL. Custom objects contain custom fields stored as structured data in the custom resource. CRDs contain all the information on the structure, schema (validation), and behavior of a CR.


Reconciliation loop (Kubernetes control loop)

The reconciliation loop is an infinite loop that watches for change events in a custom resource. If there is an event, the Kubernetes operator’s controller checks for the declared desired state from the CustomResourceDefinition. If the actual state in the CR does not match the desired state, the operator makes the necessary changes to set the desired state in the cluster/application using the Kubernetes API. The Kubernetes operator can track events like add, update, and delete. For example, if the operator has to perform a resource cleanup and notes that the cluster's actual state of the software running the resource does not match the desired state, it can perform tasks like adjusting the configuration, creating a backup, restarting the pod, or deleting a service.


An image of what a reconciliation loop is.

MongoDB Kubernetes Operators

Although you can create your own Kubernetes operator framework using the Operator Framework and the Operator SDK, many companies provide ready-to-use operators. It is beneficial to use the existing popular operators for easy maintenance, community support, and faster application development. With MongoDB Kubernetes Operators, your applications can self-manage MongoDB instances in Kubernetes. MongoDB officially supports three popular Kubernetes operators:

  • MongoDB Atlas Operator—allows you to create and manage your cloud-based - MongoDB Atlas projects and clusters

  • MongoDB Enterprise Operator—available with MongoDB Enterprise Advanced; enables MongoDB standalone instances, replica sets, and sharded clusters to be managed by Kubernetes; can also install and manage the Ops Manager

  • MongoDB Community Operator—used for simple deployments of MongoDB Community


All of the operators make it possible to integrate MongoDB with your Kubernetes environment and the apps that you run there.


MongoDB Atlas Kubernetes Operator

The MongoDB Atlas Operator for Kubernetes allows you to manage instances of MongoDB Atlas, MongoDB's database-as-a-service platform, natively from Kubernetes. You can provision MongoDB Atlas projects, clusters, and users. The operator keeps your deployment in the desired state by making API calls to MongoDB Atlas. With the Atlas operator, you can configure your Atlas clusters without ever leaving Kubernetes.

For more information about the MongoDB Atlas Kubernetes Operator, visit the dedicated documentation page.


MongoDB Enterprise Kubernetes Operator

The MongoDB Enterprise Operator for Kubernetes lets you deploy and manage MongoDB database resources to a Kubernetes cluster. You can deploy standalone instances, replica sets, and sharded clusters. Whichever you choose, the operator will control the lifecycle of the deployment, making sure it is always kept in the desired state. You can also upgrade the running MongoDB version, scale your deployment, and resize the storage when needed. The Enterprise Operator is available for MongoDB Enterprise Advanced customers.

To learn all about the MongoDB Enterprise Kubernetes Operator, visit the dedicated documentation page.


MongoDB Community Kubernetes Operator

Using this operator, you can deploy a MongoDB community instance to a Kubernetes cluster. The MongoDB community operator can create replica sets, connect to replica sets from inside the cluster, scale the replicas up or down, upgrade or downgrade the MongoDB server version, create custom roles, secure client-to-server and server-to-server connections with TLS, and much more. There are many features planned for the operator for future releases. You can visit the MongoDB Community Kubernetes Operator documentation page for details.

To create a forever-free cluster in MongoDB Atlas and control it from Kubernetes, check out the quick start guide.

FAQs

How do you deploy MongoDB on Kubernetes?

You can use the MongoDB Atlas Kubernetes Operator to manage all your Atlas resources, like clusters, projects, database users, and much more with Kubernetes. The MongoDB Enterprise Kubernetes Operator lets you provision standalone instances, replica sets, and sharded clusters, and manage them with Kubernetes. The Community Operator can be used for deploying applications on replica sets of MongoDB Community.

How do you use MongoDB Atlas with Kubernetes?

The MongoDB Atlas Kubernetes Operator integrates Atlas resources with your Kubernetes cluster. Using the Atlas Operator framework, you can deploy and control Atlas projects, clusters, and database users from your Kubernetes control plane.

What is a MongoDB Kubernetes operator?

Kubernetes operators for MongoDB allow you to deploy and control MongoDB clusters from Kubernetes. The MongoDB Atlas Operator controls resources in MongoDB Atlas, a fully managed cloud database; the MongoDB Enterprise Operator creates and deploys containerized MongoDB clusters within your self-managed Kubernetes environment. These operators translate the human knowledge of managing MongoDB clusters into automated actions, allowing you to deploy and manage MongoDB and MongoDB Atlas clusters in Kubernetes.

What is Kubernetes?

Kubernetes is a platform for orchestrating containerized applications. Kubernetes has many useful features that make the process of managing containers easier. Learn more about MongoDB and Kubernetes.

Why are there operators in Kubernetes?

Operators extend Kubernetes with domain-specific functionality software extensions. They are maintained by domain experts and are available for use in any Kubernetes environment.