Kubernetes の MongoDB Database アーキテクチャ

スタンドアロン

StandaloneMongoDB データベース リソースの タイプの場合、Kubernetes Operator は、単一のノードを含むレプリカセットをステートメントセットとして Kubernetes クラスターに配置します。 。

Kubernetes Operator は、作成する ポッドの数を含む ポッド仕様を含むステートフルセットを作成します。 Kubernetes Operator は、このスタンドアロンの MongoDB データベース インスタンス用のポッドを作成するために Kubernetes StateftableSet コントロール に依存しています。

レプリカセット

ReplicaSetMongoDB リソースの タイプの場合、Kubernetes Operator はレプリカセットをステートメントとして Kubernetesspec.members クラスターに配置します。 、 の値は と等しいノード数を持ちます。

Kubernetes Operator は、レプリカセットの各ノードに対して ステートメントに 1 つのポッドを作成するために Kubernetes AtlasStatusAtlas コントロール に依存します。

ステートフルセット 内の各ポッドはMongoDB Agentインスタンスを実行します。

シャーディングされたクラスター

MongoDB リソースのShardedClusterタイプは、1 つ以上のコンフィギュレーションサーバー、 mongosインスタンス、およびシャード ノードで構成されています。

ShardedClusterリソースに対して、Kubernetes Operator は次を配置します。

• すべてのコンフィギュレーションサーバーに 1 つのステートメントセット

• すべてのmongosインスタンスに対して 1 つのステートメントセット

• 各シャード ノードごとに 1 つのステートメントセット

Kubernetes Operator は、シャーディングされたクラスター用に作成された各 StatefluSet に 1 つのポッドを作成するために、 Kubernetes StatefunctionSet コントロール に依存しています。

レプリカセットの調整の図

次の図では、レプリカセットの に変更を加えた場合の Kubernetes Operator の動作を説明します。

• MongoDB カスタムリソース仕様

• 関連 する ConfigMap

• シークレット ストレージ ツールに保存されている関連するシークレット

クリックして拡大します

シャーディングされたクラスターの調整の図

以下の図では、シャーディングされたクラスターの に変更を加えた場合の Kubernetes Operator の動作を説明しています。

• MongoDB カスタムリソース仕様

• 関連 する ConfigMap

• シークレット ストレージ ツールに保存されている関連するシークレット

クリックして拡大します

調整ワークフロー

MongoDB リソース仕様を作成または変更する場合、または関連付けられている ConfigMap に変更を加える場合 または シークレットがない場合、Kubernetes Operator は変更を調整するために次のアクションを実行します。

1. Kubernetes Operator でプロジェクトを作成または接続するために使用したConfigMapから、必要な組織とプロジェクトの構成を読み取ります。

   リソース仕様を変更すると、Kubernetes Operator は変更が行われたことを識別し、 spec.opsManager.configMapRef.nameで指定された ConfigMap の仕様を確認します。

   注意

   リソース用にKubernetes OperatorMongoDB を構成すると、 または プロジェクトを接続または作成する ための ConfigMapCloud Manager MongoDB Ops Managerが作成されます。MongoDB Agent はこの ConfigMap を使用して、MongoDB リソースの配置を開始または変更します。

2. 次のいずれかに指定されたシークレットから、 Cloud ManagerまたはMongoDB Ops Managerの認証構成を読み取ります。

   • spec.credentials 、リソース仕様内

   • シークレット ストレージ ツール

   このシークレットには、Cloud ManagerAPI MongoDB Ops ManagerAPIKubernetesOperator がCloud Manager または に認証するために必要な キー または キーMongoDB Ops Manager が保存されています。

   注意

   MongoDB リソース用に Kubernetes Operator を構成するときは、Kubernetesでこのシークレットを作成するか、このシークレットをシークレット ストレージ ツールに保存します。

3. Kubernetes Operator はCloud ManagerまたはMongoDB Ops Managerに接続し、次のアクションを実行します。

   • ConfigMap のorgIdフィールドから組織を読み取ります。 orgIdフィールドに値を指定する必要があります。

   • ConfigMap の projectName フィールドで指定されたプロジェクト名を読み取ります。または、この任意フィールドに値を指定しなかった場合、 はCloud ManagerまたはMongoDB Ops Managerにこのプロジェクトを作成します（存在しない場合）。

   • MongoDB Agent 用に Kubernetes 演算子によって作成された<project-id>-group-secretシークレットが存在することを確認します。 Kubernetes Operator は、シークレット ストレージ ツールからシークレットを読み取るか、 MongoDB Ops Manager APIキーまたはCloud Manager APIキーを使用してシークレットを作成します。

   • は、自分自身を ConfigMap とこのシークレットの監視者として登録します。 これにより、 Kubernetes演算子は、 Reactまたはシークレットに加えられた変更に対応できるようになります。

4. Kubernetes Operator は、 TLS および X.509 証明書を検証します。

   • レプリカセットでTLSが有効になっている場合、Kubernetes Operator は、 <prefix>-<resource-name>-certシークレットまたはシークレット ストレージ ツールで提供されている証明書を検索します。

   • シャーディングされたクラスターでTLSが有効になっている場合、Kubernetes Operator は次のシークレットで証明書を検索します。

     • <prefix>-<resource-name>-x-cert を、各シャード ノードの

     • <prefix>-<resource-name>-config-cert （すべてのコンフィギュレーションサーバーに対して）。

     • <prefix>-<resource-name>-mongos-cert すべてのmongosインスタンス

     • シークレット ストレージ ツール。

   • X.509またはX.509 と TLS による内部認証が有効になっている場合、Kubernetes Operator は証明書に必要な構成が含まれているかどうかを確認します。

5. Kubernetes Operator は、必要なステートメントセットを検索して更新し、存在しない場合は新しいステートメントセットを作成します。 ステートメントセットの数は、MongoDB リソースのタイプによって異なります。

   • ReplicaSetまたはStandaloneリソースの場合、Kubernetes Operator は単一のStatulSet を作成します。

   • Kubernetes Operator はShardedClusterリソースの場合、次のアイテムを作成します。

     • すべてのコンフィギュレーションサーバーに対して 1 つのステートメントセット。

     • すべてのmongosインスタンスに対して 1 つのステートメントセット。

     • 各シャード ノードごとに 1 つのステートメントセット。

     この時点で、各ポッドは少なくとも 1 つの MongoDB Agent インスタンスを実行していますが、 mongodインスタンスはまだ含まれていません。

   • MongoDB Agent各Cloud Manager MongoDB Ops ManagerMongoDBインスタンスは、 オートメーション構成を受信するために または のポーリングを開始します。

     注意

     非静的コンテナ: MongoDB AgentMongoDBspec.versionは初めて構成を受信すると、 で指定されたバージョンの バイナリをインターネットから、またはMongoDB Ops Manager MongoDB Agentが ローカル モード で構成されている場合は からダウンロードします。

     Static containers: Static containers do not download binaries at runtime. 詳細については、「静的コンテナ（パブリック プレビュー） 」を参照してください。

   • MongoDB Agent が自動化構成を受信すると、対応するポッドでmongodインスタンスが起動されます。

   • MongoDB カスタム リソースが作成する各ステートメントセットの各ポッド（ ステートメントセットを除く）に対して、Kubernetesmongos 演算子は 永続的なボリューム要求 を生成します 。この動作は、リソース仕様でspec.persistentをfalseに設定することで上書きできます。

6. Kubernetes Operator は、 MongoDB Agentから受信したオートメーション構成を 仕様の変更で更新し、 Cloud ManagerまたはMongoDB Ops Managerに送信します。

   • 各ポッドの各MongoDB AgentはCloud ManagerまたはMongoDB Ops Managerを再度ポーリングし、更新されたオートメーション構成を受け取ります。

   • 仕様のフィールドを変更すると、Kubernetes Operator は ローリング アップデート を実行します ステートフルセットの ）コマンドを使用して、新しい仕様に一致する新しい ポッド を起動します。

   • Kubernetes Operator は、各 MongoDB Agent が準備完了状態に達したことを報告するまで待機します。

   注意

   データベースリソースの セキュリティ構成 を変更する場合、または スケールダウンした 場合、 既存の ステートメントセットの場合、Kubernetes 演算子はステップ を実行する前にステップ6 5を実行します。

7. Kubernetes Operator は、Kubernetes サービスを更新、または新しい MongoDB リソースの場合、新しい Atlas App Services ごとに必要なサービスを作成します。

   サービスタイプの場合ClusterIP の場合、Kubernetes OperatorClusterIP は をNone に設定し、次のアクションを実行します。

   • このサービスが存在しない場合は、 が作成します。

   • ReplicaSetまたはStandaloneリソースの場合、Kubernetes Operator はカスタム リソースの名前に-svcを付けたサービスに名前を付けます。

   • ShardedClusterリソースの場合、Kubernetes 演算子は次の命名規則を使用します。

     • mongosインスタンスの場合、Kubernetes Operator はspec.serviceで指定された名前、または-svcが追加されたリソースの名前を使用します。

     • コンフィギュレーションサーバーの場合、Kubernetes Operator は、 -csが追加されたリソースの名前を使用します。

     • Kubernetes Operator は、各シャードに対して、 -shが追加されたリソースの名前を使用します。

   • ポートには、Kubernetes Operator はデフォルトのポート27017 または で指定された .net.port spec.additionalMongodConfigを使用します。