MongoDB カスタム リソースは、Kubernetes 演算子が管理するデータベース配置を定義します。カスタム リソースの仕様によってこれらのリソースが定義され、Kubernetes 演算子がこれらをモニターします。リソースの仕様を更新すると、Kubernetes 演算子は変更を Ops Manager にプッシュし、MongoDB 配置の構成が変更されます。
MongoDB CRD は 3 つの配置タイプをサポートしています。次の図は、各タイプの構成を示しています。
警告
Kubernetes Operator はアービタ ノードをサポートしていません。
スタンドアロン リソース
Standaloneリソースを配置できますが、レプリカセットを使用すると将来ノードを追加できるため、1 つのノードを持つ ReplicaSetリソースを配置することをお勧めします。Kubernetes では、Standaloneリソースは 1 つのノードのみを持つ ReplicaSetリソースと同等です。
Standaloneリソースの場合、Kubernetes Operator は単一のノードを含むレプリカセットを StatefulSet として配置します。Kubernetes Operator は、ポッド仕様を含む StatefulSet を作成し、Kubernetes StatefulSet コントローラーに依存してこの単一の mongod インスタンスのポッドを作成します。
レプリカセット リソース
ReplicaSetリソースの場合、Kubernetes Operator はレプリカセットをステートフルセットとして配置します。ノード数はspec.membersの値と等しくなります。Kubernetes Operator は、レプリカセットの各ノードについて 1 つのポッドを作成するために Kubernetes StatefulSet コントローラーに依存します。各ポッドは、そのポッドで mongod プロセスをマネージする MongoDB Agent インスタンスを実行します。
シャーディングされたクラスターのリソース
ShardedCluster リソースは、コンフィギュレーションサーバー、mongos インスタンス、およびシャード ノードで構成されています。Kubernetes 演算子は次を配置します。
すべてのコンフィギュレーションサーバーに 1 つのステートメントセット
すべての
mongosインスタンスに対する 1 つの StatefulSet各シャードの StatefulSet
Kubernetes 演算子 は、各 StatefulSet に 1 つのポッドを作成するために Kubernetes StatefulSet コントローラーに依存します。2 シャードを持つシャーディングされたクラスターの場合、これは合計 4 の StatefulSet を意味します（コンフィギュレーションサーバーで 1、mongos で 1、シャードで 2）。
配置タイプ | StateftSets | ステートメントセットのサイズ |
|---|---|---|
スタンドアロン | 1 | 1 Pod |
レプリカセット | 1 | 1ポッド メンバーごと |
シャーディングされたクラスター | <numberOfShards> + 2 |
|
MongoDB リソースの再調整
MongoDBカスタム リソース仕様を適用すると、Kubernetes Operator は各リソースをステートフルセットとして配置します。Kubernetes 演算子 は、その後、継続的な調和ループに入ります。
で指定された ConfigMap
spec.opsManager.configMapRef.nameからプロジェクト構成を読み取ります。API 認証情報を、
spec.credentialsで指定されたシークレットか、またはシークレット ストレージ ツールから読み取ります。MongoDB Ops Managerに接続し、次の操作を実行します。
ConfigMap の
orgIdから組織を読み取ります。projectNameで指定されたプロジェクトを読み取るか作成します。<project-id>-group-secretが存在することを確認するか、MongoDB Ops Manager API キーを使用して作成します。Kubernetes 演算子を ConfigMap と認証情報 Secrets のウォッチャーとして登録します。
TLS と X.509 証明書を検証します (有効な場合):
レプリカセットの場合は、
<prefix>-<resource-name>-cert内の証明書を検索します。シャーディングされたクラスターの場合：
<prefix>-<resource-name>-x-cert(シャードごと)、<prefix>-<resource-name>-config-cert(コンフィギュレーションサーバー)、<prefix>-<resource-name>-mongos-cert(mongosインスタンス)の証明書を検索します。
StatefulSet を作成または更新します。数は配置の種類によって異なります。現在、各ポッドは MongoDB Agent を実行していますが、
mongodインスタンスはまだ含まれていません。MongoDB Agent各インスタンスは、オートメーション構成のために Ops Manager をポーリングします。
静的でないコンテナでは、MongoDB Agentは
spec.versionで指定されたバージョンのMongoDBバイナリをダウンロードします。構成を受信した後、MongoDB Agent は
mongodを開始します。Kubernetes 演算子 は、
spec.persistentがfalseでない限り、各 Pod （mongosPod を除く）の PersistentVolumeClaims を生成します。
オートメーション構成の更新を MongoDB Ops Manager にプッシュします。各 MongoDB Agent は更新された構成をポーリングしています。それを適用します。フィールドを変更すると、Kubernetes 演算子は StatefulSets のローリング更新を実行します。
Kubernetes Services を作成または更新します:
ReplicaSetまたはStandaloneの場合、<resource-name>-svcという名前のヘッドレスClusterIPサービス。ShardedClusterの場合:mongos:spec.serviceまたは<resource-name>-svcの名前を使用します。Config servers:
<resource-name>-cs.各シャード:
<resource-name>-sh。
次の図は、レプリカセットの調和フローを示しています。
次の図は、シャーディングされたクラスターの調停フローを示しています。
MongoDBUser リソースの突合
ユーザー認証方法が SCRAM の場合、MongoDBUser リソースはユーザー認証情報を保存するシークレットに依存します。Kubernetes 演算子はシークレットの変更を監視し、次のように調整します。
spec.MongoDBResourceRef.nameから MongoDB ユーザーのリソースを決定します。MongoDB Ops Manager に接続し、組織とプロジェクトを読み取り、エージェントのシークレットを検証します。
MongoDB Ops Managerでユーザーの認証情報を更新します。ユーザーが存在しない場合は新しいユーザーを作成します。ユーザー名が変更された場合、Kubernetes 演算子は古い名前を削除し、新しい名前を追加します。
次の図は、MongoDBUser 調和フローを示しています。
