この手順では、Ops ManagerまたはCloud Managerがマネージドするクラスターを、レプリカセットをKubernetesに移行する場合と同じライブの増分拡張・昇格・削除ワークフローを使用して、Kubernetes 演算子の下でKubernetesに移行します。その手順に従い、このページで説明されている相違点を適用してください。このページに記載されていない手順については、レプリカセットの手順と同じです。
重要
シャーディングされたクラスターで、埋め込みのコンフィギュレーションサーバーを使用したものはサポートされていません。Kubernetes 演算子はこのトポロジーを検出し、インポートを拒否します。
外部ノードはすべてのコンポーネントをカバーします
シャーディングされたクラスターの場合、spec.externalMembers は、コンフィギュレーションサーバーの mongod、各シャードの mongod、および mongos ルーターというすべてのプロセスを網羅する単一のフラットなリストです。すべてのエントリで spec.externalMembers[].type が設定され、すべての mongod エントリでも spec.externalMembers[].replicaSetName が設定され、プロセスがコンフィギュレーションサーバーのレプリカセットに属しているか、特定のシャードのレプリカセットに属しているかが識別されます。完全なフィールドリファレンスについては、MongoDB 移行リソース Settings を参照してください。
名前のオーバーライドは、オートメーション構成名を保持します
kubectl mongodb migrate-to-mck プラグインは `spec.configServerNameOverride` と `spec.shardNameOverrides` を設定し、Kubernetes 演算子が新しいレプリカセットを作成するのではなく、既存のコンフィギュレーションサーバーとシャードレプリカセットを拡張するようにします。プラグインは、Kubernetes 側のノード数を 0 にまた設定します。
均一に拡張するか、シャードごとに拡張するか
シャーディングされたクラスターを Kubernetes に拡張するには、次の 2 つの方法があります。
均一に、コンポーネントごとのカウント
spec.mongodsPerShardCount、spec.configServerCount、およびspec.mongosCountを増やすことによって。すべてのシャードが同じ数のKubernetesノードを受け取る場合に使用します。spec.shardOverridesシャードごとに、シャードを名前付けし、そのノード数を設定する エントリを使用します。これは、シャードのサイズが異なる場合、シャードをシャードごとに移行する場合、またはシャードに独自のノード 配置が必要な場合に使用します。注意
spec.shardOverrides(シャード単位の構成) とspec.shardNameOverrides(オートメーション構成レプリカセット名前付け) を混同しないでください。両設定は無関係です。
レプリカセットの手順と同様に、関連するコンポーネントの新しいKubernetesノードごとにmemberConfigを手動で書き込み (write)、その数を増やす前に実行してください。
警告
spec.memberConfig を設定するノード数を増やす前に
デフォルトでは、新しい Kubernetes ノードは投票ノードとして参加します。CRD デフォルトは votes: 1 と priority: "1" です。これらのデフォルトにより、同期中のノードは最初の同期が完了する前に選挙に参加できます。
MongoDB は、ノード数を増やす前に、votes: 0 と priority: "0" を使用して、新しい Kubernetes ノードごとに spec.memberConfig エントリを 1 つ書き込み (write)することを推奨します。これにより、まだ同期中のノードが選挙に勝つことができなくなります。votes は整数です。priority は string です。
例、次の構成は、単一クラスターのシャーディングされた配置を拡張します。この例では、コンフィギュレーションサーバーに 1 つのKubernetesメンバー、2 つのシャードそれぞれに 1 つ、および 1 つの mongos ルーターを追加します。新しいメンバーが最初の同期を完了している間に votes: 0 と priority: "0" を設定し、次に示す値でそれらを昇格させます。
spec: configServerCount: 1 memberConfig: - votes: 1 priority: "10" shardOverrides: - shardNames: ["myclustershard-0"] members: 1 memberConfig: - votes: 1 priority: "10" - shardNames: ["myclustershard-1"] members: 1 memberConfig: - votes: 1 priority: "10" mongosCount: 1単一クラスター配置では、最上位のspec.memberConfig がコンフィギュレーションサーバーメンバーを構成します。一致するspec.shardOverrides エントリがないすべてのシャードのメンバーに同じ構成が適用されます。mongos ルーターはレプリカセットメンバーではなく、 を受け取りません。memberConfig
コンポーネントごとの TLS 証明書
コンポーネントごとに 1 つの証明書を発行します。名前付けのパターンはそれぞれのコンポーネントに合わせて使用します。コンフィギュレーションサーバーには <name>-config-*、各シャードには <name>-<i>-*、および mongos 台のルーターには <name>-mongos-*を使用します。
1 つのコンポーネントずつ拡張および剪定
コンフィギュレーションサーバー、シャード、または mongos ルーターの拡張や削減に順序の指定はありません。一度に拡張または削減するコンポーネントは1つだけにしてください。次のコンポーネントや次のエントリに進む前に、目標状態になるまで待機してください。
ステータス条件と検証
ステータス状況と理由は、レプリカセットと同様に機能し、すべてのコンポーネントにわたるオーバーライドを考慮したノードの総数に基づいて計算されます。kubectl wait --for=condition=Migrating=False はシャーディングされたクラスターの移行に有効です。
移行は、シャード ノードではなく、mongos Pod を介して検証します。