Install and Configure the Kubernetes Operator >
Upgrade the Kubernetes Operator from Prior Versions >
Migrate to One Resource per Project (Required for Version 1.3.0)

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

On this page

Prerequisites
Procedure

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.

Prerequisites¶

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

Procedure¶

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

1

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:

copy

kubectl apply -f <myconfigmap.yaml>

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

2

Update MongoDB resource objects.¶

For each MongoDB resource in the project:

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

Field	Type	Description
`spec.security.authentication`	object	Contains authentication specifications for the deployment.
`spec.security.authentication.enabled`	boolean	Specifies whether authentication is enabled for the deployment. Set this value to `true`.
`spec.security.authentication.modes`	array	Specifies supported authentication mechanisms for the deployment. Set this value to `["X509"]`

If internal cluster authentication is enabled, set spec.security.authentication.internalCluster to X509.
Add the spec.opsManager.configMapRef.name field to the Kubernetes object and set the value to the metadata.name value of the corresponding ConfigMap you created in step 1.
Remove the spec.project field from the resource object.
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.
copy
```
kubectl apply -f <configuration>.yaml
```

3

Update MongoDB user objects.¶

For each MongoDB user resource:

Remove the spec.project field.
Add the spec.mongodbResourceRef.name field and set the value to the name of the relevant MongoDB resource in the same namespace.

Note

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

4

Delete the original project ConfigMap.¶

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

copy

kubectl delete -f <configMap>.yaml

5

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

Important

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.