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
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:
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:
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.
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 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?
To answer the above questions, let us understand how a stateful application works.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Operators extend Kubernetes with domain-specific functionality software extensions. They are maintained by domain experts and are available for use in any Kubernetes environment.