MongoDB Database Architecture in Kubernetes

Standalone

For the Standalone type of the MongoDB database resource, the Kubernetes Operator deploys a replica set with a single member to the Kubernetes cluster as a StatefulSet.

The Kubernetes Operator creates the StatefulSet, which contains the Pod specification with the number of Pods to create. The Kubernetes Operator relies on the Kubernetes StatefulSet Controller to create a Pod for this standalone MongoDB database instance.

Replica Set

For the ReplicaSet type of the MongoDB resource, the Kubernetes Operator deploys a replica set to the Kubernetes cluster as a StatefulSet, with a number of members equal to the value of spec.members.

The Kubernetes Operator relies on the Kubernetes StatefulSet Controller to create one Pod in the StatefulSet for each member of the replica set.

Each Pod in the StatefulSet runs a MongoDB Agent instance.

Sharded Cluster

The ShardedCluster type of the MongoDB resource consists of one or more Config Servers, mongos instances, and shard members.

For the ShardedCluster resource, the Kubernetes Operator deploys:

• One StatefulSet for all Config Servers

• One StatefulSet for all mongos instances

• One StatefulSet for each Shard Member

The Kubernetes Operator relies on the Kubernetes StatefulSet Controller to create one Pod in each of the StatefulSets created for the sharded cluster.

Diagram of a Replica Set Reconciliation

The following diagram describes how the Kubernetes Operator behaves if you make changes to a replica set's:

• MongoDB custom resource specifications

• Associated ConfigMap

• Associated secrets stored in your secret storage tool

click to enlarge

Diagram of a Sharded Cluster Reconciliation

The following diagram describes how the Kubernetes Operator behaves if you make changes to a sharded cluster's:

• MongoDB custom resource specifications

• Associated ConfigMap

• Associated secrets stored in your secret storage tool

click to enlarge

Reconciliation Workflow

When you create or change a MongoDB resource specification, or when you make changes to an associated ConfigMap or secret, the Kubernetes Operator performs the following actions to reconcile the changes:

1. Reads the required organization and project configuration from the ConfigMap that you used to create or connect to a project in the Kubernetes Operator.

   If you change your resource specification, the Kubernetes Operator identifies that the change took place, and checks the specification for the ConfigMap specified in spec.opsManager.configMapRef.name.

   Note

   When you configure the Kubernetes Operator for MongoDB resources, you create a ConfigMap to connect or create your Cloud Manager or Ops Manager project. The MongoDB Agent uses this ConfigMap to start or make changes to the deployment for the MongoDB resource.

2. Reads the authentication configuration for Cloud Manager or Ops Manager from the secret specified in either:

   • spec.credentials in the resource specification

   • Your secret storage tool

   This secret stores the Cloud Manager API keys or the Ops Manager API Keys required for the Kubernetes Operator to authenticate to Cloud Manager or Ops Manager.

   Note

   When you configure the Kubernetes Operator for MongoDB resources, you either create this secret in Kubernetes or store this secret in your secret storage tool.

3. The Kubernetes Operator connects to Cloud Manager or Ops Manager and performs the following actions:

   • Reads the organization from the orgId field in the ConfigMap. You must provide a value in the orgId field.

   • Reads a project name specified in the projectName field in the ConfigMap, or, if you didn't specify a value for this optional field, creates this project in Cloud Manager or Ops Manager if it doesn't exist.

   • Checks that the <project-id>-group-secret secret created by the Kubernetes Operator for the MongoDB Agent exists. The Kubernetes Operator reads the secret from your secret storage tool, or creates it with Ops Manager API keys or Cloud Manager API keys.

   • Registers itself as a watcher of the ConfigMap and this secret. This enables the Kubernetes Operator to react to changes that you make to the ConfigMap or the secret.

4. The Kubernetes Operator verifies any TLS and X.509 certificates.

   • If TLS is enabled for a replica set, the Kubernetes Operator looks for certificates provided in the <prefix>-<resource-name>-cert secret or your secret storage tool.

   • If TLS is enabled for a sharded cluster, the Kubernetes Operator looks for certificates in these secrets:

     • <prefix>-<resource-name>-x-cert for each shard member.

     • <prefix>-<resource-name>-config-cert for all config servers.

     • <prefix>-<resource-name>-mongos-cert for all mongos instances.

     • Your secret storage tool.

   • If X.509 or internal authentication with X.509 and TLS are enabled, the Kubernetes Operator checks that their certificates contain the required configuration.

5. The Kubernetes Operator locates and updates the necessary StatefulSets, or creates new StatefulSets if they don't exist. The number of StatefulSets depends on the type of the MongoDB resource.

   • For ReplicaSet or Standalone resources, the Kubernetes Operator creates a single StatefulSet.

   • For a ShardedCluster resource, the Kubernetes Operator creates:

     • One StatefulSet for all config servers.

     • One StatefulSet for all mongos instances.

     • One StatefulSet for each shard member.

     At this point, each Pod runs at least one MongoDB Agent instance, but does not yet contain mongod instances.

   • Each MongoDB Agent instance starts polling Cloud Manager or Ops Manager to receive the MongoDB automation configuration.

     Note

     Non-static containers: When the MongoDB Agent receives the configuration for the first time, it downloads the MongoDB binaries with the version specified in spec.version from the Internet, or from Ops Manager if the MongoDB Agent is configured in local mode.

     Static containers: Static containers do not download binaries at runtime. To learn more, see Static Containers (Public Preview).

   • After the MongoDB Agent receives the automation configuration, it starts a mongod instance on the corresponding Pod.

   • For each Pod of each StatefulSet that the MongoDB custom resource creates, except for mongos StatefulSets, the Kubernetes Operator generates a Persistent Volume Claim. You can override this behavior by setting spec.persistent to false in the resource specification.

6. The Kubernetes Operator updates the automation configuration it received from the MongoDB Agent with changes from the specifications and sends it to Cloud Manager or Ops Manager.

   • Each MongoDB Agent for each Pod polls Cloud Manager or Ops Manager again and receives the updated automation configuration.

   • If you change any field in the specification, the Kubernetes Operator performs a rolling update of the StatefulSets to start new Pods matching the new specification.

   • The Kubernetes Operator waits for each MongoDB Agent to report that it reached the ready state.

   Note

   If you change the security configuration of a database resource, or scale down an existing StatefulSet, the Kubernetes Operator runs step 6 before it runs step 5.

7. The Kubernetes Operator updates the Kubernetes services, or for a new MongoDB resource, creates the services required for each new StatefulSet.

   For the ServiceType ClusterIP, the Kubernetes Operator sets ClusterIP to None, and performs these actions:

   • Creates this service if it doesn't exist.

   • For ReplicaSet or Standalone resources, the Kubernetes Operator names the service with the custom resource's name with -svc appended to it.

   • For a ShardedCluster resource, the Kubernetes Operator uses these naming conventions:

     • For mongos instances, the Kubernetes Operator uses the name specified in spec.service, or the resource's name with -svc appended to it.

     • For the config servers, the Kubernetes Operator uses the resource's name with -cs appended to it.

     • For each shard, the Kubernetes Operator uses the resource's name with -sh appended to it.

   • For the port, the Kubernetes Operator uses the default port 27017, or the .net.port specified in spec.additionalMongodConfig.