Migrate Between Two MCK Instances

Before you Begin

Confirm the following before you migrate a deployment between two Kubernetes Operator installations:

• A Ops Manager or Cloud Manager connection ConfigMap with the keys baseUrl, orgId, and projectName.

• An API key Secret with the keys publicKey and privateKey.

• The Kubernetes Operator ServiceAccount has batch/jobs permissions (create, get, list, watch, and delete) for the dry-run connectivity Job.

• The project contains exactly one deployment.

You also need:

• A source deployment that a running Kubernetes Operator installation manages.

• A second Kubernetes Operator installation that you want to become the target, in a different namespace or Kubernetes cluster than the source.

• Both installations configured against the same Ops Manager or Cloud Manager project ConfigMap and credentials.

• Keep at least 3 voting members at all times. Kubernetes Operator rejects more than 7 voting members. If you exceed 7, add non-voting Kubernetes members or remove voting external members.

• Make only one kind of change at a time: add Kubernetes members, prune external members, or change the votes and priority of only one member at a time. Admission validation rejects mixed changes once migration has started, and also rejects removing Kubernetes members or adding external members mid-migration.

• Act only when the deployment is at goal state.

• Migrate the primary last. Shifting votes and priority onto a member can trigger an election, and writes can briefly fail while the replica set elects a new primary. Migrating the primary last avoids triggering that election, and the write downtime it causes, until the final step.

  Note

  You can also trigger a re-election by increasing the priority of a member in Kubernetes.

• While spec.externalMembers is non-empty, Kubernetes Operator forces one-member-at-a-time scaling. This is why each change needs its own wait for goal state.

How This Differs from Migrating from Virtual Machines

An MCK-to-MCK migration uses the same extend, promote, and prune loop as migrating a virtual machine deployment. Source members appear as spec.externalMembers in the target resource, the same as they do when migrating from virtual machines. For the detailed step-by-step mechanics of that loop, see Migrate a Replica Set to Kubernetes.

This migration has additional requirements that do not apply to a virtual-machine migration:

• Stop or scope down the source operator first. Before you begin, stop the source Kubernetes Operator installation, or otherwise ensure it stops reconciling the deployment. Two operators must never reconcile the same Ops Manager or Cloud Manager project at the same time.

• Both operators must share the same project ConfigMap and credentials. The source and target Kubernetes Operator installations connect to the same Ops Manager or Cloud Manager project.

• Cluster-scoped Helm resource names must not collide. The two operator Helm installations must use distinct names for any cluster-scoped resource.

• The namespaces must differ. If the source and target installations shared a namespace, process names would collide.

Migrate the Deployment

Follow the same extend, promote, and prune sequence described in Migrate a Replica Set to Kubernetes, generating the target MongoDB custom resource against the target Kubernetes Operator installation's namespace and cluster. The source members appear in spec.externalMembers on the target resource until you prune them.

Precedence is Validating > Extending > Pruning > InProgress. A prune that also grows the Kubernetes side reports Extending, which is another reason to make one change at a time.

Pruning and extending are not allowed at the same time.

To script against migration completion, use kubectl wait --for=condition=Migrating=False rather than polling status.phase.

Clean Up the Source

After migration finishes, delete the source MongoDB custom resource. Do not delete the Ops Manager or Cloud Manager project, and do not delete the underlying data. Deleting the source custom resource removes only the source Kubernetes Operator installation's management of that resource.

Learn More

• Migrate a Self-Managed Deployment to Kubernetes

• Migrate a Replica Set to Kubernetes