Review the limitations in this page before you plan a migration of a self-managed deployment into Kubernetes. Some limitations block migration entirely, and others require you to plan around missing capabilities.
One Deployment Per Project
The Ops Manager or Cloud Manager project must contain exactly one deployment. The kubectl mongodb plugin errors out if the project contains more than one deployment.
If your project contains multiple deployments, split them into separate projects before you migrate. To learn how, see Migrate a MongoDB Deployment to a New Project in the Ops Manager documentation.
Embedded Config Servers Are Unsupported
A sharded cluster whose config server is also backed by one of its shards cannot be migrated. Kubernetes Operator detects an embedded config server and rejects the migration at import.
Inbound Connectivity Is Not Auto-Verified
The dry run validates connectivity from Kubernetes to the virtual machines only. It does not check virtual-machine-to-Kubernetes inbound connectivity automatically. Verify that direction of connectivity yourself before you rely on it.
No Automatic Rollback
No automated way exists to reverse a migration after it starts. Plan your migration and take a backup before you begin, because you cannot revert through the plugin or the operator.
To manually roll back a migration in progress:
Reconcile the automation config back to its state before migration.
Edit the automation config directly in Ops Manager or Cloud Manager.
Warning
If you delete the MongoDB resource while Kubernetes Operator is still running, Kubernetes Operator does not delete the project in Ops Manager or Cloud Manager, to protect the external members. However, Kubernetes Operator automatically deletes the StatefulSets and Pods for that resource. Depending on how far the migration has progressed, deleting these Pods can cause the replica set to lose its voting majority.
No Seeding or Pre-Copy
Migration moves data by MongoDB replication only. Kubernetes Operator does not seed or pre-copy data into the new Kubernetes members through any other mechanism.
No Automated Prune
Removing external members is a manual operation. You remove entries from spec.externalMembers one at a time. The operator does not automate this step for you.
Ops Manager Itself Is Not Migrated
This workflow migrates only the MongoDB deployment that Ops Manager or Cloud Manager manages. It does not migrate Ops Manager or Cloud Manager itself.
Configuration Freeze during Migration
While a migration is in progress, do not make version or configuration changes to the deployment outside the migration steps. Concurrent edits through the Ops Manager UI are also unsupported during migration.
Some fields are expected to change as part of the migration itself:
- Member counts and the
votesandpriorityfields inmemberConfigchange as you extend, promote, and prune members.
Other settings must match the source deployment throughout migration and must not change:
MongoDB version
Feature compatibility version
Port
Authentication modes
Internal cluster authentication
Settings That Do Not Carry Over to New Members
Plan for these settings before you migrate, because Kubernetes Operator does not reproduce them on the new Kubernetes members:
secondaryDelaySecson a delayed member.The hidden setting on a hidden member.
buildIndexesset tofalseon a member.
If you run analytics nodes or delayed nodes on virtual machines, reconfigure the equivalent settings on the Kubernetes members yourself, after they join the replica set.
Not Supported on MongoDBMultiCluster
Kubernetes Operator does not support migration on MongoDBMultiCluster resource. The spec.externalMembers field was deliberately not added to that CRD. No MongoDBProject CRD exists.