在两个 MCK 实例之间迁移

开始之前

在两个Kubernetes Operator 安装之间迁移部署之前，请确认以下内容：

• 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.

• 该项目只包含一个部署。

您还需要：

• 运行的Kubernetes Operator 安装管理的源部署。

• 您希望成为目标的第二个Kubernetes Operator 安装，位于与源不同的命名空间或Kubernetes集群中。

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

• 始终至少保留 3 个有投票权的节点。 Kubernetes Operator 拒绝了超过 7 个投票节点。如果超过 7，请添加无投票权的Kubernetes成员或删除有投票权的外部成员。

• 一次仅进行一种更改：添加Kubernetes节点、修剪外部节点或一次仅更改一个节点的投票和优先级。迁移开始后，准入验证会拒绝混合更改，也会拒绝在迁移过程中删除Kubernetes成员或添加外部成员。

• 仅当部署处于目标状态时才采取行动。

• 最后迁移主节点 (primary node in the replica set)。将投票和优先级转移到节点上可能会触发选举，并且在副本集选举新的主节点 (primary node in the replica set)时，写入可能会短暂失败。最后迁移主节点 (primary node in the replica set)可避免触发该选举及其导致的写入停机时间，直到最后一步。

  注意

  您还可以通过提高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.

这与从虚拟机迁移有何不同

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.

此迁移具有不适应用虚拟机迁移的其他要求：

• 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.

• 集群范围的 Helm资源名称不得冲突。两个 Helm 操作符安装必须对任何集群范围的资源使用不同的名称。

• 命名空间必须不同。如果源安装和目标安装共享命名空间，进程名称会发生冲突。

迁移部署

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.

不允许同时进行剪枝和扩展。

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

清理源代码

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.

了解详情

• Migrate a Self-Managed Deployment to Kubernetes

• Migrate a Replica Set to Kubernetes