Kubernetes Operator は、Ops Manager またはCloud Manager が仮想マシンまたは必要最低限のクラスタで管理する配置をKubernetesに移行できます。移行はライブで増分されます。配置は プロセス全体で読み取りと書込みを処理し続けます。通常のMongoDBレプリケーションを使用して、仮想マシンから一度に 1 つずつメンバーをKubernetesに移動します。
移行の仕組み
移行は、データ コピー ツールではなく、標準のMongoDBレプリケーションに依存します。これは 3 つのフェーズで進みます。
拡張。既存のレプリカセットにKubernetesメンバーを追加します。 Kubernetes Operator は新しいノードを非投票権として作成し、既存のノードから最初の同期を実行します。
昇格。投票と優先順位を仮想マシン メンバーからKubernetesメンバーに移行します。外部ノードは、ソースオートメーション構成にすでに持っている投票と優先順位を、削除するまで保持します。
プルーニング。仮想マシン ノードを一度に 1 つずつ削除し、削除ごとにレプリカセットが目的の状態に達するまで待ちます。
Kubernetes Operator がメンバーの 100% を管理し、spec.externalMembers が空で、すべてのデータがKubernetes永続ボリューム要求にある場合、移行は完了します。その点で 、仮想マシン上にノードは残りません。
移行でスナップショット復元またはCluster-to-Cluster Syncが使用されない理由
移行ワークフローではスナップショットは復元されず、mongosync やその他のクラスター間同期ツールは使用されません。クラスター間同期ツールは、カットオーバー時にダウンタイムを課し、時系列コレクションをサポートしていないため、安全に実行するにはフィールドのヘルプ が必要です。レプリケーションベースの移行、これらの制限を回避します。配置は引き続き利用可能であり、移行は配置の残りの部分と同じコレクションタイプをサポートし、このプロセスは kubectl mongodbプラグインを使用して自分で実行します。
移行中の可用性
移行を通じて読み取りは引き続き利用できます。選挙中に書き込みが一時的に失敗する可能性があるため、ドライバーは再試行可能な書き込みを使用する必要があります。読み取りターゲットが移動すると読み取りレイテンシが増加する可能性があるため、仮想マシンと同じリージョンでKubernetesクラスターを実行します。休止モードがないため、移行されたセカンダリ ブレークに対して長時間実行されているカーソル。
ハイブリッド操作は一時的
移行の進行中は、配置が仮想マシンとKubernetesに分裂ノードでハイブリッド状態で実行されます。 Kubernetes Operator は、 アクティブな移行中に一時的な条件としてのみこのハイブリッド状態をサポートします。移行には、一定期間、2 つの環境間の永続的な双方向ネットワーク接続が必要です。 Kubernetes Operator は、分割された環境配置の無期限の実行中をサポートしていません。
移行で行われない操作
Kubernetes Operator は、次の操作を実行しません。
仮想マシンを廃止します。移行が完了した後に、自分で廃止します。
移行をロールバックします。一度移行を開始すると、元に戻すための自動方法は存在しません。
データをシードまたは事前にコピーします。すべてのデータ移動はMongoDBレプリケーションを通じて行われます。
Ops Manager またはCloud Manager自体を移行します。 MongoDBデプロイのみがKubernetesに移動されます。