2 つの MCK インスタンス間での移行

始める前に

Kubernetes Operator の 2 つのインストール間で配置を移行する前に、次の点を確認してください。

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

• プロジェクトには 1 つの配置が含まれています。

また、次のコマンドも必要です。

• 実行中のKubernetes Operator インストールが管理するソース配置。

• ソースとは異なる名前空間またはKubernetesクラスターで、ターゲットになる 2 つ目のKubernetes Operator インストール。

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

• 常に少なくとも 3 の投票ノードを保持します。 Kubernetes Operator は 7 を超える投票メンバーを拒否します。 7 を超える場合は、投票権のないKubernetesノードを追加するか、投票権のある外部ノードを削除します。

• 一度に 1 種類の変更のみを行います。Kubernetes ノードを追加する、外部ノードをプルーニングする、または一度に 1 つのノードのみの投票と優先順位を変更します。認証検証は、移行が開始されると混合変更を拒否し、 Kubernetesノードの削除や移行中の外部ノードの追加も拒否します。

• 配置が目的の状態にある場合にのみ実行します。

• 最後にプライマリを移行します。投票と優先順位をノードに付与すると選挙 がトリガーされ、レプリカセットが新しいプライマリを選択している間に書込み (write) が一時的に失敗することがあります。プライマリを最後に移行すると、最後のステップまで、その選挙とそれによって発生する 書込み (write) ダウンタイムがトリガーされないようにできます。

  注意

  また、 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リソース名は重複してはなりません。 2 つの演算子 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

• レプリカセットのKubernetesへの移行