Let’s briefly explore how we got here from a technical perspective. As you may know, support for MongoDB on Kubernetes has already been implemented by the MongoDB Enterprise Kubernetes Operator, or Operator for short. This was done by creating Kubernetes Custom Resources Definitions for MongoDB which describe the configuration for the MongoDB cluster to be deployed.

In August 2019 the alpha version of the MongoDBOpsManager Custom Resource was released. It allowed the Operator to start a single instance of Ops Manager in Kubernetes and the application database. The application database is used to store Ops Manager data.

In December 2019 the MongoDB Enterprise Kubernetes Operator 1.4.0 was released, at which point the MongoDBOpsManager Custom Resource was promoted to Beta with a rich feature set: high availability, backup, external access configuration, authentication for the application database and Openshift support.

In GA version MongoDBOpsManager got TLS support, rich status, fine-grained configuration of StatefulSets for Ops Manager and Backup, JVM parameters configuration, improved backup configuration.

This article will describe the architecture of Ops Manager in Kubernetes and provide step-by-step instructions detailing how to configure these additional Ops Manager features in Kubernetes. To follow along, it’s critical that you complete the steps in Part 1 of the tutorial.

Architecture

The Operator manages the MongoDBOpsManager Custom Resource and monitors for any updates to its specification. Each update results in a reconciliation process where the following actions are done:

1. The Operator creates/updates the application database StatefulSet running at least 3 MongoDB instances. StatefulSet is an API object that manages stateful applications.

Note: The only type allowed is Replica Set and SCRAM-SHA authentication is always enabled. Each database pod runs an instance of MongoDB Agent which is configured directly by the Operator.

1. The Operator creates/updates the StatefulSet running the Ops Manager pods. Ops Manager instances connect to the application database created in the previous step.
2. The Operator ensures the StatefulSet for the Backup Daemon is running unless backup is disabled. The StatefulSet consists of a single pod. The Backup Daemon connects to the same application database as the Ops Manager instance.
3. The Operator registers the first user with GLOBAL_OWNER role and saves a public API key to a secret for later usage. This is done only once during the Ops Manager creation.
4. The Operator configures the Backup Daemon using Ops Manager public API according to the backup specification.

#kubernetes #ops manager #mongodbopsmanager #api #mongodb