This version of the documentation is archived and no longer supported. To learn how to upgrade your version of MongoDB Kubernetes Operator, refer to the upgrade documentation.

Migrate to One Resource per Project (Required for Version 1.3.0)

On this page

Starting in MongoDB Enterprise Kubernetes Operator version 1.3.0, you can only have one MongoDB resource per project. This document explains how to migrate existing projects which have multiple MongoDB resources into configurations with a single resource per project.


Before completing this procedure, ensure that you have upgraded your MongoDB Enterprise Kubernetes Operator to version 1.3.0. For upgrade instructions, see Upgrade the Operator.


Complete the following steps for each project that contains multiple MongoDB resources:


Create a new ConfigMap for each MongoDB resource in the project.

To associate each MongoDB resource with a single project, each resource must have a distinct ConfigMap. The new ConfigMaps:

  • Must have unique projectName fields.
  • Cannot contain the credentials or authenticationMode fields.

All other fields can remain the same as the original project ConfigMap. Invoke the following command for each ConfigMap to apply them to Cloud Manager or Ops Manager:

kubectl apply -f <myconfigmap.yaml>

To learn more about creating a project using a ConfigMap, see Create a Project using a ConfigMap.


Update MongoDB resource objects.

For each MongoDB resource in the project:

  1. If X.509 authentication is enabled, add the following fields to the Kubernetes object:

    Field Type Description object Contains authentication specifications for the deployment. boolean Specifies whether authentication is enabled for the deployment. Set this value to true. array Specifies supported authentication mechanisms for the deployment. Set this value to ["X509"]
  2. If internal cluster authentication is enabled, set to X509.

  3. Add the field to the Kubernetes object and set the value to the value of the corresponding ConfigMap you created in step 1.

  4. Remove the spec.project field from the resource object.

  5. Invoke the following command for each resource object to apply the updated configuration(s). When you apply a new configuration, the Operator creates a new project in Cloud Manager or Ops Manager containing the deployment from the corresponding MongoDB resource. All data on the resource database remains the same after the migration.

    kubectl apply -f <configuration>.yaml

Update MongoDB user objects.

For each MongoDB user resource:

  1. Remove the spec.project field.

  2. Add the field and set the value to the name of the relevant MongoDB resource in the same namespace.


    This may require duplicating your MongoDBUser resource if you wish to have the same user in multiple clusters.


Delete the original project ConfigMap.

Invoke the following command to delete the original project ConfigMap from your Kubernetes namespace:

kubectl delete -f <configMap>.yaml

(Optional) Remove Orphaned Clusters from Cloud Manager or Ops Manager.


Removing clusters will delete their historical backups and monitoring data.

After reconfiguring your deployments to exist in dedicated clusters, you may have clusters remaining in the original project which are no longer managed by the Kubernetes Operator. You can remove these clusters if you wish.