The Kubernetes Operator は、リソースを配置する各Kubernetesクラスターの MongoDBOpsManager カスタムリソース を使用して、MongoDB Ops Manager の配置を管理します。Kubernetes演算子 は、リソースの仕様の変更を監視します。仕様が変更されると、 Kubernetes Operator は変更を検証し、 MongoDB Ops Managerコンポーネントを配置する各Kubernetesクラスターのリソースに適切な更新を行います。
MongoDBOpsManager カスタムリソースの仕様では、次のMongoDB Ops Managerコンポーネントが定義されます。
アプリケーション データベース
MongoDB Ops Managerアプリケーション
バックアップデーモン
以下の図では、 MongoDB Ops Managerの配置に関連するコンポーネントが説明されています。
単一クラスター配置では、Kubernetes Operator がインストールされるのと同じ Kubernetes クラスターにこれらのコンポーネントを配置します。 このクラスターは「演算子クラスター」と呼ばれます。
マルチクラスター配置では、次の操作を行います。
異なる Kubernetes クラスターに配置します。これは「ノードクラスター」と呼ばれます。 また、Kubernetes クラスターの単一ノードを使用した簡素化されたマルチクラスター配置を配置することもできます。 詳細については、「シングルクラスター モードとマルチクラスター モード 」を参照してください。
Kubernetes Operator を、「オペレータークラスター」と呼ばれる 1 つの Kubernetes クラスターにインストールし、Kubernetes Operator が他のすべてのノードクラスターを管理します。 演算子クラスターは、 MongoDB Ops Managerコンポーネントもホストできるため、ノードクラスターと見なすこともできます。 「マルチクラスター アーキテクチャ図 」を参照してください。
アプリケーション データベース
アプリケーション データベースの場合、 Kubernetes Operator はMongoDBレプリカセットをステートフルセットとして配置します。
アプリケーション データベースの各ポッドには、次のコンテナがあります。
MongoDB Agent 。 MongoDB Agent のバージョンを上書きするには、
$AGENT_IMAGE環境変数または Kubernetes Operator のインストールに使用する Helm チャートのagent.versionを使用します。モニタリングエージェント。 モニタリングエージェントのバージョンを上書きすることはできません。 Kubernetes Operator が使用するバージョンは、 MongoDB Ops Managerバージョンとの下位互換性を確保します。
モニタリングエージェントのバージョンを表示するには、以下を行います。
Kubernetes Operator の ポッド または Kubernetes Operator の イメージ内の
/usr/local/om_version_mapping.jsonを調べます。アプリケーション データベースを配置するポッドで、モニタリングエージェントのコンテナのイメージを確認します。
マルチクラスター配置（ spec.applicationDatabase.topologyをMultiClusterに設定している場合）、Kubernetes Operator は、 spec.applicationDatabase.clusterSpecListのアプリケーション データベースに指定された各 Kubernetes クラスターにステートフルセットを作成します。
次のアクションは、アプリケーション データベースの MongoDB レプリカセット ノードをホストしている各ノードの Kubernetes クラスターで実行されます。
Kubernetes は、アプリケーション データベース レプリカセットを構成する各ノードに対して ステートメントを使用して 1 つのポッドを作成します。 ステートメントセット内の各ポッドは
mongodとMongoDB Agentを実行します。To enable each MongoDB Agent to start
mongodon its Pod in the StatefulSet, you must specify a specific MongoDB Server version for the Application Database using thespec.applicationDatabase.versionsetting. The version that you specify in this setting must correspond to the tag in the container registry.Each MongoDB Agent starts
mongods on its Application Database Pod. MongoDB Agent's addmongodprocesses to the Application Database replica set.アプリケーション データベースレプリカセットのレプリカ数とその他の構成オプションは、
spec.applicationDatabaseカスタムリソースのMongoDBOpsManagerコレクションで構成します。Kubernetes Operatorは、アプリケーション データベース ステートメント セット内の各ポッドにマウントされるシークレットを使用して、この構成をMongoDB Agent の に渡します。マルチクラスターのアプリケーション データベースの配置（
spec.applicationDatabase.topologyがMultiClusterに設定されている場合）では、spec.applicationDatabase.clusterSpecListの各ノードクラスターに対して各ノードクラスター内のノード数を個別に指定します。 マルチクラスター配置では、spec.applicationDatabaseのreplicas設定は無視されます。spec.applicationDatabaseコレクションを更新するたびに、Kubernetes Operator は MongoDB Agent の構成と Atlas Triggers 仕様に変更を適用します（該当する場合）。 ステートフルセットの仕様が変更された場合、Kubernetes はポッドを段階的にアップグレードし、各ポッドを再起動します。To provide connectivity to each Application Database Pod from within each Kubernetes cluster hosting the Application Database, the Kubernetes Operator creates a headless service. In multi-cluster deployments of the Application Database, the Kubernetes Operator also creates one service per Pod named
<om_resource_name>-db-N-svc(this corresponds tometadata.name), and uses its FQDN, such as<om_resource_name>-db-0.<namespace>.svc.cluster.local, as a hostname for connecting to a particularmongod.StorageClass に応じて または Kubernetes Operator を配置した環境によって、Kubernetes は 永続的なボリューム を作成する可能性があります。 動的ボリュームプロビジョニング を使用します。
You can customize the Persistent Volume Claims for the Application Database Pods using
spec.applicationDatabase.podSpec.persistence.singleorspec.applicationDatabase.podSpec.persistence.multiple.
アプリケーション データベースのトポロジー
プライマリを選択するには、アプリケーション データベースのレプリカセットのノードの過半数が利用可能である必要があります。レプリカセットのノードの過半数が失敗した場合、レプリカセットはプライマリノードを選出するための投票過半数を形成できません。詳細については、「 レプリカセットの配置アーキテクチャ 」を参照してください。
可能であれば、奇数のメンバー Kubernetes クラスターを使用し、 アプリケーションデータベース ノードをデータセンター、ゾーン、または Kubernetes クラスターに分散します。 詳しくは、「 2 つ以上のデータセンターに分散されたレプリカセット 」を参照してください。
アプリケーション データベースのトポロジーの次の例について考えてみましょう。
5 つのノードからなるアプリケーションデータベースの場合、ノードの分布には次のようなものがあります。
2 つのクラスター: 3 つのノードから
Cluster 1への 2 つのノードで、Cluster 2への 2 つのノード。Cluster 2が失敗した場合、Cluster 1はプライマリ ノードを選択するのに十分な数のアプリケーション データベースのレプリカセット メンバーをホストします。Cluster 1が失敗した場合、Cluster 2にはプライマリ ノードを選択するのに十分なアプリケーション データベースのメンバーがありません。
3 つのクラスター:
Cluster 1に 2 つのノード、Cluster 2に 2 つのノード、Cluster 3に 1 つのノード。いずれかのクラスターが失敗した場合、残りのクラスターにプライマリ ノードを選択するのに十分なメンバーが存在します。
2 つのクラスターが失敗した場合、残りのクラスターにプライマリ ノードを選択するのに十分なノードがありません。
7 つのノードからなるアプリケーション データベースの場合、次のノードの分布を考慮してください。
2 つのクラスター: 4 つのノードから
Cluster 1への 3 つのノード、Cluster 2への 3 つのノード。Cluster 2が失敗した場合、Cluster 1にはプライマリ ノードを選択するのに十分なメンバーが存在します。Cluster 1が失敗した場合、プライマリ ノードを選択するのに十分なメンバーがCluster 2に存在しません。
Cluster 2はアプリケーション データベースの最小ノード 3 つを満たしていますが、アプリケーション データベースの 7 つのノードの過半数がプライマリ ノードの選択に使用できる必要があります。
MongoDB Ops Managerアプリケーション
アプリケーション データベースが実行状態に達すると、 Kubernetes Operator によってMongoDB Ops Managerアプリケーションの配置が開始されます。
これにより、Kubernetes クラスターの各ノードに ステートメントが構成されます。
配置するMongoDB Ops Managerレプリカセットごとに、 Kubernetesはステートフルセットに 1 つのポッドを作成します。
各ポッドには 1 つのMongoDB Ops Managerアプリケーション プロセスが含まれています。
MongoDB Ops Managerの単一クラスターの配置を単一の ポッド障害に対して回復性のあるものにするには、 を使用してMongoDB Ops Manager spec.replicasアプリケーションをホストするレプリカの数を増やします。
マルチクラスターのMongoDB Ops Manager 配置をデータセンターまたはゾーン全体の障害に対して回復性のあるものにするには、MongoDB Ops Manager と を に設定して アプリケーションを複数のKubernetes spec.topologyspec.applicationDatabase.topologyMultiClusterクラスターに配置します。「 MongoDB Ops Managerと AppDB リソースの障害復旧 」も参照してください。
バックアップデーモン
がspec.backup.enabled true の場合、各ノードのKubernetes クラスターでは、Kubernetes アプリケーションがMongoDB Ops Manager 実行中 のステージに達した後に Operator はバックアップデーモンを起動します。バックアップデーモンの場合、Kubernetes Operator はステートフルセットを各ノードの Kubernetes クラスターにデプロイします。 各ノード クラスターに、Kubernetes はspec.backup.membersで指定された数のバックアップ デーモン ポッドを Atlas App Services に作成します。 単一クラスター配置では、これらのアクションはKubernetes Operator のインストールとMongoDB Ops Managerコンポーネントの配置に使用するオペレータークラスターで行われます。
If you enable backup, configure the oplog store, a blockstore, or an S3 snapshot store at the global spec.backup level, and not for each Kubernetes member cluster.
バックアップジョブを暗号化 することもできますが、同じ Kubernetes Operator インスタンスが MongoDPOsManager と MongoDB カスタム リソースの両方を管理していない配置には 制限が 適用されます。
If you enable backup, the Kubernetes Operator creates a Persistent Volume Claim for the Backup Daemon's head database on each member Kubernetes cluster. You can configure the head database using the spec.backup.headDB setting.
Kubernetes Operator はMongoDB Ops Manager API を呼び出して、 MongoDB Ops Managerアプリケーションのバックアップ構成が、各ノードのKubernetesクラスターのカスタム リソース定義で定義したバックアップ構成と一致することを確認します。