MongoDB Database リソースの仕様

必須

apiVersion

型: string

MongoDBリソース スキーマのバージョン。

kind

型: string

作成するMongoDBリソースの種類。 これをMongoDBに設定します

metadata.name

型: string

作成するMongoDBリソースの名前。

リソース名は 44 文字以下にする必要があります。

spec.credentials

型: string

必須。 シークレット MongoDB Ops ManagerAPIの名前Kubernetes は、Kubernetes Operator がCloud Manager または と通信するための 認証情報として 作成MongoDB Ops Manager しました。

認証情報を保持するMongoDB Ops Manager Kubernetes Secretオブジェクトは、作成するリソースと同じ名前空間に存在する必要があります。

重要

演算子がシークレットへの変更を管理

Kubernetes Operator は、シークレットへの変更を追跡し、 MongoDBリソースの状態を調整します。

spec.persistent

タイプ: ブール値

デフォルト: True

警告: コンテナに 永続ボリューム への書込み (write) 権限を付与 。Kubernetes 演算子は、 securityContextでfsGroup = 2000 、 runAsUser = 2000 、 runAsNonRoot = trueを設定します。 Kubernetes Operator は、 fsgroupをrunAsUserと等しく設定して、コンテナでメイン プロセスを実行するユーザーがボリュームを書込み可能にします。 詳細については、「 ポッドまたはコンテナのセキュリティ コンテキストの構成 」を参照してください および関連する ディスカッション （Kubernetes ドキュメント）。リソースを再デプロイしても永続ボリュームの問題が修正されない場合は、 MongoDB サポートにお問い合わせください。

永続的なボリューム を使用しない場合 Disk UsageDisk IOPSProcesses、Deployment 、Metrics チャートは、この配置 のデータ を確認するときに、 ページの タブまたは ページのいずれにも表示できません。

spec.type

型: string

作成するMongoDBリソースのタイプ。 指定できる値は以下のとおりです。

• Standalone

• ReplicaSet

• ShardedCluster

spec.version

型: string

このMongoDBリソースにインストールした MongoDB のバージョン。

重要

互換性のある MongoDB Server バージョンを選択していることを確認してください。

互換性のあるバージョンは、MongoDB database リソースが使用する基本イメージによって異なります。

注意

この値をデータベースリソース用のMongoDBの新しいバージョンに更新しても、機能の互換性バージョンはアップグレード元のMongoDBバージョンのままになり、必要に応じてダウングレードのオプションが提供されます。 機能の互換性バージョンを新しいMongoDBバージョンと一致させるには、 spec.featureCompatibilityVersionを新しいバージョンに、またはAlwaysMatchVersionに手動で設定する必要があります。 詳しくは、 spec.featureCompatibilityVersionを参照してください。

条件付き

すべてのリソースは、次のいずれかの設定を使用する必要があります。

spec.opsManager.configMapRef.name

型: string

ConfigMap の名前Cloud Manager またはMongoDB Ops Manager 接続構成の場合。spec.cloudManager.configMapRef.name設定はこの設定のエイリアスであり、代わりに使用できます。

この値は、作成するリソースと同じ名前空間に存在する必要があります。

重要

演算子が ConfigMap への変更を管理

Kubernetes 演算子は、ConfigMap への変更を追跡し、 MongoDBリソースの状態を調整します。

spec.cloudManager.configMapRef.name

型: string

spec.opsManager.configMapRef.nameのエイリアス。

任意

すべてのリソースの種類では、次の設定を使用できます。

metadata.annotations.mongodb.com/v1.architecture

型: string

具体的な配置で使用されるコンテナ アーキテクチャを決定します。

• 実行時に MongoDB バイナリをダウンロードするデフォルトの非静的コンテナ、または

• 実行時に不変である静的コンテナ（パブリック プレビュー） 。

指定できる値は次のとおりです。

• static

• non-static

apiVersion: mongodb.com/v1
kind: MongoDB
metadata:
  name: my-project
  annotations:
    mongodb.com/v1.architecture: "static"

spec.agent.backupAgent.logRotate

型: オブジェクト

MongoDB Agent がバックアップ ログをローテーションするしきい値。

spec.agent.backupAgent.logRotate.sizeThresholdMB

タイプ: 整数

MongoDB Agent がログをローテーションする前のバックアップ ログファイルの最大サイズ（MB 単位）。

spec.agent.backupAgent.logRotate.timeThresholdHrs

タイプ: 整数

MongoDB Agent がバックアップ ログファイルをローテーションする時間数。

spec.agent.mongod.auditlogRotate

型: オブジェクト

MongoDB プロセスの監査ログ ローテーション構成を含むオブジェクト。

spec.agent.mongod.auditlogRotate.sizeThresholdMB

タイプ: 数値

MongoDB Agent がログをローテーションする前の監査ログファイルの最大サイズ（MB 単位）。

spec.agent.mongod.auditlogRotate.timeThresholdHrs

タイプ: 整数

MongoDB Agent が監査ログファイルをローテーションする時間数。

spec.agent.mongod.auditlogRotate.numUncompressed

タイプ: 整数

現在のログファイルを含む、非圧縮のままにする監査ログファイルの最大数。

spec.agent.mongod.auditlogRotate.numTotal

タイプ: 整数

MongoDB Ops Managerが保持する 監査ログ ファイルの合計数。 この値を設定しない場合、監査ログファイルの合計数はデフォルトで0になります。

spec.agent.mongod.auditlogRotate.percentOfDiskspace

タイプ: 数値

MongoDB Ops Managerがログファイルを保存するために使用できる合計ディスク領域の最大パーセンテージは小数で表されます。 この制限を超えた場合、 MongoDB Ops Managerは、この制限を満たすまで圧縮されたログファイルを削除します。 MongoDB Ops Managerは、最も古いログファイルを最初に削除します。

デフォルトは0.02です。

spec.agent.mongod.logRotate

型: オブジェクト

MongoDB Ops ManagerがプロセスのMongoDBログをローテーションするしきい値。

spec.agent.mongod.logRotate.sizeThresholdMB

タイプ: 整数

MongoDB Ops Managerがログファイルをローテーションする前の、個々のログファイルの最大サイズ（MB 単位）。 MongoDB Ops Manager は、このsizeThresholdMBまたはspec.agent.mongod.logRotate.timeThresholdHrsのいずれかに指定された値を満たす場合、ログファイルをすぐにローテーションします。

spec.agent.mongod.logRotate.timeThresholdHrs

タイプ: 整数

次のローテーションまでの個々のログファイルの最大期間（時間単位）。 は最後のローテーション以降の時間です。

MongoDB Ops Manager は、ファイルがこのtimeThresholdHrsまたはspec.agent.mongod.logRotate.sizeThresholdMBのいずれかを満たすと、ログファイルをローテーションします。

spec.agent.monitoringAgent.logRotate

型: オブジェクト

MongoDB Agent が監視ログをローテーションするしきい値。

spec.agent.monitoringAgent.logRotate.sizeThresholdMB

タイプ: 整数

MongoDB Agent が監視ログをローテーションする前の、個々のログファイルの最大サイズ（MB 単位）。

spec.agent.monitoringAgent.logRotate.timeThresholdHrs

タイプ: 整数

MongoDB Agent が監視ログをローテーションする時間数。

spec.agent.readinessProbe.environmentVariables

型: オブジェクト

Readness Probe のログファイルを制御するために使用される次の環境変数を構成します。

• readiness_PROBE_LOGER_BACKUPS

• readiness_PROBE_LOGER_COMPRESS

• readiness_PROBE_LOGER_MAX_SIZE

• readiness_PROBE_LOGER_MAX_AGE

• MDB_WITH_AGENT_FILE_LOGGING

• LOG_FILE_PATH

apiVersion: mongodb.com/v1
kind: MongoDB
metadata:
  name: my-project
spec:
  agent:
    readinessProbe:
      environmentVariables:
        READINESS_PROBE_LOGGER_BACKUPS: 1
        READINESS_PROBE_LOGGER_MAX_SIZE: 10
        READINESS_PROBE_LOGGER_MAX_AGE: 3
        READINESS_PROBE_LOGGER_COMPRESS: true
        MDB_WITH_AGENT_FILE_LOGGING: false
        LOG_FILE_PATH: /var/log/mongodb-mms-automation/readiness.log

spec.featureCompatibilityVersion

型: string

MongoDBのアップグレード後に、以前のメジャーMongoDBバージョンにデフォルト設定されます。

新しいメジャー バージョンへのアップグレードに関連して発生するデータの変更を制限します。 例、 MongoDB 5.0からMongoDB 6.0にアップグレードする場合、機能の互換性バージョンは5.0のままになり、必要に応じてダウングレードのオプションが提供されます。

機能の互換性バージョンを新しいMongoDBバージョンと一致させる場合は、 featureCompatibilityVersionを新しいバージョンに手動で設定する必要があります。 例、 featureCompatibilityVersion: 6.0 。

または、 AlwaysMatchVersionオプションを有効にすると、アップグレード中に機能の互換性バージョンがMongoDBバージョンと一致するように自動的に更新されます。 例、 featureCompatibilityVersion: AlwaysMatchVersion 。

機能の互換性の詳細については、 MongoDBマニュアルのsetFeatureCompatibilityVersionを参照してください。

spec.clusterDomain

型: string

デフォルト: cluster.local

Kubernetes Operator を配置する Kubernetes クラスターのドメイン名。 Kubernetes がステートメントを作成する場合 、Kubernetes は各 ポッド に割り当てます FQDN 。またはCloud Manager MongoDB Ops Managerを更新するために、Kubernetes 演算子は各 ポッド の FQDN を計算します 指定されたクラスター名を使用します。Kubernetes では、これらのホスト名をクエリするためのAPIは提供されていません。

警告

Kubernetes クラスターに デフォルトのドメインspec.clusterDomain がある場合は、 を設定する必要があります デフォルトのcluster.local 以外。デフォルトを使用せず、 spec.clusterDomainオプションも設定しない場合、Kubernetes 演算子が期待どおりに機能しない可能性があります。

spec.clusterName

型: string

デフォルト: cluster.local

重要

spec.clusterName は非推奨

代わりにspec.clusterDomainを使用してください。

Kubernetes Operator を配置する Kubernetes クラスターのドメイン名。 Kubernetes がステートメントを作成する場合 、Kubernetes は各 ポッド に割り当てます FQDN 。またはCloud Manager MongoDB Ops Managerを更新するために、Kubernetes 演算子は各 ポッド の FQDN を計算します 指定されたクラスター名を使用します。Kubernetes では、これらのホスト名をクエリするためのAPIは提供されていません。

警告

Kubernetes クラスターに デフォルトのドメインspec.clusterDomain がある場合は、 を設定する必要があります デフォルトのcluster.local 以外。デフォルトを使用せず、 spec.clusterDomainオプションも設定しない場合、Kubernetes 演算子が期待どおりに機能しない可能性があります。

metadata.namespace

型: string

Kubernetes 名前空間 このMongoDB リソースと他の オブジェクト を作成する場所 。

spec.service

型: string

デフォルト: <resource_name>+"-svc" および <resource_name>+"-svc-external"

重要

spec.service は非推奨

代わりにspec.statefulSet.spec.serviceNameを使用してください。

Atlas App Services が作成または使用する Kubernetes サービスの名前 。この名前のサービスがすでに存在する場合、MongoDB Enterprise Kubernetes Operator はサービスを削除または再作成しません。 この設定により、独自のカスタム サービスを作成し、Kubernetes Operator でそれらを再利用できます。

spec.logLevel

型: string

デフォルト: INFO

ポッド 内のオートメーションエージェントのログ記録のレベルを構成します 。受け入れ可能な値は以下の通りです。

• DEBUG

• INFO

• WARN

• ERROR

• FATAL

spec.security.authentication.ignoreUnknownUsers

タイプ: ブール値

デフォルト: false

Kubernetes Operator、またはCloud ManagerまたはMongoDB Ops Managerユーザー インターフェイスを通じて構成されていないデータベースユーザーを変更できるかどうかを決定します。

mongodまたはmongosを使用してデータベースユーザーを直接管理するには、この設定をtrueに設定します。

スタンドアロン設定

spec.additionalMongodConfig

タイプ: コレクション

MongoDB プロセスを開始するための追加構成オプション。

Kubernetes Operator は、MongoDB Agent を通じて配置する MongoDB バージョンがサポートするすべての構成オプションをサポートしています。ただし、Kubernetes Operator は、次のいずれかのオプションに指定した値を上書きします。

• net.port

• net.tls.certificateKeyFile

• net.tls.clusterFile

• replication.replSetName

• security.clusterAuthMode

• sharding.clusterRole

• storage.dbPath

• systemLog.destination

• systemLog.path

Kubernetes Operator が所有する構成オプションの詳細については、「 MongoDB Kubernetes Operator 専用設定 」を参照してください。

使用できる構成オプションについては、 MongoDBドキュメントの「 配置の詳細オプションMongoDB Ops Manager 」を 参照してください。

spec.agent

タイプ: コレクション

MongoDB データベース リソース 用の MongoDB Agent 構成設定。

spec.agent.startupOptions

タイプ: コレクション

MongoDB データベース リソースを起動する MongoDB Agent 設定。

MongoDB Agent 設定はキーと値のペアとして提供する必要があります。 値は文字列である必要があります。

サポートされている MongoDB Agent 設定のリストについては、以下を参照してください。

• Cloud Manager プロジェクトのMongoDB Agent 設定。

• OperatorMongoDB Agent を使用して配置したMongoDB Ops Manager バージョンの 設定 。Kubernetes

1
---
2
apiVersion: mongodb.com/v1
3
kind: MongoDB
4
metadata:
5
  name: my-standalone
6
spec:
7
  version: "6.0.0-ent"
8
  service: my-service
9
10
  opsManager:
11
    configMapRef:
12
      name: my-project
13
  credentials: my-credentials
14
  type: Standalone
15
16
  persistent: true
17
  agent:
18
    startupOptions:
19
      maxLogFiles: "30"
20
      dialTimeoutSeconds: "40"
21
...

spec.podSpec

型: オブジェクト

MongoDB CustomResourceDefinition の仕様を含むオブジェクト ポッド。

spec.externalAccess

タイプ: コレクション

クラスターを外部接続用に公開するための仕様。 Kubernetes クラスターの外部から MongoDB リソースに接続する方法については、「 Kubernetes の外部から MongoDB Database リソースに接続する 」を参照してください。

spec.externalAccessを追加すると、Kubernetes Operator はレプリカセット内の各ポッドの外部サービスを作成します。 外部サービスは、クラスター内の各 MongoDB database ポッドの外部エントリ ポイントを提供します。 各外部サービスには セレクター があります は、外部サービスを特定のポッドに一致させます。

値なしでこの設定を追加すると、Kubernetes Operator は次のデフォルト値を持つ外部サービスを作成します。

フィールド	値	説明
Name	<pod-name>-svc-external	外部サービスの名前。 この値は変更できません。
Type	LoadBalancer	外部 LoadBalancer を作成します service
Port	<Port Number>	mongodのポート。
publishNotReadyAddress	true	DNS レコード を指定する は、Ped が準備ができていない場合でも作成されます。どのデータベース ポッドでもfalseに設定しないでください。

注意

spec.externalAccess.externalDomainを設定すると、外部サービスはバックアップ用の別のポート（ Port Number + 1 ）を追加します。

spec.externalAccess.externalService

タイプ: コレクション

spec.externalAccessのデフォルト値を上書きするための指定。

spec.externalAccess設定を設定すると、Kubernetes Operator はデフォルト値の外部ロード バランサー サービスを自動的に作成します。 ニーズに応じて、特定の値を上書きしたり、新しい値を追加したりできます。 たとえば、 NodePort サービス を作成しようとすると、 で、ロード バランサーが必要ない場合は、Kubernetes 仕様でオーバーライドを構成する必要があります。

externalAccess:
  externalService:
    annotations:
      # cloud-specific annotations for the service
    spec:
      type: NodePort # default is LoadBalancer
      # you can specify other spec overrides if necessary

Kubernetes 仕様の詳細については、 ServiceSpec を参照してください （Kubernetes ドキュメント）。

spec.externalAccess.externalService.annotations

タイプ: コレクション

配置内のすべてのクラスターにクラウドプロバイダー固有の構成設定を追加できるキーと値のペア。 詳細については、 注釈 を参照してください Kubernetes クラウドプロバイダーのドキュメントとドキュメントを参照してください。

注釈 を使用できます で、Kubernetes Operator の配置で使用される外部サービスのプレースホルダー値を指定します。Kubernetes Operator は、これらの値を次の表に記載されている正しい値に自動的に置き換えます。 プレースホルダーを使用すると、特定のポッドの各サービスに特定の注釈を提供できます。

値	説明
{resourceName}	metadata.nameに等しい。
{namespace}	metadata.namespaceに等しい。
{podIndex}	ステートフルセット によって割り当てられたポッドのインデックス 現在の外部サービスが対象とする と
{podName}	{resourceName}-{podIndex}に等しい。
{statefulSetName}	ステートメントセット 。{resourceName}に等しい。
{externalServiceName}	指定したプレースホルダー値に基づいて、外部サービスの生成された名前。 {resourceName}-{podIndex}-svc-externalに等しい。
{mongodProcessDomain}	mongod プロセスをホストしているサーバーのドメイン名。 指定されている場合はspec.externalAccess.externalDomainと等しくなります。 それ以外の場合は、 mongodプロセスFQDNに使用されるドメインと等しくなります。 たとえば、プロセス ホスト名mdb-rs-1.example.comの場合、 example.comはドメイン名になります。
{mongodProcessFQDN}	mongodオートメーション構成 で設定された プロセスのホスト名。 プロセス ホスト名は、配置構成によって異なります。 external domainsを使用するように配置を構成した場合、プロセス ホスト名は次の形式を使用します。 {resourceName}-{podIndex}.{mongodProcessDomain} 以下に例を挙げます。 mdb-rs-1.example.com 配置で外部ドメインを使用しない場合、プロセス ホスト名は次の形式を使用します。 {resourceName}-{podIndex}.{resourceName}-{podIndex}-svc.{namespace}.svc.cluster.local 以下に例を挙げます。 mdb-rs-1.mdb-rs-1-svc.ns.svc.cluster.local

注意

表に指定されている既知のプレースホルダー値のみを使用し、プレースホルダーが空または null 値を使用しないようにする必要があります。 また、単一の MongoDB リソース配置では、複数の Kubernetes クラスター配置に固有のプレースホルダーを使用することもできません。

それ以外の場合、Kubernetes Operator はエラーを返します。 たとえば、次のエラーメッセージが表示される場合があります。

error replacing placeholders in map with key=external-dns.alpha.kubernetes.io/hostname, value={resourceName}-{podIndex}-{unknownPlaceholder}.{clusterName}-{clusterIndex}.example.com: missing values for the following placeholders: {clusterName}, {clusterIndex}, {unknownPlaceholder}``

例

次の例えでは、 {resourceName} 、 {podIndex} 、 {namespace}プレースホルダーを指定します。

apiVersion: mongodb.com/v1
kind: MongoDB
metadata:
  name: mdb-rs
  namespace: ns
spec:
  replicas: 3
  externalAccess:
    externalService:
      annotations:
        external-dns.alpha.kubernetes.io/hostname: {resourceName}-{podIndex}-{namespace}.example.com

Kubernetes Operator は、各プレースホルダーの適切な値に基づいて、外部サービスの注釈を自動的に入力します。 例:

mdb-rs-0-svc-external:
  annotations:
    external-dns.alpha.kubernetes.io/hostname: mdb-rs-0-ns.example.com
mdb-rs-1-svc-external:
  annotations:
    external-dns.alpha.kubernetes.io/hostname: mdb-rs-1-ns.example.com
mdb-rs-2-svc-external:
  annotations:
    external-dns.alpha.kubernetes.io/hostname: mdb-rs-2-ns.example.com

spec.externalAccess.externalService.spec

タイプ: コレクション

ServiceSpec の構成 。詳しくは、 spec.externalAccess.externalServiceを参照してください。

spec.podSpec.persistence.single

タイプ: コレクション

Kubernetes Operator が 1 つの 永続ボリューム要求 を作成するようにします と では、データ、ジャーナル、ログの 3 つのすべてのディレクトリが同じ 永続ボリューム にマウントされます。 。

注意

• spec.persistent : trueの場合は、このコレクションに値を設定する必要があります。

• このコレクションまたはpersistence.multipleコレクションを設定できますが、両方は設定できません。

スカラー	データ型	説明
labelSelector	string	タグ マウントされたボリュームをディレクトリにバインドするために使用されます。
storage	string	永続ボリューム の最小サイズ マウントする必要があるもの。この値は、 JEDEC表記では、整数とそれに続くストレージの単位として表されます。 デフォルト値は 16Gi です。 たとえば、 のスタンドアロン配置に60ギガバイトのストレージが必要な場合は、この値を60Giに設定します。
storageClass	string	永続的なボリューム要求 で指定されるストレージのタイプ 。このストレージ タイプは、 StorageClass として作成できます。 この オブジェクト で使用する前にオブジェクトを 仕様。 StorageClass を必ず設定してください 保持 するreclaimPolicy 。これにより、 永続的なボリューム要求 が発生した場合にデータが保持できます は削除されます。

spec.podSpec.persistence.multiple.data

タイプ: コレクション

Kubernetes Operator が 永続的なボリューム要求 を作成するようにします と は、データのディレクトリを独自の 永続ボリューム にマウントします。 。

注意

• spec.persistent : trueの場合は、このコレクションに値を設定する必要があります。

• このコレクションまたはpersistence.singleコレクションを設定できますが、両方を設定することはできません。

スカラー	データ型	説明
labelSelector	string	タグ マウントされたボリュームをディレクトリにバインドするために使用されます。
storage	string	Kubernetes ノード で使用可能である必要がある最小ストレージ容量 から、Kubernetes で スタンドアロン配置 をホストします。この値は、 JEDEC表記では、整数とそれに続くストレージの単位として表されます。 デフォルト値は 16Gi です。 たとえば、このMongoDBリソースに60ギガバイトのストレージ容量が必要な場合は、この値を60Giに設定します。
storageClass	string	スタンドアロン配置に必要なストレージのタイプ。 このストレージ タイプは、 StorageClass として作成できます。 この オブジェクト で使用する前にオブジェクトを 仕様。 StorageClass を必ず設定してください 保持 するreclaimPolicy 。これにより、 永続的なボリューム要求 が発生した場合にデータが保持できます は削除されます。

spec.podSpec.persistence.multiple.journal

タイプ: コレクション

Kubernetes Operator が 永続的なボリューム要求 を作成するようにします およびジャーナル用のディレクトリを独自の 永続ボリューム にマウントする 。

注意

• spec.persistent : trueの場合は、このコレクションに値を設定する必要があります。

• このコレクションまたはpersistence.singleコレクションを設定できますが、両方を設定することはできません。

スカラー	データ型	説明
labelSelector	string	タグ マウントされたボリュームをディレクトリにバインドするために使用されます。
storage	string	Kubernetes ノード で使用可能である必要がある最小ストレージ容量 から、Kubernetes で スタンドアロン配置 をホストします。この値は、 JEDEC表記では、整数とそれに続くストレージの単位として表されます。 デフォルト値は 1Gi です。 たとえば、このMongoDBリソースに60ギガバイトのストレージ容量が必要な場合は、この値を60Giに設定します。
storageClass	string	スタンドアロン配置に必要なストレージのタイプ。 このストレージ タイプは、 StorageClass として作成できます。 この オブジェクト で使用する前にオブジェクトを 仕様。 StorageClass を必ず設定してください 保持 するreclaimPolicy 。これにより、 永続的なボリューム要求 が発生した場合にデータが保持できます は削除されます。

spec.podSpec.persistence.multiple.logs

タイプ: コレクション

Kubernetes Operator が 永続的なボリューム要求 を作成するようにします および は、ログ用のディレクトリを独自の 永続ボリューム にマウントします。 。

注意

• spec.persistent : trueの場合は、このコレクションに値を設定する必要があります。

• このコレクションまたはpersistence.singleコレクションを設定できますが、両方を設定することはできません。

スカラー	データ型	説明
labelSelector	string	タグ マウントされたボリュームをディレクトリにバインドするために使用されます。
storage	string	Kubernetes ノード で使用可能である必要がある最小ストレージ容量 から、Kubernetes で スタンドアロン配置 をホストします。この値は、 JEDEC表記では、整数とそれに続くストレージの単位として表されます。 デフォルト値は 3Gi です。 たとえば、このMongoDBリソースに60ギガバイトのストレージ容量が必要な場合は、この値を60Giに設定します。
storageClass	string	スタンドアロン配置に必要なストレージのタイプ。 このストレージ タイプは、 StorageClass として作成できます。 この オブジェクト で使用する前にオブジェクトを 仕様。 StorageClass を必ず設定してください 保持 するreclaimPolicy 。これにより、 永続的なボリューム要求 が発生した場合にデータが保持できます は削除されます。

spec.podSpec.podTemplate.affinity.nodeAffinity

型: 構造体

Kubernetes ルール : ポッド を配置する 特定の範囲の ノード 上の レプリカセット 用 。

読み取りおよび書込みパフォーマンスを最適化するには、ノードの アフィニティ ルールを使用してノードを制限します 特定の ノード 上で を実行する 、または特定の ノード で の実行を優先する場合は 。

spec.podSpec.podTemplate.affinity.podAffinity

型: 構造体

Kubernetes ルール 複数のMongoDB リソース ポッド かどうかを判断 は他の ポッド と同じ場所に配置する必要があります 。ユースケースの詳細については、「 アフィニティと非アフィニティ 」を参照してください。 （Kubernetes ドキュメント）。

spec.podSpec.podTemplate.affinity.podAntiAffinity

型: 構造体

Default: kubernetes.io/hostname

ルールMongoDB を設定する ポッド を分散する リソースを異なる場所でホストする。ロケーションは、単一のノード、ロック、またはリージョンにすることができます。 デフォルトでは、Kubernetes Operator は異なるノードにポッドを分散しようとします。

spec.podSpec.podTemplate.affinity.podAntiAffinity.requiredDuringSchedulingIgnoredDuringExecution.topologyKey

型: 構造体

Default: kubernetes.io/hostname

このキーは、どの ラベル を定義しますか どのトポロジー ドメイン を決定するために使用されるか ノードが属する。

spec.podSpec.podTemplate

タイプ: コレクション

テンプレート MongoDB Enterprise Kubernetes Operator が MongoDB データベース リソース用に作成する Kubernetes ポッド用。

テンプレート値は、 spec.podSpecで指定された値よりも優先されます。

注意

Kubernetes 演算子は、 spec.podSpec.podTemplateで指定したフィールドを検証しません。

spec.podSpec.podTemplate.metadata

タイプ: コレクション

MongoDB Enterprise Kubernetes Operator が MongoDB database リソース用に作成する Kubernetes ポッドのメタデータ。

spec.podSpec.podTemplate.metadataに追加できるフィールドを確認するには、 Kubernetes のドキュメント を参照してください。

spec.podSpec.podTemplate.spec

タイプ: コレクション

MongoDB Enterprise Kubernetes Operator が MongoDB データベースリソース用に作成する Kubernetes ポッドの仕様。

spec.podSpec.podTemplate.specに追加できるフィールドを確認するには、Kubernetes PodSpec v1Core API を参照してください。

注意

spec.podSpec.podTemplate.spec.containersにコンテナを追加すると、Kubernetes Operator はそれらを Kubernetes ポッドに追加します。 これらのコンテナは、ポッド内の MongoDB database リソース コンテナに追加されます。

この設定を使用して、各ポッドの CPU と RAM の割り当てを指定します。 例について Githubは、 のサンプルを参照してください。

レプリカセット設定

レプリカセットのリソース タイプには次の設定が適用されます。

spec.backup

タイプ: コレクション

spec.backup.modeのコレクション コンテナ。Kubernetes Operator で MongoDB リソースの継続的なバックアップを可能にします。

spec.backup.assignmentLabels

タイプ: 配列

バックアップデーモン、oplog ストア、ブロックストア、 S3スナップショット ストア、ファイルシステム ストアを特定のプロジェクトまたはグループに割り当てるためのラベルのコンマ区切りリスト。 割り当てラベル を使用して、特定のバックアップ ストアが特定のプロジェクトに関連付けられていることを識別します。

Kubernetes Operator を使用して割り当てラベルを設定すると、割り当てラベルのKubernetes構成ファイルで設定した値が、 MongoDB Ops Manager UI で定義された値を上書きします。 Kubernetes Operator を使用して設定しない割り当てラベルは、 MongoDB Ops Manager UI で設定された値を引き続き使用します。

注意

このパラメータを設定する場合、 spec.credentialsの値にリンクされた API キーにGlobal Ownerロールが必要です。

spec.backup.mode

型: string

MongoDB リソースの継続的なバックアップを有効にします。 指定できる値は、 enabled 、 disabled 、 terminatedです。

注意

spec.backup.modeの設定は、 MongoDB Ops Managerで有効になっているspec.backup.enabled バックアップMongoDB Ops Manager trueに依存します。また、 リソース仕様 の 値が に設定されている必要があります。

spec.backup.modeを使用して MongoDB リソースの継続的なバックアップを有効にすると、バックアップ ステータスを確認できます。

spec.backup.encryption

型: オブジェクト

バックアップ暗号化の構成設定を含むオブジェクト。

spec.backup.encryption.kmip

型: オブジェクト

KMIPバックアップ暗号化の構成設定を含むオブジェクトです。 詳細については、「 MongoDB Ops Managerの KMIP バックアップ暗号化の構成 」を参照してください。

spec.backup.encryption.kmip.client

型: オブジェクト

KMIPバックアップ暗号化クライアントの構成設定を含むオブジェクト。

spec.backup.encryption.kmip.client.clientCertificatePrefix

型: string

spec.backup.snapshotSchedule

タイプ: コレクション

Kubernetes Operator の MongoDB リソースの継続的なバックアップのスナップショット スケジュール設定のコレクション コンテナ。

spec.backup.snapshotSchedule.snapshotIntervalHours

タイプ: 数値

スナップショット間の時間数。 6 、 8 、 12 、または24の値を設定できます。

spec.backup.snapshotSchedule.snapshotRetentionDays

タイプ: 数値

最近のスナップショットを保持する日数。 2から5までの値を設定できます。

spec.backup.snapshotSchedule.dailySnapshotRetentionDays

タイプ: 数値

日次スナップショットを保持する日数。 1から365までの値を設定できます。 値を0に設定すると、このルールが無効になります。

spec.backup.snapshotSchedule.weeklySnapshotRetentionWeeks

タイプ: 数値

Number of weeks to keep weekly snapshots. 1から52までの値を設定できます。 値を0に設定すると、このルールが無効になります。

spec.backup.snapshotSchedule.monthlySnapshotRetentionMonths

タイプ: 数値

月次スナップショットを保持する月数。 1から36までの値を設定できます。 値を0に設定すると、このルールが無効になります。

spec.backup.snapshotSchedule.pointInTimeWindowHours

タイプ: 数値

ポイントインタイム スナップショットを作成できる過去の時間数。

spec.backup.snapshotSchedule.referenceHourOfDay

タイプ: 数値

24 時間制でスナップショットをスケジュールする時刻のUTC時間。 0から23までの値を設定できます。

spec.backup.snapshotSchedule.referenceMinuteOfHour

タイプ: 数値

スナップショットをスケジュールする時間のUTC分。 0から59までの値を設定できます。

spec.backup.snapshotSchedule.fullIncrementalDayOfWeek

型: string

MongoDB Ops Managerが完全なスナップショットを取得する曜日。 この設定により、最新の完全なバックアップが保証されます。 MongoDB Ops Manager はデフォルト値をSUNDAYに設定します。

spec.clusterName

型: string

デフォルト: cluster.local

重要

spec.clusterName は非推奨

代わりにspec.clusterDomainを使用してください。

Kubernetes Operator を配置する Kubernetes クラスターのドメイン名。 Kubernetes がステートメントを作成する場合 、Kubernetes は各 ポッド に割り当てます FQDN 。またはCloud Manager MongoDB Ops Managerを更新するために、Kubernetes 演算子は各 ポッド の FQDN を計算します 指定されたクラスター名を使用します。Kubernetes では、これらのホスト名をクエリするためのAPIは提供されていません。

警告

Kubernetes クラスターに デフォルトのドメインspec.clusterDomain がある場合は、 を設定する必要があります デフォルトのcluster.local 以外。デフォルトを使用せず、 spec.clusterDomainオプションも設定しない場合、Kubernetes 演算子が期待どおりに機能しない可能性があります。

spec.connectivity.replicaSetHorizons

タイプ: コレクション

クライアント アプリケーションと MongoDB エージェントに対して異なるDNS設定を提供できます。 Kubernetes Operator は、レプリカセット ノードに スプリット ホライゾンDNSを使用します。 この機能により、Kubernetes クラスター内と Kubernetes 外部からの両方で通信が可能になります。

ホストごとに複数の外部マッピングを追加できます。

スプリットホライゾンの要件:

• この配列内の各値が一意であることを確認してください。

• この配列内のエントリ数がspec.membersの値と一致していることを確認します。

• TLSspec.security.certsSecretPrefix を有効にするには、 設定の値を指定します。このメソッドでスプリットホライズンを使用するには、 TLSプロトコルの サーバー名表示 拡張機能が必要です。

• 外部ホスト名のルーティングを構成します。

例

この例では、レプリカセットのメンバーはexample-localhostホライゾンで相互に通信します。 クライアントはexample-websiteホライゾンを使用してレプリカセットと通信します。

1
---
2
apiVersion: mongodb.com/v1
3
kind: MongoDB
4
metadata:
5
  name: <my-replica-set>
6
spec:
7
  members: 3
8
  version: "4.2.2-ent"
9
  type: ReplicaSet
10
  opsManager:
11
    configMapRef:
12
      name: <configMap.metadata.name>
13
  credentials: <mycredentials>
14
  persistent: true

15
  security:
16
    tls:
17
      enabled: true
18
  connectivity:
19
    replicaSetHorizons:
20
      - "example-website": "web1.example.com:30907"
21
      - "example-website": "web2.example.com:32350"
22
      - "example-website": "web3.example.com:31185"
23
...

spec.externalAccess.externalDomain

型: string

レプリカセットの配置を外部で公開するために使用される外部ドメイン。

デフォルトでは、各レプリカセット ノードは Kubernetes ポッドのFQDN （ *.svc.cluster.local ）をデフォルトのホスト名として使用します。 ただし、この設定に外部ドメインを追加すると、レプリカセットは代わりに、指定されたドメインのサブドメインであるホスト名を使用します。 このホスト名は、次の形式を使用します。

<replica-set-name>-<pod-idx>.<externalDomain>

以下に例を挙げます。

replica-set-1.example.com

この設定でレプリカセットを配置すると、 Kubernetes Operator は外部ドメインを含むホスト名を使用して、 MongoDB Ops Managerオートメーション構成の processes[n].hostname フィールドを上書きします。 次に、MongoDB Agent はこのホスト名を使用してmongodに接続します。

レプリカセットに接続するための他のホスト名を指定するには、 spec.connectivity.replicaSetHorizons設定を使用できます。 ただし、次の接続では、外部ドメインを含むホスト名は引き続き使用されます。

• mongodに接続する MongoDB Agent

• mongodを使用して他のmongodインスタンスに接続します。

警告:このフィールドを指定すると、 MongoDB Ops Managerがmongodプロセスを登録する方法が変更されます。 このフィールドは、Kubernetes Operator バージョン1.19以降の新しいレプリカセット配置でのみ指定できます。 実行中のレプリカセット配置のMongoDB Ops Manager自動化構成で、このフィールドまたは任意の processes[n].hostname フィールドの値を変更することはできません。

spec.members

タイプ: 整数

必須。 レプリカセットのノード数。

spec.memberConfig

タイプ: コレクション

MongoDBリソースから配置された各 MongoDB レプリカセット ノードの仕様。

配列内の要素の順序は、レプリカセット内のノードの順序を反映する必要があります。 たとえば、 配列の最初の要素はインデックス0の ポッドに影響し、2 番目の要素はインデックス1に影響するなどします。

例

3 つのノードからなるレプリカセットの次の仕様例を検討してみましょう。

spec:
  memberConfig:
    - votes: 1
      priority: "0.5"
      tags:
        tag1: "value1"
        environment: "prod"
    - votes: 1
      priority: "1.5"
      tags:
        tag2: "value2"
        environment: "prod"
    - votes: 0
      priority: "0.5"
      tags:
        tag2: "value2"
        environment: "prod"

spec.memberConfig.priority

型: string

MongoDB レプリカセットがプライマリ になる相対的な可能性を示す数値。

• レプリカセット メンバーがプライマリになる相対的な可能性を高めるには、 priorityの値を高く指定します。

• レプリカセット メンバーがプライマリになる相対的な可能性を減らすには、 priorityの値を低く指定します。

たとえば、 memberConfig.priorityが1.5のメンバーは、 memberConfig.priorityが0.5のメンバーよりも多く、プライマリになる可能性が高くなります。

かつmemberConfig.priorityが0のノードはプライマリになる資格がありません。 詳しくは、「メンバーの優先順位 」を参照してください。

spec.memberConfig.tags

タイプ: map

MongoDB レプリカセットの特定のノードに読み取りおよび書込み (write) 操作を指示するためのレプリカセット タグのマップ。

spec.memberConfig.votes

タイプ: 数値

MongoDB レプリカセットのメンバーが選挙で投票できるかどうかを決定します。 メンバーに投票を許可するには を1に設定します。 ノードを選挙から除外するには、 0に設定します。

次の設定はレプリカセットのリソースタイプにのみ適用されます。

spec.backup.autoTerminateOnDeletion

タイプ: ブール値

MongoDB リソースを削除するときに Kubernetes Operator がバックアップを停止して終了するかどうかを制御するフラグ。 省略した場合、デフォルト値はfalseです。 このフラグをtrueに設定すると、 spec.backup.mode設定がenabledに設定されているときに MongoDB カスタム リソースを削除する場合に便利です。

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

次の設定は、シャーディングされたクラスターのリソース タイプにのみ適用されます。

spec.backup.snapshotSchedule.clusterCheckpointIntervalMin

タイプ: 数値

連続するクラスター チェックポイント間の分数。 この設定は、 MongoDBを機能の互換性バージョン4.0またはそれ以前のバージョンで実行するシャーディングされたクラスターにのみ適用されます。 この数値により、シャーディングされたクラスターのポイントインタイム復元の粒度が決まります。 15 、 30 、または60の値を設定できます。

spec.configServerCount

タイプ: 整数

必須。 コンフィギュレーションサーバー内のメンバーの数。

spec.configSrv.additionalMongodConfig

タイプ: コレクション

各コンフィギュレーション サーバー ノード を起動するための追加 構成オプション 。

Kubernetes Operator は、MongoDB Agent を通じて配置する MongoDB バージョンがサポートするすべての構成オプションをサポートしています。ただし、Kubernetes Operator は、次のいずれかのオプションに指定した値を上書きします。

• net.tls.certificateKeyFile

• net.tls.clusterFile

• replication.replSetName

• security.clusterAuthMode

• sharding.clusterRole

• storage.dbPath

• systemLog.destination

• systemLog.path

Kubernetes Operator が所有する構成オプションの詳細については、「 MongoDB Kubernetes Operator 専用設定 」を参照してください。

使用できる構成オプションについては、 MongoDBドキュメントの「 配置の詳細オプションMongoDB Ops Manager 」を 参照してください。

spec.configSrv.agent

タイプ: コレクション

各コンフィギュレーションサーバーノードの MongoDB Agent 構成設定。

spec.configSrv.agent.startupOptions

タイプ: コレクション

各コンフィギュレーションサーバー ノードを起動する MongoDB Agent 設定。

MongoDB Agent 設定はキーと値のペアとして提供する必要があります。 値は文字列である必要があります。

サポートされている MongoDB Agent 設定のリストについては、以下を参照してください。

• Cloud Manager プロジェクトのMongoDB Agent 設定。

• OperatorMongoDB Agent を使用して配置したMongoDB Ops Manager バージョンの 設定 。Kubernetes

1
---
2
apiVersion: mongodb.com/v1
3
kind: MongoDB
4
metadata:
5
  name: my-sharded-cluster-options
6
spec:
7
  version: "6.0.0-ent"
8
  type: ShardedCluster
9
  opsManager:
10
    configMapRef:
11
      name: my-project
12
  credentials: my-credentials
13
  persistent: true
14
  shardCount: 2
15
  mongodsPerShardCount: 3
16
  mongosCount: 2
17
  configServerCount: 1
18
19
  mongos:
20
    agent:
21
      startupOptions:
22
        maxLogFiles: "30"
23
24
  configSrv:
25
     agent:
26
       startupOptions:
27
         dialTimeoutSeconds: "40"
28
  shard:
29
     agent:
30
       startupOptions:
31
         serverSelectionTimeoutSeconds: "20"
32
...

spec.configSrvPodSpec

型: オブジェクト

MongoDB CustomResourceDefinition の仕様を含むオブジェクト コンフィギュレーションサーバー ポッド。

spec.configSrvPodSpec.persistence.single

タイプ: コレクション

Kubernetes Operator が 1 つの 永続ボリューム要求 を作成するようにします と では、データ、ジャーナル、ログの 3 つのすべてのディレクトリが同じ 永続ボリューム にマウントされます。 。

注意

• spec.persistent : trueの場合は、このコレクションに値を設定する必要があります。

• このコレクションまたはpersistence.multipleコレクションを設定できますが、両方は設定できません。

スカラー	データ型	説明
labelSelector	string	タグ マウントされたボリュームをディレクトリにバインドするために使用されます。
storage	string	永続ボリューム の最小サイズ マウントする必要があるもの。この値は、 JEDEC表記では、整数とそれに続くストレージの単位として表されます。 デフォルト値は 5Gi です。 たとえば、 の各コンフィギュレーションサーバー ノードに60ギガバイトのストレージ容量が必要な場合は、この値を60Giに設定します。
storageClass	string	永続的なボリューム要求 で指定されるストレージのタイプ 。このストレージ タイプは、 StorageClass として作成できます。 この オブジェクト で使用する前にオブジェクトを 仕様。 StorageClass を必ず設定してください 保持 するreclaimPolicy 。これにより、 永続的なボリューム要求 が発生した場合にデータが保持できます は削除されます。

spec.configSrvPodSpec.persistence.multiple.data

タイプ: コレクション

Kubernetes Operator が 永続的なボリューム要求 を作成するようにします と は、データのディレクトリを独自の 永続ボリューム にマウントします。 。

注意

• spec.persistent : trueの場合は、このコレクションに値を設定する必要があります。

• このコレクションまたはpersistence.singleコレクションを設定できますが、両方を設定することはできません。

スカラー	データ型	説明
labelSelector	string	タグ マウントされたボリュームをディレクトリにバインドするために使用されます。
storage	string	Kubernetes ノード で使用可能である必要がある最小ストレージ容量 は、Kubernetes で各コンフィギュレーション サーバー ノード をホストします。この値は、 JEDEC表記では、整数とそれに続くストレージの単位として表されます。 デフォルト値は 16Gi です。 たとえば、このMongoDBリソースに60ギガバイトのストレージ容量が必要な場合は、この値を60Giに設定します。
storageClass	string	各コンフィギュレーションサーバー ノードに必要なストレージのタイプ。 このストレージ タイプは、 StorageClass として作成できます。 この オブジェクト で使用する前にオブジェクトを 仕様。 StorageClass を必ず設定してください 保持 するreclaimPolicy 。これにより、 永続的なボリューム要求 が発生した場合にデータが保持できます は削除されます。

spec.configSrvPodSpec.persistence.multiple.journal

タイプ: コレクション

Kubernetes Operator が 永続的なボリューム要求 を作成するようにします およびジャーナル用のディレクトリを独自の 永続ボリューム にマウントする 。

注意

• spec.persistent : trueの場合は、このコレクションに値を設定する必要があります。

• このコレクションまたはpersistence.singleコレクションを設定できますが、両方を設定することはできません。

スカラー	データ型	説明
labelSelector	string	タグ マウントされたボリュームをディレクトリにバインドするために使用されます。
storage	string	Kubernetes ノード で使用可能である必要がある最小ストレージ容量 は、Kubernetes で各コンフィギュレーション サーバー ノード をホストします。この値は、 JEDEC表記では、整数とそれに続くストレージの単位として表されます。 デフォルト値は 1Gi です。 たとえば、このMongoDBリソースに60ギガバイトのストレージ容量が必要な場合は、この値を60Giに設定します。
storageClass	string	各コンフィギュレーションサーバー ノードに必要なストレージのタイプ。 このストレージ タイプは、 StorageClass として作成できます。 この オブジェクト で使用する前にオブジェクトを 仕様。 StorageClass を必ず設定してください 保持 するreclaimPolicy 。これにより、 永続的なボリューム要求 が発生した場合にデータが保持できます は削除されます。

spec.configSrvPodSpec.persistence.multiple.logs

タイプ: コレクション

Kubernetes Operator が 永続的なボリューム要求 を作成するようにします および は、ログ用のディレクトリを独自の 永続ボリューム にマウントします。 。

注意

• spec.persistent : trueの場合は、このコレクションに値を設定する必要があります。

• このコレクションまたはpersistence.singleコレクションを設定できますが、両方を設定することはできません。

スカラー	データ型	説明
labelSelector	string	タグ マウントされたボリュームをディレクトリにバインドするために使用されます。
storage	string	Kubernetes ノード で使用可能である必要がある最小ストレージ容量 は、Kubernetes で各コンフィギュレーション サーバー ノード をホストします。この値は、 JEDEC表記では、整数とそれに続くストレージの単位として表されます。 デフォルト値は 3Gi です。 たとえば、このMongoDBリソースに60ギガバイトのストレージ容量が必要な場合は、この値を60Giに設定します。
storageClass	string	各コンフィギュレーションサーバー ノードに必要なストレージのタイプ。 このストレージ タイプは、 StorageClass として作成できます。 この オブジェクト で使用する前にオブジェクトを 仕様。 StorageClass を必ず設定してください 保持 するreclaimPolicy 。これにより、 永続的なボリューム要求 が発生した場合にデータが保持できます は削除されます。

spec.configSrvPodSpec.podTemplate

タイプ: コレクション

テンプレート MongoDB Enterprise Kubernetes Operator が各コンフィギュレーション サーバー ノード に対して作成する Kubernetes ポッド用。

テンプレート値は、 spec.configSrvPodSpecで指定された値よりも優先されます。

注意

Kubernetes 演算子は、 spec.configSrvPodSpec.podTemplateで指定したフィールドを検証しません。

spec.configSrvPodSpec.podTemplate.affinity.podAffinity

タイプ: コレクション

Kubernetes ルール 複数のMongoDB リソース ポッド かどうかを判断 は他の ポッド と同じ場所に配置する必要があります 。ユースケースの詳細については、「 アフィニティと非アフィニティ 」を参照してください。 （Kubernetes ドキュメント）。

spec.configSrvPodSpec.podTemplate.affinity.nodeAffinity

タイプ: コレクション

Kubernetes ルール : ポッド を配置する 特定の範囲の ノード 上の レプリカセット 用 。

読み取りおよび書込みパフォーマンスを最適化するには、ノードの アフィニティ ルールを使用してノードを制限します 特定の ノード 上で を実行する 、または特定の ノード で の実行を優先する場合は 。

spec.configSrvPodSpec.podTemplate.affinity.podAntiAffinity

型: string

Default: kubernetes.io/hostname

ルールMongoDB を設定する ポッド を分散する リソースを異なる場所でホストする。ロケーションは、単一のノード、ロック、またはリージョンにすることができます。 デフォルトでは、Kubernetes Operator は異なるノードにポッドを分散しようとします。

spec.configSrvPodSpec.podTemplate.affinity.podAntiAffinity.requiredDuringSchedulingIgnoredDuringExecution.topologyKey

型: string

Default: kubernetes.io/hostname

このキーは、どの ラベル を定義しますか どのトポロジー ドメイン を決定するために使用されるか ノードが属する。

spec.configSrvPodSpec.podTemplate.metadata

タイプ: コレクション

MongoDB Enterprise Kubernetes Operator が各コンフィギュレーションサーバー ノードに対して作成する Kubernetes ポッドのメタデータ。

spec.configSrvPodSpec.podTemplate.metadataに追加できるフィールドを確認するには、 Kubernetes のドキュメント を参照してください。

spec.configSrvPodSpec.podTemplate.spec

タイプ: コレクション

MongoDB Enterprise Kubernetes Operator が各コンフィギュレーションサーバー ノードに対して作成する Kubernetes ポッドの仕様。

spec.configSrvPodSpec.podTemplate.specに追加できるフィールドを確認するには、Kubernetes PodSpec v1Core API を参照してください。

注意

spec.configSrvPodSpec.podTemplate.spec.containersにコンテナを追加すると、Kubernetes Operator はそれらを Kubernetes ポッドに追加します。 これらのコンテナは、ポッド内の各コンフィギュレーションサーバー ノードコンテナに追加されます。

この設定を使用して、各ポッドの CPU と RAM の割り当てを指定します。 例について Githubは、 のサンプルを参照してください。

spec.mongodsPerShardCount

タイプ: 整数

必須。 シャードあたりのメンバー数。

spec.mongosCount

タイプ: 整数

必須。 シャーディングされた mongosクラスター内 の インスタンスの数。

spec.mongos.additionalMongodConfig

タイプ: コレクション

各 mongos インスタンスを起動するための追加 構成オプション 。

Kubernetes Operator は、MongoDB Agent を通じて配置する MongoDB バージョンがサポートするすべての構成オプションをサポートしています。ただし、Kubernetes Operator は、次のいずれかのオプションに指定した値を上書きします。

• net.tls.certificateKeyFile

• net.tls.clusterFile

• replication.replSetName

• security.clusterAuthMode

• sharding.clusterRole

• storage.dbPath

• systemLog.destination

• systemLog.path

Kubernetes Operator が所有する構成オプションの詳細については、「 MongoDB Kubernetes Operator 専用設定 」を参照してください。

使用できる構成オプションについては、 MongoDBドキュメントの「 配置の詳細オプションMongoDB Ops Manager 」を 参照してください。

spec.mongos.agent

タイプ: コレクション

各mongosインスタンスの MongoDB Agent 構成設定。

spec.mongos.agent.startupOptions

タイプ: コレクション

各mongosインスタンスの起動に使用する MongoDB Agent 設定。

MongoDB Agent 設定はキーと値のペアとして提供する必要があります。 値は文字列である必要があります。

サポートされている MongoDB Agent 設定のリストについては、以下を参照してください。

• Cloud Manager プロジェクトのMongoDB Agent 設定。

• OperatorMongoDB Agent を使用して配置したMongoDB Ops Manager バージョンの 設定 。Kubernetes

1
---
2
apiVersion: mongodb.com/v1
3
kind: MongoDB
4
metadata:
5
  name: my-sharded-cluster-options
6
spec:
7
  version: "6.0.0-ent"
8
  type: ShardedCluster
9
  opsManager:
10
    configMapRef:
11
      name: my-project
12
  credentials: my-credentials
13
  persistent: true
14
  shardCount: 2
15
  mongodsPerShardCount: 3
16
  mongosCount: 2
17
  configServerCount: 1
18
19
  mongos:
20
    agent:
21
      startupOptions:
22
        maxLogFiles: "30"
23
24
  configSrv:
25
     agent:
26
       startupOptions:
27
         dialTimeoutSeconds: "40"
28
  shard:
29
     agent:
30
       startupOptions:
31
         serverSelectionTimeoutSeconds: "20"
32
...

spec.mongosPodSpec

型: オブジェクト

MongoDB CustomResourceDefinition の仕様を含むオブジェクト mongos ポッド。

spec.mongosPodSpec.podTemplate

タイプ: コレクション

テンプレート MongoDB Enterprise Kubernetes Operator が各 インスタンスに対して作成する Kubernetesmongos ポッドの場合、

テンプレート値は、 spec.mongosPodSpecで指定された値よりも優先されます。

注意

Kubernetes 演算子は、 spec.mongosPodSpec.podTemplateで指定したフィールドを検証しません。

spec.mongosPodSpec.podTemplate.affinity.podAffinity

タイプ: コレクション

任意。 Kubernetes ルール 複数のMongoDB リソース ポッド かどうかを判断する は他の ポッド と同じ場所に配置する必要があります 。

spec.mongosPodSpec.podTemplate.affinity.nodeAffinity

タイプ: コレクション

Kubernetes ルール : ポッド を配置する 特定の範囲の ノード 上の レプリカセット 用 。

読み取りおよび書込みパフォーマンスを最適化するには、ノードの アフィニティ ルールを使用してノードを制限します 特定の ノード 上で を実行する 、または特定の ノード で の実行を優先する場合は 。

spec.mongosPodSpec.podTemplate.affinity.podAntiAffinity

型: string

Default: kubernetes.io/hostname

ルールMongoDB を設定する ポッド を分散する リソースを異なる場所でホストする。ロケーションは、単一のノード、ロック、またはリージョンにすることができます。 デフォルトでは、Kubernetes Operator は異なるノードにポッドを分散しようとします。

spec.mongosPodSpec.podTemplate.affinity.podAntiAffinity.requiredDuringSchedulingIgnoredDuringExecution.topologyKey

型: string

Default: kubernetes.io/hostname

このキーは、どの ラベル を定義しますか どのトポロジー ドメイン を決定するために使用されるか ノードが属する。

spec.mongosPodSpec.podTemplate.metadata

タイプ: コレクション

MongoDB Enterprise Kubernetes Operator が各mongosインスタンスに対して作成する Kubernetes ポッドのメタデータ。

spec.mongosPodSpec.podTemplate.metadataに追加できるフィールドを確認するには、 Kubernetes のドキュメント を参照してください。

spec.mongosPodSpec.podTemplate.spec

タイプ: コレクション

MongoDB Enterprise Kubernetes Operator が各mongosインスタンスに対して作成する Kubernetes ポッドの仕様。

spec.mongosPodSpec.podTemplate.specに追加できるフィールドを確認するには、Kubernetes PodSpec v1Core API を参照してください。

注意

spec.mongosPodSpec.podTemplate.spec.containersにコンテナを追加すると、Kubernetes Operator はそれらを Kubernetes ポッドに追加します。 これらのコンテナは、ポッド内の各mongosインスタンス コンテナに追加されます。

この設定を使用して、各ポッドの CPU と RAM の割り当てを指定します。 例について Githubは、 のサンプルを参照してください。

spec.shardCount

タイプ: 整数

必須。 シャーディングされたクラスター内の シャード の数。

spec.shard.additionalMongodConfig

タイプ: コレクション

各シャーディングされた クラスター のシャード ノードを起動するための追加 構成オプション 。

Kubernetes Operator は、MongoDB Agent を通じて配置する MongoDB バージョンがサポートするすべての構成オプションをサポートしています。ただし、Kubernetes Operator は、次のいずれかのオプションに指定した値を上書きします。

• net.tls.certificateKeyFile

• net.tls.clusterFile

• replication.replSetName

• security.clusterAuthMode

• sharding.clusterRole

• storage.dbPath

• systemLog.destination

• systemLog.path

Kubernetes Operator が所有する構成オプションの詳細については、「 MongoDB Kubernetes Operator 専用設定 」を参照してください。

使用できる構成オプションについては、 MongoDBドキュメントの「 配置の詳細オプションMongoDB Ops Manager 」を 参照してください。

spec.shard.agent

タイプ: コレクション

各シャーディングされたクラスターのシャード ノードの MongoDB Agent の構成設定。

spec.shard.agent.startupOptions

タイプ: コレクション

各シャーディングされたクラスターのシャード ノードを起動する MongoDB Agent 設定。

MongoDB Agent 設定はキーと値のペアとして提供する必要があります。 値は文字列である必要があります。

サポートされている MongoDB Agent 設定のリストについては、以下を参照してください。

• Cloud Manager プロジェクトのMongoDB Agent 設定。

• OperatorMongoDB Agent を使用して配置したMongoDB Ops Manager バージョンの 設定 。Kubernetes

1
---
2
apiVersion: mongodb.com/v1
3
kind: MongoDB
4
metadata:
5
  name: my-sharded-cluster-options
6
spec:
7
  version: "6.0.0-ent"
8
  type: ShardedCluster
9
  opsManager:
10
    configMapRef:
11
      name: my-project
12
  credentials: my-credentials
13
  persistent: true
14
  shardCount: 2
15
  mongodsPerShardCount: 3
16
  mongosCount: 2
17
  configServerCount: 1
18
19
  mongos:
20
    agent:
21
      startupOptions:
22
        maxLogFiles: "30"
23
24
  configSrv:
25
     agent:
26
       startupOptions:
27
         dialTimeoutSeconds: "40"
28
  shard:
29
     agent:
30
       startupOptions:
31
         serverSelectionTimeoutSeconds: "20"
32
...

spec.shardPodSpec

型: オブジェクト

MongoDB CustomResourceDefinition の仕様を含むオブジェクト シャード ポッド。

spec.shardPodSpec.persistence.multiple.data

タイプ: コレクション

Kubernetes Operator が 永続的なボリューム要求 を作成するようにします と は、データのディレクトリを独自の 永続ボリューム にマウントします。 。

注意

• spec.persistent : trueの場合は、このコレクションに値を設定する必要があります。

• このコレクションまたはpersistence.singleコレクションを設定できますが、両方を設定することはできません。

スカラー	データ型	説明
labelSelector	string	タグ マウントされたボリュームをディレクトリにバインドするために使用されます。
storage	string	Kubernetes ノード で使用可能である必要がある最小ストレージ容量 各シャーディングされた クラスター のシャード ノードを Kubernetes でホストします。この値は、 JEDEC表記では、整数とそれに続くストレージの単位として表されます。 デフォルト値は 16Gi です。 たとえば、このMongoDBリソースに60ギガバイトのストレージ容量が必要な場合は、この値を60Giに設定します。
storageClass	string	各シャーディングされたクラスターのシャード ノードに必要なストレージのタイプ。 このストレージ タイプは、 StorageClass として作成できます。 この オブジェクト で使用する前にオブジェクトを 仕様。 StorageClass を必ず設定してください 保持 するreclaimPolicy 。これにより、 永続的なボリューム要求 が発生した場合にデータが保持できます は削除されます。

spec.shardPodSpec.persistence.multiple.journal

タイプ: コレクション

Kubernetes Operator が 永続的なボリューム要求 を作成するようにします およびジャーナル用のディレクトリを独自の 永続ボリューム にマウントする 。

注意

• spec.persistent : trueの場合は、このコレクションに値を設定する必要があります。

• このコレクションまたはpersistence.singleコレクションを設定できますが、両方を設定することはできません。

スカラー	データ型	説明
labelSelector	string	タグ マウントされたボリュームをディレクトリにバインドするために使用されます。
storage	string	Kubernetes ノード で使用可能である必要がある最小ストレージ容量 各シャーディングされた クラスター のシャード ノードを Kubernetes でホストします。この値は、 JEDEC表記では、整数とそれに続くストレージの単位として表されます。 デフォルト値は 1Gi です。 たとえば、このMongoDBリソースに60ギガバイトのストレージ容量が必要な場合は、この値を60Giに設定します。
storageClass	string	各シャーディングされたクラスターのシャード ノードに必要なストレージのタイプ。 このストレージ タイプは、 StorageClass として作成できます。 この オブジェクト で使用する前にオブジェクトを 仕様。 StorageClass を必ず設定してください 保持 するreclaimPolicy 。これにより、 永続的なボリューム要求 が発生した場合にデータが保持できます は削除されます。

spec.shardPodSpec.persistence.multiple.logs

タイプ: コレクション

Kubernetes Operator が 永続的なボリューム要求 を作成するようにします および は、ログ用のディレクトリを独自の 永続ボリューム にマウントします。 。

注意

• spec.persistent : trueの場合は、このコレクションに値を設定する必要があります。

• このコレクションまたはpersistence.singleコレクションを設定できますが、両方を設定することはできません。

スカラー	データ型	説明
labelSelector	string	タグ マウントされたボリュームをディレクトリにバインドするために使用されます。
storage	string	Kubernetes ノード で使用可能である必要がある最小ストレージ容量 各シャーディングされた クラスター のシャード ノードを Kubernetes でホストします。この値は、 JEDEC表記では、整数とそれに続くストレージの単位として表されます。 デフォルト値は 3Gi です。 たとえば、このMongoDBリソースに60ギガバイトのストレージ容量が必要な場合は、この値を60Giに設定します。
storageClass	string	各シャーディングされたクラスターのシャード ノードに必要なストレージのタイプ。 このストレージ タイプは、 StorageClass として作成できます。 この オブジェクト で使用する前にオブジェクトを 仕様。 StorageClass を必ず設定してください 保持 するreclaimPolicy 。これにより、 永続的なボリューム要求 が発生した場合にデータが保持できます は削除されます。

spec.shardPodSpec.podTemplate

タイプ: コレクション

テンプレート MongoDB Enterprise Kubernetes Operator が各シャーディングされ たクラスター のシャード ノードに対して作成する Kubernetes ポッド用。

テンプレート値は、 spec.shardPodSpecで指定された値よりも優先されます。

注意

Kubernetes 演算子は、 spec.shardPodSpec.podTemplateで指定したフィールドを検証しません。

spec.shardPodSpec.podTemplate.affinity.podAffinity

型: string

Kubernetes ルール 複数のMongoDB リソース ポッド かどうかを判断 は他の ポッド と同じ場所に配置する必要があります 。ユースケースの詳細については、「 アフィニティと非アフィニティ 」を参照してください。 （Kubernetes ドキュメント）。

spec.shardPodSpec.podTemplate.affinity.nodeAffinity

型: string

Kubernetes ルール : ポッド を配置する 特定の範囲の ノード 上の レプリカセット 用 。

読み取りおよび書込みパフォーマンスを最適化するには、ノードの アフィニティ ルールを使用してノードを制限します 特定の ノード 上で を実行する 、または特定の ノード で の実行を優先する場合は 。

spec.shardPodSpec.podTemplate.affinity.podAntiAffinity

型: string

Default: kubernetes.io/hostname

ルールMongoDB を設定する ポッド を分散する リソースを異なる場所でホストする。ロケーションは、単一のノード、ロック、またはリージョンにすることができます。 デフォルトでは、Kubernetes Operator は異なるノードにポッドを分散しようとします。

spec.shardPodSpec.podTemplate.affinity.podAntiAffinity.requiredDuringSchedulingIgnoredDuringExecution.topologyKey

型: string

Default: kubernetes.io/hostname

このキーは、どの ラベル を定義しますか どのトポロジー ドメイン を決定するために使用されるか ノードが属する。

spec.shardPodSpec.podTemplate.metadata

タイプ: コレクション

MongoDB Enterprise Kubernetes Operator が各シャーディングされたクラスターのシャード ノードに対して作成する Kubernetes ポッドのメタデータ。

spec.shardPodSpec.podTemplate.metadataに追加できるフィールドを確認するには、 Kubernetes のドキュメント を参照してください。

spec.shardPodSpec.podTemplate.spec

タイプ: コレクション

MongoDB Enterprise Kubernetes Operator が各シャーディングされたクラスターのシャード ノードに対して作成する Kubernetes ポッドの仕様。

spec.shardPodSpec.podTemplate.specに追加できるフィールドを確認するには、Kubernetes PodSpec v1Core API を参照してください。

注意

spec.shardPodSpec.podTemplate.spec.containersにコンテナを追加すると、Kubernetes Operator はそれらを Kubernetes ポッドに追加します。 これらのコンテナは、ポッド内の各シャーディングされたクラスターのシャード ノードのコンテナに追加されます。

この設定を使用して、各ポッドの CPU と RAM の割り当てを指定します。 例について Githubは、 のサンプルを参照してください。

spec.shardSpecificPodSpec

タイプ: 配列

ステートメント を含むリスト は、シャードごとに上書きします。

spec.shardSpecificPodSpec.podTemplate

タイプ: コレクション

テンプレート MongoDB Enterprise Kubernetes Operator が特定のシャードに対して作成する Kubernetes ポッド用。

テンプレート値は、 spec.shardSpecificPodSpecで指定された値よりも優先されます。

注意

Kubernetes 演算子は、 spec.shardSpecificPodSpec.podTemplateで指定したフィールドを検証しません。

spec.shardSpecificPodSpec.podTemplate.affinity.podAffinity

型: string

Kubernetes ルール 複数のMongoDB リソース ポッド かどうかを判断 は他の ポッド と同じ場所に配置する必要があります 。ユースケースの詳細については、「 アフィニティと非アフィニティ 」を参照してください。 （Kubernetes ドキュメント）。

spec.shardSpecificPodSpec.podTemplate.affinity.podAntiAffinity

型: string

Default: kubernetes.io/hostname

ルールMongoDB を設定する ポッド を分散する リソースを異なる場所でホストする。ロケーションは、単一のノード、ロック、またはリージョンにすることができます。 デフォルトでは、Kubernetes Operator は異なるノードにポッドを分散しようとします。

spec.shardSpecificPodSpec.podTemplate.affinity.podAntiAffinity.requiredDuringSchedulingIgnoredDuringExecution.topologyKey

型: string

Default: kubernetes.io/hostname

このキーは、どの ラベル を定義しますか どのトポロジー ドメイン を決定するために使用されるか ノードが属する。

spec.shardSpecificPodSpec.podTemplate.metadata

タイプ: コレクション

MongoDB Enterprise Kubernetes Operator が特定のシャードに対して作成する Kubernetes ポッドのメタデータ。

spec.shardSpecificPodSpec.podTemplate.metadataに追加できるフィールドを確認するには、 Kubernetes のドキュメント を参照してください。

spec.shardSpecificPodSpec.podTemplate.spec

タイプ: コレクション

MongoDB Enterprise Kubernetes Operator が特定のシャードに対して作成する Kubernetes ポッドの仕様。

spec.shardSpecificPodSpec.podTemplate.specに追加できるフィールドを確認するには、Kubernetes PodSpec v1Core API を参照してください。

注意

spec.shardSpecificPodSpec.podTemplate.spec.containersにコンテナを追加すると、Kubernetes Operator はそれらを Kubernetes ポッドに追加します。 これらのコンテナは、ポッド内の特定のシャード コンテナに追加されます。

この設定を使用して、各ポッドの CPU と RAM の割り当てを指定します。 例について Githubは、 のサンプルを参照してください。

spec.topology

型: string

任意

デフォルト: SingleCluster

シャーディングされたシャーディングされたクラスターのトポロジーを定義します。 既存の配置では変更できません。 MultiClusterに設定されている場合:

• すべてのシャーディングされたクラスターコンポーネントにはclusterSpecListが定義されている必要があります: - spec.mongos.clusterSpecList - spec.configSrv.clusterSpecList - spec.shard.clusterSpecList

• 次のフィールドは無視され、 spec.<section>.clusterSpecListオブジェクト内の各クラスターに同等の値が渡されます。- spec.mongodsPerShardCountはspec.shard.clusterSpecList.membersで定義されています - spec.mongosCountはspec.mongos.clusterSpecList.membersで定義されています - spec.configServerCountはspec.configSrv.clusterSpecList.membersで定義されています。 - spec.shardOverrides.memberConfigはspec.shardOverrides.clusterSpecList.memberConfigで定義されています - spec.shardOverrides.membersはspec.shardOverrides.clusterSpecList.membersで定義されています - spec.shardOverrides.statefulSetはspec.shardOverrides.clusterSpecList.statefulSetで定義されています

例:

apiVersion: mongodb.com/v1
kind: MongoDB
metadata:
  name: sc
spec:
  shardCount: 3
  # we don't specify mongodsPerShardCount, mongosCount and configServerCount as they don't make sense for multi-cluster
  topology: MultiCluster
  type: ShardedCluster
  version: 7.0.12
  cloudManager:
    configMapRef:
      name: my-project
  credentials: my-credentials
  persistent: true
  shard:
    clusterSpecList:
      - clusterName: member-cluster-0
        members: 2 # each shard will have 2 members in cluster 0, unless overriden
      - clusterName: member-cluster-1
        members: 2
      - clusterName: member-cluster-2
        members: 1
  shardOverrides:
    - shardNames: [sc-2] # this override will apply to the third shard (here, shards are indexed from 0 to 2 as we have 3 shards)
      clusterSpecList:
        - clusterName: member-cluster-0 # all other fields are optional, if not provided the fields from matching member cluster from shard.clusterSpecList will be taken by default
          members: 3
        - clusterName: member-cluster-1 # we don't deploy this shard to member-cluster-1
          # Note that it is also possible to make it explicit with members: 0
        # we don't provide entry for clusterName: member-cluster-1, so it won't be deployed there
        - clusterName: member-cluster-2
          members: 2
  configSrv:
    clusterSpecList:
      - clusterName: member-cluster-0
        members: 2 # config server will have 2 members in this cluster
      - clusterName: member-cluster-1
        members: 1
      - clusterName: member-cluster-2
        members: 2
  mongos:
    clusterSpecList:
      - clusterName: member-cluster-0
        members: 2 # router will have 2 members in this cluster
      - clusterName: member-cluster-1
        members: 1

次のフィールドは、 topology=MultiClusterが実行される配置にのみ関連します。

spec.configSrv.clusterSpecList

注意

このフィールドは、マルチクラスターのシャーディングされたクラスターの配置でのみ使用できます。これらは現在public preview段階です。

タイプ: オブジェクトの配列

必須topology=MultiClusterの場合）

次の最上位フィールドを持つマルチクラスターのシャーディングされたクラスター配置で使用するオブジェクトの配列。

clusterName

型: string

MongoDB Enterprise Kubernetes Operator が ステートメント をスケジュールするクラスターの名前 。

externalAccess

タイプ: コレクション

マルチ Kubernetes クラスター MongoDB 配置を外部接続用に公開するための仕様。 Kubernetes クラスターの外部からマルチ Kubernetes クラスター MongoDB 配置に接続する方法については、「 Kubernetes 外部からマルチクラスター リソースに接続する 」を参照してください。

これらの設定は、すべてのクラスターのサービスに適用されます。 特定のクラスターでこれらのグローバル設定をオーバーライドするには、 spec.clusterSpecList.externalAccess.externalService を使用します。

spec.externalAccessを追加すると、Kubernetes Operator はレプリカセット内の各ポッドの外部サービスを作成します。 外部サービスは、クラスター内の各 MongoDB database ポッドの外部エントリ ポイントを提供します。 各外部サービスには セレクター があります は、外部サービスを特定のポッドに一致させます。

値なしでこの設定を追加すると、Kubernetes Operator は次のデフォルト値を持つ外部サービスを作成します。

フィールド	値	説明
Name	<pod-name>-svc-external	外部サービスの名前。 この値は変更できません。
Type	LoadBalancer	外部 LoadBalancer を作成します service
Port	<Port Number>	mongodのポート。
publishNotReadyAddress	true	DNS レコード を指定する は、Ped が準備ができていない場合でも作成されます。どのデータベース ポッドでもfalseに設定しないでください。

注意

spec.clusterSpecList.externalAccess.externalDomainを設定すると、外部サービスはバックアップ用の別のポート（ Port Number + 1 ）を追加します。

members

タイプ: 数値

MongoDB レプリカセット内のノードの数。

memberConfig

タイプ: コレクション

マルチ Kubernetes クラスターMongoDBデプロイ内の各MongoDBシャードとそのノードの仕様。

シャードのオブジェクト内の要素の順序は、レプリカセット内のノードの順序を反映する必要があります。 例、最初の要素はインデックス0の ポッドに影響し、2 番目の要素はインデックス1に影響するなど、 に影響します。

例

3 つのレプリカ セットを含むマルチ Kubernetes クラスター MongoDB 配置の次の例の仕様を検討してみましょう。

apiVersion: mongodb.com/v1
kind: MongoDBMultiCluster
metadata:
  name: multi-replica-set
spec:
  version: 6.0.0-ent
  type: ReplicaSet
  duplicateServiceObjects: false
  credentials: my-credentials
  opsManager:
    configMapRef:
      name: my-project
  clusterSpecList:
    - clusterName: cluster1.example.com
      members: 2
      memberConfig:
          - votes: 1
            priority: "0.5"
            tags:
                tag1: "value1"
                environment: "prod"
          - votes: 1
            priority: "1.5"
            tags:
                  tag2: "value2"
                  environment: "prod"
    - clusterName: cluster2.example.com
      members: 1
      memberConfig:
          - votes: 1
            priority: "0.5"
            tags:
                tag1: "value1"
                environment: "prod"
    - clusterName: cluster3.example.com
      members: 1
      memberConfig:
          - votes: 1
            priority: "0.5"
            tags:
                tag1: "value1"
                environment: "prod"

podSpec.persistence

タイプ: コレクション

spec.configSrv.clusterSpecListとspec.shard.clusterSpecListに渡されるclusterSpecItemオブジェクトでのみ利用可能。 特定のクラスターの既存の永続化構成を上書きします。

statefulSet

タイプ: コレクション

ステートフルセット の構成を提供します マルチ Kubernetes クラスターMongoDBデプロイにおけるクラスターの各ステートメントセットの オーバーライド。マルチ Kubernetes クラスターMongoDBデプロイ内のすべてのクラスターに適用されるグローバル構成を設定するには、 spec.status.spec を参照してください。

この設定は、マルチ Kubernetes クラスター MongoDB 配置のレプリカセット リソース タイプにのみ適用されます。

spec.duplicateServiceObjects

注意

このフィールドは、マルチクラスターのシャーディングされたクラスターの配置でのみ使用できます。これらは現在public preview段階です。

タイプ: ブール値

任意

デフォルト: true

トポロジーがMultiClusterでない場合は無視されます。 すべてのシャーディングされたクラスターコンポーネントのサービスに適用されます（ mongos 、 configSrv 、 shards 。

trueに設定されている場合:

Kubernetes演算子は、各ノード クラスター内のすべてのノード クラスターからすべてのPod Servicesを作成します。

falseに設定されている場合:

Kubernetes演算子は、次のみを作成します:

spec.mongos.clusterSpecList

注意

このフィールドは、マルチクラスターのシャーディングされたクラスターの配置でのみ使用できます。これらは現在public preview段階です。

タイプ: オブジェクトの配列

必須topology=MultiClusterの場合）

次の最上位フィールドを持つマルチクラスターのシャーディングされたクラスター配置で使用するオブジェクトの配列。

clusterName

型: string

MongoDB Enterprise Kubernetes Operator が ステートメント をスケジュールするクラスターの名前 。

externalAccess

タイプ: コレクション

マルチ Kubernetes クラスター MongoDB 配置を外部接続用に公開するための仕様。 Kubernetes クラスターの外部からマルチ Kubernetes クラスター MongoDB 配置に接続する方法については、「 Kubernetes 外部からマルチクラスター リソースに接続する 」を参照してください。

これらの設定は、すべてのクラスターのサービスに適用されます。 特定のクラスターでこれらのグローバル設定をオーバーライドするには、 spec.clusterSpecList.externalAccess.externalService を使用します。

spec.externalAccessを追加すると、Kubernetes Operator はレプリカセット内の各ポッドの外部サービスを作成します。 外部サービスは、クラスター内の各 MongoDB database ポッドの外部エントリ ポイントを提供します。 各外部サービスには セレクター があります は、外部サービスを特定のポッドに一致させます。

値なしでこの設定を追加すると、Kubernetes Operator は次のデフォルト値を持つ外部サービスを作成します。

フィールド	値	説明
Name	<pod-name>-svc-external	外部サービスの名前。 この値は変更できません。
Type	LoadBalancer	外部 LoadBalancer を作成します service
Port	<Port Number>	mongodのポート。
publishNotReadyAddress	true	DNS レコード を指定する は、Ped が準備ができていない場合でも作成されます。どのデータベース ポッドでもfalseに設定しないでください。

注意

spec.clusterSpecList.externalAccess.externalDomainを設定すると、外部サービスはバックアップ用の別のポート（ Port Number + 1 ）を追加します。

members

タイプ: 数値

MongoDB レプリカセット内のノードの数。

memberConfig

タイプ: コレクション

マルチ Kubernetes クラスターMongoDBデプロイ内の各MongoDBシャードとそのノードの仕様。

シャードのオブジェクト内の要素の順序は、レプリカセット内のノードの順序を反映する必要があります。 例、最初の要素はインデックス0の ポッドに影響し、2 番目の要素はインデックス1に影響するなど、 に影響します。

例

3 つのレプリカ セットを含むマルチ Kubernetes クラスター MongoDB 配置の次の例の仕様を検討してみましょう。

apiVersion: mongodb.com/v1
kind: MongoDBMultiCluster
metadata:
  name: multi-replica-set
spec:
  version: 6.0.0-ent
  type: ReplicaSet
  duplicateServiceObjects: false
  credentials: my-credentials
  opsManager:
    configMapRef:
      name: my-project
  clusterSpecList:
    - clusterName: cluster1.example.com
      members: 2
      memberConfig:
          - votes: 1
            priority: "0.5"
            tags:
                tag1: "value1"
                environment: "prod"
          - votes: 1
            priority: "1.5"
            tags:
                  tag2: "value2"
                  environment: "prod"
    - clusterName: cluster2.example.com
      members: 1
      memberConfig:
          - votes: 1
            priority: "0.5"
            tags:
                tag1: "value1"
                environment: "prod"
    - clusterName: cluster3.example.com
      members: 1
      memberConfig:
          - votes: 1
            priority: "0.5"
            tags:
                tag1: "value1"
                environment: "prod"

statefulSet

タイプ: コレクション

ステートフルセット の構成を提供します マルチ Kubernetes クラスターMongoDBデプロイにおけるクラスターの各ステートメントセットの オーバーライド。マルチ Kubernetes クラスターMongoDBデプロイ内のすべてのクラスターに適用されるグローバル構成を設定するには、 spec.status.spec を参照してください。

この設定は、マルチ Kubernetes クラスター MongoDB 配置のレプリカセット リソース タイプにのみ適用されます。

spec.shard.clusterSpecList

注意

このフィールドは、マルチクラスターのシャーディングされたクラスターの配置でのみ使用できます。これらは現在public preview段階です。

タイプ: オブジェクトの配列

必須topology=MultiClusterの場合）

次の最上位フィールドを持つマルチクラスターのシャーディングされたクラスター配置で使用するオブジェクトの配列。

clusterName

型: string

MongoDB Enterprise Kubernetes Operator が ステートメント をスケジュールするクラスターの名前 。

externalAccess

タイプ: コレクション

マルチ Kubernetes クラスター MongoDB 配置を外部接続用に公開するための仕様。 Kubernetes クラスターの外部からマルチ Kubernetes クラスター MongoDB 配置に接続する方法については、「 Kubernetes 外部からマルチクラスター リソースに接続する 」を参照してください。

これらの設定は、すべてのクラスターのサービスに適用されます。 特定のクラスターでこれらのグローバル設定をオーバーライドするには、 spec.clusterSpecList.externalAccess.externalService を使用します。

spec.externalAccessを追加すると、Kubernetes Operator はレプリカセット内の各ポッドの外部サービスを作成します。 外部サービスは、クラスター内の各 MongoDB database ポッドの外部エントリ ポイントを提供します。 各外部サービスには セレクター があります は、外部サービスを特定のポッドに一致させます。

値なしでこの設定を追加すると、Kubernetes Operator は次のデフォルト値を持つ外部サービスを作成します。

フィールド	値	説明
Name	<pod-name>-svc-external	外部サービスの名前。 この値は変更できません。
Type	LoadBalancer	外部 LoadBalancer を作成します service
Port	<Port Number>	mongodのポート。
publishNotReadyAddress	true	DNS レコード を指定する は、Ped が準備ができていない場合でも作成されます。どのデータベース ポッドでもfalseに設定しないでください。

注意

spec.clusterSpecList.externalAccess.externalDomainを設定すると、外部サービスはバックアップ用の別のポート（ Port Number + 1 ）を追加します。

members

タイプ: 数値

MongoDB レプリカセット内のノードの数。

memberConfig

タイプ: コレクション

マルチ Kubernetes クラスターMongoDBデプロイ内の各MongoDBシャードとそのノードの仕様。

シャードのオブジェクト内の要素の順序は、レプリカセット内のノードの順序を反映する必要があります。 例、最初の要素はインデックス0の ポッドに影響し、2 番目の要素はインデックス1に影響するなど、 に影響します。

例

3 つのレプリカ セットを含むマルチ Kubernetes クラスター MongoDB 配置の次の例の仕様を検討してみましょう。

apiVersion: mongodb.com/v1
kind: MongoDBMultiCluster
metadata:
  name: multi-replica-set
spec:
  version: 6.0.0-ent
  type: ReplicaSet
  duplicateServiceObjects: false
  credentials: my-credentials
  opsManager:
    configMapRef:
      name: my-project
  clusterSpecList:
    - clusterName: cluster1.example.com
      members: 2
      memberConfig:
          - votes: 1
            priority: "0.5"
            tags:
                tag1: "value1"
                environment: "prod"
          - votes: 1
            priority: "1.5"
            tags:
                  tag2: "value2"
                  environment: "prod"
    - clusterName: cluster2.example.com
      members: 1
      memberConfig:
          - votes: 1
            priority: "0.5"
            tags:
                tag1: "value1"
                environment: "prod"
    - clusterName: cluster3.example.com
      members: 1
      memberConfig:
          - votes: 1
            priority: "0.5"
            tags:
                tag1: "value1"
                environment: "prod"

podSpec.persistence

タイプ: コレクション

spec.configSrv.clusterSpecListとspec.shard.clusterSpecListに渡されるclusterSpecItemオブジェクトでのみ利用可能。 特定のクラスターの既存の永続化構成を上書きします。

statefulSet

タイプ: コレクション

ステートフルセット の構成を提供します マルチ Kubernetes クラスターMongoDBデプロイにおけるクラスターの各ステートメントセットの オーバーライド。マルチ Kubernetes クラスターMongoDBデプロイ内のすべてのクラスターに適用されるグローバル構成を設定するには、 spec.status.spec を参照してください。

この設定は、マルチ Kubernetes クラスター MongoDB 配置のレプリカセット リソース タイプにのみ適用されます。

spec.shardOverrides

注意

このフィールドは、マルチクラスターのシャーディングされたクラスターの配置でのみ使用できます。これらは現在public preview段階です。

タイプ: オブジェクトの配列

任意

シャードごとのオーバーライドを含むリスト。 各オブジェクトには、次のフィールドが含まれています。

• shardNames

  必須

  このオーバーライドが適用されるシャードの名前。

• podSpec.Persistence

  任意

  Kubernetes Operator が永続ボリュームを作成してシャードにバインドする方法を定義します。 topology=MultiClusterの場合、すべてのノード クラスターの永続化設定を設定します。 spec.shardOverrides.clusterSpecList.persistenceでは、特定のノード クラスターの永続設定を定義できます。

• additionalMongodConfig

  任意

  spec.shard.additionalMongodConfigのシャード固有の上書き。

• agent

  任意

  spec.shard.agentのシャード固有の上書き。

• statefulSet

  任意

  spec.shardPodSpec.podTemplateとspec.shard.clusterSpecList.statefulSetのシャード固有の上書き。

• members

  任意

  topology=SingleClusterの場合にのみ利用可能です。 spec.mongodsPerShardCountのオーバーライド用のシャード固有オーバーライド。

• memberConfig

  任意

  topology=SingleClusterの場合にのみ利用可能です。 spec.shard.memberConfigのシャード固有の上書き。

spec.shardPodSpec.persistence.single

タイプ: コレクション

Kubernetes Operator が 1 つの 永続ボリューム要求 を作成するようにします と では、データ、ジャーナル、ログの 3 つのすべてのディレクトリが同じ 永続ボリューム にマウントされます。 。

注意

• spec.persistent : trueの場合は、このコレクションに値を設定する必要があります。

• このコレクションまたはpersistence.multipleコレクションを設定できますが、両方は設定できません。

スカラー	データ型	説明
labelSelector	string	タグ マウントされたボリュームをディレクトリにバインドするために使用されます。
storage	string	永続ボリューム の最小サイズ マウントする必要があるもの。この値は、 JEDEC表記では、整数とそれに続くストレージの単位として表されます。 デフォルト値は 16Gi です。 たとえば、 の各シャーディングされたクラスターのシャード ノードに60ギガバイトのストレージ容量が必要な場合は、この値を60Giに設定します。
storageClass	string	永続的なボリューム要求 で指定されるストレージのタイプ 。このストレージ タイプは、 StorageClass として作成できます。 この オブジェクト で使用する前にオブジェクトを 仕様。 StorageClass を必ず設定してください 保持 するreclaimPolicy 。これにより、 永続的なボリューム要求 が発生した場合にデータが保持できます は削除されます。