この手順では、1つのKubernetes 演算子インストールがマネージドするMongoDB配置を、同じMongoDB Ops ManagerまたはCloud Managerプロジェクト内の2番目のKubernetes 演算子インストールに移行します。この手順は、仮想マシンから初めてKubernetesに移行する場合ではなく、名前空間間またはKubernetesクラスター間で配置を移動する場合に使用します。
この移行では、ソース配置はすでに Kubernetes Operator によってマネージドされています。オートメーション構成には Kubernetes Operator スタイルのプロセス名とホスト名が含まれています。対象は、別の名前空間またはクラスターにある 2 番目の Kubernetes 演算子のインストールです。
始める前に
2 つの Kubernetes 演算子インストール間で配置を移行する前に、以下の項目を確認してください。
MongoDB Ops Manager または Cloud Manager への接続は、キー
baseUrl、orgId、projectNameを使用してConfigMapされます。キー
publicKeyおよびprivateKeyを含む API キーSecret。Kubernetes 演算子
ServiceAccountは、ドライ実行する接続性ジョブに対してbatch/jobsの許可 (create、get、list、watch、およびdelete) を持っています。プロジェクトにはちょうど 1 つの配置が含まれています。
また、次の項目も必要です。
実行中のKubernetes演算子インストールがマネージドするソース配置。
ターゲットとしたい2番目のKubernetes演算子のインストールは、ソースとは異なる名前空間またはKubernetesクラスター内にある必要があります。
両方のインストールが、同じ MongoDB Ops Manager または Cloud Manager プロジェクトの ConfigMap および認証情報に対して構成されています。
常に 3 個以上の投票ノードを維持してください。Kubernetes 演算子は、7 個を超える投票ノードを拒否します。7 を超える場合は、投票権のない Kubernetes ノードを追加するか、投票権のある外部ノードを除いてください。
一度に行う変更は1種類だけにしてください。Kubernetesノードの追加、外部ノードの削除、または一度に1つのノードの投票数と優先順位の変更のみを行います。移行が開始されると、アドミッション検証は混合変更を拒否し、移行中のKubernetesノードを除くことや外部ノードの追加も拒否します。
配置が目標状態にあるときのみ実行します。
プライマリを最後に移行します。ノードに投票と優先順位を移行すると選挙が trigger される可能性があります。また、レプリカセットが新しいプライマリを選出する間に書き込み (write)が一時的に失敗する可能性があります。プライマリを最後に移行すると、最終ステップまでプライマリの選挙と、それが引き起こす書き込み (write)ダウンタイムをトリガーすることを回避できます。
注意
Kubernetes でノードの優先順位を上げることで、再選挙をtriggerすることも可能です。
spec.externalMembersが空でない間は、Kubernetes 演算子は 1 つのノードずつのスケーリングを強制します。このため、変更ごとには目標状態になるまで個別の待機が必要です。
バーチャル マシンから移行することとの違い
MCK から MCK への移行では、バーチャル マシン配置を移行するのと同じ拡張、プロモート、プルーン ループを使用します。ソースノードは、ターゲットリソースで spec.externalMembers として表示されます。これは、バーチャルマシンから移行する場合と同じです。このループの詳細な手順とメカニズムについては、レプリカセットを Kubernetes に移行するを参照してください。
この移行には、仮想マシンの移行には適用されない追加の要件があります。
まず、ソース演算子を停止するか、スコープを縮小してください。開始する前に、ソースKubernetes 演算子のインストールを停止するか、配置の調整を停止するようにしてください。2つの演算子が同時に同じMongoDB Ops ManagerまたはCloud Managerプロジェクトを調整してはなりません。
両方の演算子は、同じプロジェクトのConfigMapと認証情報を共有する必要があります。ソースとターゲットのKubernetes演算子のインストールは、同じOps ManagerまたはCloud Managerプロジェクトに接続します。
クラスタースコープのHelmリソース名は重複してはなりません。2つの演算子Helmインストールでは、クラスタースコープのリソースに異なる名前を使用する必要があります。
名前空間は異なる必要があります。ソースインストールとターゲットインストールで名前空間を共有していると、プロセス名が競合します。
配置を移行する
重要
続行する前に、ソース演算子を停止または範囲を縮小してください。前のセクションを参照してください。
レプリカセットを Kubernetes へ移行するに記述されている extend、promote、prune というシーケンスに従い、ターゲット Kubernetes 演算子 インストールの名前空間とクラスターでターゲット MongoDB カスタムリソースを生成します。ソースノードは、削除するまでターゲットリソース上の spec.externalMembers に表示されます。
理由 | ステータス | 意味 |
|---|---|---|
|
| ドライラン アノテーションが設定されています。 |
|
| 目的のKubernetesノード数が、最後に調整された数を超えています。 |
|
|
|
|
| 外部ノードは存在しますが、何も変わっていません。これも最初の調整時の理由です。 |
|
| すべての外部ノードが削除されました。 |
優先順位は Validating > Extending > Pruning > InProgress です。Kubernetes 側の削除と拡大の両方を行うプルーンは Extending を報告します。これもまた、変更を1つずつ行う別の理由です。
Pruningとextendingを同時に行うことはできません。
移行の完了をスクリプトで処理するには、status.phaseをポーリングするのではなく、kubectl wait --for=condition=Migrating=Falseを使用してください。
ソースのクリーンアップ
移行が完了したら、ソースのMongoDBカスタムリソースを削除します。Ops ManagerまたはCloud Managerのプロジェクトを削除しないでください。また、基礎のデータを削除しないでください。ソースのカスタムリソースを削除しても、そのリソースのソースKubernetes演算子インストールによるマネジメントのみが除かれます。