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