在两个 MCK 实例之间迁移

此过程将由一个 Kubernetes Operator 安装托管的 MongoDB 部署迁移到同一 Ops Manager 或 Cloud Manager 项目中的第二个 Kubernetes Operator 安装。当您将部署从一个命名空间迁移到另一个命名空间，或从一个 Kubernetes 集群迁移到另一个 Kubernetes 集群，而不是首次从虚拟机迁移到 Kubernetes 时，请使用此过程。

在此迁移中，源部署已经是 Kubernetes 操作符托管的：自动化配置包含 Kubernetes 操作符风格的进程名称和主机名称。目标是在另一个命名空间或集群中安装第二个 Kubernetes 操作符。

开始之前

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

一个 MongoDB Ops Manager 或 Cloud Manager 连接 ConfigMap，具有密钥 baseUrl、orgId 和 projectName。
一个 API 密钥 Secret 具有密钥 publicKey 和 privateKey。
Kubernetes 操作符 ServiceAccount 具有 batch/jobs 权限 (create、get、list、watch 和 delete) 用于 dry-run connectivity 作业。
该项目包含恰好一个部署。

您还需要：

正在运行的 Kubernetes 操作符安装所托管的源部署。
第二个 Kubernetes 操作符安装，您希望其成为目标，与源位于不同的命名空间或 Kubernetes 集群中。
两个安装都针对同一个 MongoDB Ops Manager 或 Cloud Manager 项目 ConfigMap 和凭证进行配置。

始终至少保持 3 个投票节点。Kubernetes 操作符拒绝超过 7 名投票节点。如果超过 7，请添加无投票权的 Kubernetes 节点，或删除具有投票权的外部节点。
一次只进行一种更改：添加 Kubernetes 节点、精简外部节点，或一次仅更改一个节点的投票和优先级。一旦迁移开始，准入验证将拒绝混合更改，并拒绝在迁移过程中删除 Kubernetes 节点或添加外部节点。
仅当部署达到目标状态时才执行操作。
最后迁移主节点 (primary node in the replica set)。将选票和优先级转移到节点上可以 trigger 一次选举，并且在副本集选举新的主节点 (primary node in the replica set)期间，写入可能会短暂失败。最后迁移主节点 (primary node in the replica set)可以避免触发该选举，以及它导致的写入停机时间，直到最后一步。

注意
您还可以通过提高 Kubernetes 中节点的优先级来 trigger 重新选举。
当 spec.externalMembers 不为空时，Kubernetes 操作符强制一个节点一次的扩展。这就是为什么每个变更都需要各自等待目标状态。

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

MCK 到 MCK 的迁移使用与迁移虚拟机部署相同的扩展、提升和剪除循环。源节点在目标资源中显示为 spec.externalMembers，这与从虚拟机迁移时的显示方式相同。有关该循环的详细步骤机制，请参阅将副本集迁移到 Kubernetes。

此迁移具有虚拟机迁移所不适用的额外要求：

首先停止或缩小源操作符的范围。在开始之前，请停止源 Kubernetes 操作符安装，或者确保它停止协调部署。绝不能有两个操作符同时协调同一个 MongoDB Ops Manager 或 Cloud Manager 项目。
两个操作符必须共享同一个项目 ConfigMap 和凭证。源 Kubernetes 操作符安装和目标 Kubernetes 操作符安装连接到同一个 Ops Manager 或 Cloud Manager 项目。
集群范围的 Helm 资源名称不得冲突。两个操作符 Helm 安装必须为任何集群范围的资源使用不同的名称。
命名空间必须不同。如果源安装和目标安装共享一个命名空间，进程名称就会发生冲突。

迁移部署

重要

在继续之前，停止或缩小源操作符的范围。请参阅上一节。

遵循在将副本集迁移到 Kubernetes 中描述的相同扩展、提升和修剪序列，对应目标 Kubernetes 操作符安装的命名空间和集群生成目标 MongoDB 自定义资源。源节点会在目标资源上的 spec.externalMembers 中显示，直到您对其进行修剪。

原因	状态	含义
`Validating`	`True`	空运行注释已设置。
`Extending`	`True`	所需的 Kubernetes 节点数超过了上次协调的计数。
`Pruning`	`True`	`externalMembers` 计数低于 `status.migrationObservedExternalMembersCount`。
`InProgress`	`True`	外部节点存在，但没有任何变化。这也是在初次协调时的原因。
`MigrationComplete`	`False`	所有外部节点均已移除。

优先级是 Validating > Extending > Pruning > InProgress。一个也会扩展 Kubernetes 侧的清理报告 Extending，这是逐步更改的另一个原因。

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

若要通过脚本实现迁移完成后的操作，请使用 kubectl wait --for=condition=Migrating=False，而不是轮询 status.phase。

清理源

迁移完成后，删除源 MongoDB 自定义资源。请勿删除 MongoDB Ops Manager 或 Cloud Manager 项目，也不要删除根本的数据。删除源自定义资源只会删除源 Kubernetes Operator 安装对该资源的管理。

了解详情