この手順では、Ops ManagerまたはCloud Managerが管理するレプリカセットを、通常のMongoDBレプリケーションを使用して、Kubernetes 演算子の下でKubernetesに移行します。これには、仮想マシンやベアメタルで実行されている配置や、別のKubernetes演算子インスタンスによって既にマネージドされている配置が含まれます。移行はライブかつ段階的に行われます。レプリカセットをKubernetesに拡張し、Kubernetesノードを昇格させてから、外部ノードを削除します。スナップショットの復元やmongosyncは必要ありません。
始める前に
レプリカセットを移行する前に、以下を確認してください。
MongoDB Ops Manager または Cloud Manager への接続は、キー
baseUrl、orgId、projectNameを使用してConfigMapされます。キー
publicKeyおよびprivateKeyを含む API キーSecret。Kubernetes 演算子
ServiceAccountは、ドライ実行する接続性ジョブに対してbatch/jobsの許可 (create、get、list、watch、およびdelete) を持っています。プロジェクトにはちょうど 1 つの配置が含まれています。
また、次の項目も必要です。
MongoDB Ops Manager または Cloud Manager がマネージドする既存のレプリカセット。
MongoDB Ops Manager または Cloud Manager プロジェクト内の配置は 1 つだけです。
Kubernetes 演算子がインストールされている Kubernetes クラスター。
Kubernetes 演算子のバージョンに合わせた
kubectl mongodbプラグイン。Kubernetes 演算子は、ドライ実行を含むリコンシルごとにこのマッチを強制します。仮想マシンホストとKubernetes Pod間の双方向ネットワーク接続とホスト名解決。
配置でTLSを使用している場合、すべてのSANをカバーする事前設定済みのTLS証明書。
SCRAMユーザーパスワードが手元にある状態。オートメーション設定から復元することはできません。
開始前に取られたバックアップ。
正常で目標状態にある配置。
常に 3 個以上の投票ノードを維持してください。Kubernetes 演算子は、7 個を超える投票ノードを拒否します。7 を超える場合は、投票権のない Kubernetes ノードを追加するか、投票権のある外部ノードを除いてください。
一度に行う変更は1種類だけにしてください。Kubernetesノードの追加、外部ノードの削除、または一度に1つのノードの投票数と優先順位の変更のみを行います。移行が開始されると、アドミッション検証は混合変更を拒否し、移行中のKubernetesノードを除くことや外部ノードの追加も拒否します。
配置が目標状態にあるときのみ実行します。
プライマリを最後に移行します。ノードに投票と優先順位を移行すると選挙が trigger される可能性があります。また、レプリカセットが新しいプライマリを選出する間に書き込み (write)が一時的に失敗する可能性があります。プライマリを最後に移行すると、最終ステップまでプライマリの選挙と、それが引き起こす書き込み (write)ダウンタイムをトリガーすることを回避できます。
注意
Kubernetes でノードの優先順位を上げることで、再選挙をtriggerすることも可能です。
spec.externalMembersが空でない間は、Kubernetes 演算子は 1 つのノードずつのスケーリングを強制します。このため、変更ごとには目標状態になるまで個別の待機が必要です。
手順
MongoDB カスタム リソースを生成します。
kubectl mongodb migrate-to-mck mongodbコマンドを実行します。
kubectl mongodb migrate-to-mck mongodb \ --config-map-name <configmap> \ --secret-name <secret> \ --namespace <namespace> \ -o mongodb-cr.yaml生成されたファイルを確認します。内容は以下の通りです。
spec.externalMembers, ソース プロセスをリストしています。spec.members0に設定します。プラグインが常に追加する
mongodb.com/migration-dry-run: trueアノテーション。
コマンドは、以下の任意フラグもサポートしています。
--certs-secret-prefixTLSが有効な場合に必須です。spec.security.certsSecretPrefixを設定します。--prometheus-secret-namePrometheusが有効な場合に使用します。Secretは既に存在し、passwordキーを持っている必要があります。--resource-name-override: 生成されたリソースにmetadata.nameを設定します。プラグインは、レプリカセット名が有効な Kubernetes 名ではない場合に自動的に正規化し、spec.replicaSetNameOverrideを設定します。
MongoDBUserカスタムリソースを生成します。
この手順は、データベースユーザーを移行する場合にのみ実行してください。移行に必須ではありません。
SCRAMユーザーごとにSecretを1つずつ事前作成し、それぞれにpasswordキーを設定します。実行する:
kubectl mongodb migrate-to-mck users \ --config-map-name <configmap> \ --secret-name <secret> \ --namespace <namespace> \ --users-secrets-file users.csv \ -o users-cr.yamlCSV ファイルは、1 行に 1 つの形式 username:database,secret-name でユーザーを Secrets にマップします。--users-secrets-file を省略すると、代わりにユーザーごとにプロンプトが表示されます。
プラグインは、X.509 と LDAP ユーザーを $external データベースに対して生成します。オートメーションエージェントユーザーをスキップします。
配置でTLSを使用する場合は、Kubernetesノード証明書を発行します。
仮想マシンの証明書に署名した認証局と同じ認証局から、Kubernetesのノード証明書を発行します。
Kubernetes 演算子は、"<certsSecretPrefix>-<resourceName>-cert" という名前の kubernetes.io/tls Secret と、ca-pem キーと mms-ca.crt キーの両方を含む "<resourceName>-ca" という名前の CA ConfigMap を必要とします。証明書には、Pod ごとの DNS 名とサービス DNS 名、およびサーバー認証とクライアント認証の両方の使用をカバーする SAN が必要です。
ソース配置でTLSを使用していない場合は、移行する前に、既存の仮想マシン配置上の Ops Manager または Cloud Manager で net.tls.mode を disabled に設定してください。この場合、MongoDBカスタムリソースに何も設定する必要はありません。
注意
CA の不一致は、次のステップでのドライ実行するによって設計上捕捉されます。
外部アクセスを設定します。
ドライ実行するを実行する前に、spec.externalAccess を設定して、バーチャル マシン ノードが Kubernetes Pods にアクセスできるようにします。これらのノードがホスト名で Pod を解決できるようにするには、spec.externalAccess.externalDomain を設定することもできます。関与するフィールドと DNS 要件について学ぶには、移行のネットワーク要件を参照してください。
この設定はユーザーが所有します。環境に合わせてLoadBalancerやNodePort、DNSレコードを構成してください。
重要
この配置で MongoDB Search またはベクトル検索を使用する場合は、externalDomain を設定しないでください。MongoDBSearch は externalDomain を設定する MongoDB リソースをサポートしておらず、クラスター作成後にフィールドを除くことはできません。詳細については、「MongoDB Search と移行のインタラクション」を参照してください。
ドライランを実行し、接続を確認します。
mongodb.com/migration-dry-run アノテーションが残っている状態で、生成されたリソースを適用します。アノテーションが設定されている間、Kubernetes 演算子はオートメーション構成の変更を行わず、接続の検証のみを行います。
Kubernetes 演算子は<resourceName>-connectivity-checkという名前のジョブを作成し、すべての外部ノードにダイヤルして認証を行います。ジョブはttlSecondsAfterFinishedを使用して自身を削除し、次の調整で再作成されるため、検証は自動的に行われます。KubernetesまたはMongoDB Ops Manager UIで問題を修正し、自由に再実行できます。
ドライランでは、Kubernetesから仮想マシンへの到達可能性（DNS、TLS、ファイアウォール、ノードアドレス）と認証情報（localデータベースの__systemロールを含む）、およびTLSが有効な場合のCAがチェックされます。仮想マシンからKubernetesへのインバウンド接続はチェックされません。
その方向性は完全にネットワークの設定に依存するため、単一のコマンドで保証することはできません。代わりに、このチェックリストを確認してください。
<metadata.name>-0.<spec.externalAccess.externalDomain>のパスワードなしに従って Kubernetes ノードが持つホスト名が、バーチャル マシン ノードから解決可能であることを確認します。KubernetesノードまたはLoadBalancerのIPアドレスに、仮想マシンから到達できることを確認します。
status.conditions[type=NetworkConnectivityVerified] から結果を読み取る:
バリデーター ジョブ 終了コード | 条件ステータス | 理由 | 意味 |
|---|---|---|---|
ジョブが実行中です |
|
|
|
|
|
| すべての外部ノードは到達可能であり認証済みです。 |
|
|
| 認証情報、認証メカニズム、または不足している |
|
|
| DNS、TLS、タイムアウト、または到達不能なノード。ジョブPodのログを確認します。 |
|
|
| 未分類の障害。ジョブ Pod ログを確認する。 |
ジョブの開始前に発生する失敗は、OperatorImageUnknown、BuildStatefulSetOptions、AgentCertSecretFailed、AgentCertSubject の理由を使用します。
Kubernetes 演算子は、外部ノードがなくなると、status.conditions から NetworkConnectivityVerified 状態を完全に除きます。
レプリカセットを Kubernetes に拡張する。
dry-run 注釈を除く:
kubectl annotate mdb <resourceName> \ mongodb.com/migration-dry-run-この時点で、Kubernetes 演算子がOps Managerプロジェクトの所有権を取得します。
spec.members を発生させ、spec.memberConfig を手動で書き込み (write) します。
警告
spec.memberConfig を設定するノード数を増やす前に
デフォルトでは、新しい Kubernetes ノードは投票ノードとして参加します。CRD デフォルトは votes: 1 と priority: "1" です。これらのデフォルトにより、同期中のノードは最初の同期が完了する前に選挙に参加できます。
MongoDB は、ノード数を増やす前に、votes: 0 と priority: "0" を使用して、新しい Kubernetes ノードごとに spec.memberConfig エントリを 1 つ書き込み (write)することを推奨します。これにより、まだ同期中のノードが選挙に勝つことができなくなります。votes は整数です。priority は string です。
例として、3つのKubernetesノードを投票権なしで追加するには、次のようにします。
spec: memberConfig: - votes: 0 priority: "0" - votes: 0 priority: "0" - votes: 0 priority: "0"完全な最初の同期と目標状態を待ちます。上記の任意の手順で MongoDBUser リソースを生成した場合は、今すぐ適用し、それぞれが Updated の status.phase に達していることを確認してください。
外部のノードを削除します。
重要
spec.externalMembers からは一度に 1 エントリーのみ除くことができます。各項目を除くした後、目標状態になるのを待ってから、次の項目を除くしてください。
以下に例を挙げます。
kubectl patch mdb <resourceName> --type=json \ -p='[{"op":"remove","path":"/spec/externalMembers/0"}]'移行開始後は、エントリを除くことはできますが、追加することはできません。
status.conditions[type=Migrating].reason が Extending、InProgress、Pruning を通って動くのを見る：
理由 | ステータス | 意味 |
|---|---|---|
|
| ドライラン アノテーションが設定されています。 |
|
| 目的のKubernetesノード数が、最後に調整された数を超えています。 |
|
|
|
|
| 外部ノードは存在しますが、何も変わっていません。これも最初の調整時の理由です。 |
|
| すべての外部ノードが削除されました。 |
優先順位は Validating > Extending > Pruning > InProgress です。Kubernetes 側の削除と拡大の両方を行うプルーンは Extending を報告します。これもまた、変更を1つずつ行う別の理由です。
Pruningとextendingを同時に行うことはできません。
移行の完了をスクリプトで処理するには、status.phaseをポーリングするのではなく、kubectl wait --for=condition=Migrating=Falseを使用してください。
接続文字列シークレット
Kubernetes 演算子は、認証情報を含まない接続文字列 Secret を <metadata.name>-cluster-connection-string という名前で自動的に生成し、アクティブ ノードと同期させます。接続文字列をハードコードするのではなく、アプリケーションをこの Secret に向けてください。
移行中の可用性
移行中はずっと読み取りが利用可能です。選挙中に書き込み (write)が一時的に失敗する可能性があります。そのため、ドライバーは再試行可能な書き込みを使用する必要があります。読み取り対象が移動すると、読み取りレイテンシが増加する可能性があります。そのため、Kubernetes クラスターをバーチャル マシンと同じリージョン内で実行します。移行されたセカンダリに対する長時間カーソルは、クイエッス モードがないため、切断されます。