Reconciling the MongoDBOpsManager
Custom Resource
The following diagram describes how the Kubernetes Operator reconciles changes
to the MongoDBOpsManager
CustomResourceDefinition on each member Kubernetes cluster.
The Kubernetes Operator creates or updates the
<om_resource_name>-db-config
secret. This secret contains the configurations that the MongoDB Agent uses to start the Application Database replica set.The Kubernetes Operator creates or updates the
<om_resource_name>-db
Application Database StatefulSet. This StatefulSet contains at least three Pods.Each Pod runs one MongoDB Agent instance. Each MongoDB Agent starts a
mongod
instance on its Pod.The Kubernetes Operator mounts the
<om_resource_name>-db-config
secret to each Pod. The MongoDB Agent uses this secret to configure the Application Database replica set.In multi-cluster deployments, the Kubernetes Operator assigns the member cluster's index suffix to each Application Database's StatefulSet, in the form of
<om_resource_name>-db-<cluster-idx>
, for example:om-db-1
.
The Kubernetes Operator creates or updates the
<om_resource_name>
StatefulSet. In multi-cluster deployments, the Kubernetes Operator assigns the member cluster's index suffix to each StatefulSet, in the form of<om_resource_name>-<cluster-idx>
, for example:om-1
.The StatefulSet contains one Pod for each Ops Manager replica. Each Ops Manager replica connects to the Application Database.
Most changes to the
MongoDBOpsManager
custom resource trigger a rolling upgrade of the Pods in the<om_resource_name>
StatefulSet. Enabling TLS for the Application Database also triggers a rolling restart because the connection string to the Application Database changes. Changes tospec.backup
don't trigger a rolling upgrade.The Kubernetes Operator invokes Ops Manager APIs to create an admin user. The Kubernetes Operator saves this admin user's credentials in the
<om_resource_name>-admin-key
secret. The Kubernetes Operator uses these credentials for all other Ops Manager API invocations. This reconciliation step happens only once when you use the Kubernetes Operator to deploy a new Ops Manager resource. The Kubernetes Operator skips this step when it updates the resource.The Kubernetes Operator performs a rolling upgrade of the Pods in the
<om_resource_name>-db
Application Database StatefulSet to enable Ops Manager to monitor it. Monitoring is enabled by default. This reconciliation step happens only once, such as when you deploy a new Ops Manager resource.If
spec.backup.enabled
is true, the Kubernetes Operator creates the<om_resource_name>-backup-daemon
StatefulSet or verifies that it is running. The Backup Daemon connects to the same Application Database as the Ops Manager deployment.In multi-cluster deployments, the Kubernetes Operator assigns the member cluster's index suffix to each Backup Daemon's StatefulSet, in the form of
<om_resource_name>-backup-daemon-<cluster-idx>
, for example:om-backup-daemon-1
.If
spec.backup.enabled
is true, the Kubernetes Operator invokes Ops Manager APIs to ensure that the Ops Manager Application's backup configuration matches the one that you define in the custom resource definition.