MongoDB Database リソースの仕様

必須

apiVersion

型: string

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

kind

型: string

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

metadata.name

型: string

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

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

spec.credentials

型: string

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

認証情報を保持する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 IOPSを使用しない場合、この配置のデータを確認するときに、Processes ページまたは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

Cloud ManagerまたはMongoDB Ops Manager接続構成を含む ConfigMap の名前。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 がStatefulSet を作成する場合、 Kubernetes は各ポッド に FQDN を割り当てます。Cloud ManagerまたはMongoDB Ops Manager を更新するために、 Kubernetes Operator は指定されたクラスター名を使用して各 ポッド の FQDN を計算します。Kubernetesでは、これらのホスト名をクエリするためのAPIは提供されていません。

警告

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

spec.clusterName

型: string

デフォルト: cluster.local

重要

spec.clusterName は非推奨

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

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

警告

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

metadata.namespace

型: string

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

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データベースポッドの外部エントリ点を提供します。各外部サービスには、外部サービスを特定のポッドに一致させるセレクターがあります。

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

フィールド	値	説明
Name	<pod-name>-svc-external	外部サービスの名前。 この値は変更できません。
Type	LoadBalancer	外部 LoadBalancer サービスを作成します。
Port	<Port Number>	mongodのポート。
publishNotReadyAddress	true	ポッドが準備ができていない場合でも DNS レコードが作成されることを指定します。どのデータベースポッドでも 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仕様の詳細については、Kubernetesドキュメントの ServiceSpec を参照してください。

spec.externalAccess.externalService.annotations

タイプ: コレクション

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

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

値	説明
{resourceName}	metadata.nameに等しい。
{namespace}	metadata.namespaceに等しい。
{podIndex}	StateftSet によって割り当てられ、現在の外部サービスが対象とする ポッドのインデックス。
{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ルール。

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

spec.podSpec.podTemplate.affinity.podAffinity

型: 構造体

複数のMongoDB リソースポッドが他のポッドと同じロケーションに存在する必要があるかどうかを決定するためのKubernetesルール。ユースケースの詳細については、 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 v1 Core 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 がStatefulSet を作成する場合、 Kubernetes は各ポッド に FQDN を割り当てます。Cloud ManagerまたはMongoDB Ops Manager を更新するために、 Kubernetes Operator は指定されたクラスター名を使用して各 ポッド の FQDN を計算します。Kubernetesでは、これらのホスト名をクエリするためのAPIは提供されていません。

警告

spec.clusterDomainKubernetesクラスターにデフォルトの 以外のデフォルトのドメインがある場合は、 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

タイプ: コレクション

複数のMongoDB リソースポッドが他のポッドと同じロケーションに存在する必要があるかどうかを決定するためのKubernetesルール。ユースケースの詳細については、 Kubernetesドキュメントのアフィニティと非アフィニティを参照してください。

spec.configSrvPodSpec.podTemplate.affinity.nodeAffinity

タイプ: コレクション

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

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

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 v1 Core 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 が 各mongos インスタンスに対して作成するKubernetesポッドのテンプレート。

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

注意

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

spec.mongosPodSpec.podTemplate.affinity.podAffinity

タイプ: コレクション

任意。複数のMongoDB リソースポッドが他のポッドと同じロケーションに存在する必要があるかどうかを決定するためのKubernetesルール。

spec.mongosPodSpec.podTemplate.affinity.nodeAffinity

タイプ: コレクション

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

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

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 v1 Core 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

複数のMongoDB リソースポッドが他のポッドと同じロケーションに存在する必要があるかどうかを決定するためのKubernetesルール。ユースケースの詳細については、 Kubernetesドキュメントのアフィニティと非アフィニティを参照してください。

spec.shardPodSpec.podTemplate.affinity.nodeAffinity

型: string

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

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

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 v1 Core 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

複数のMongoDB リソースポッドが他のポッドと同じロケーションに存在する必要があるかどうかを決定するためのKubernetesルール。ユースケースの詳細については、 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 v1 Core 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 が Atlas Triggers をスケジュールするクラスターの名前。

externalAccess

タイプ: コレクション

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

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

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

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

フィールド	値	説明
Name	<pod-name>-svc-external	外部サービスの名前。 この値は変更できません。
Type	LoadBalancer	外部 LoadBalancer サービスを作成します。
Port	<Port Number>	mongodのポート。
publishNotReadyAddress	true	ポッドが準備ができていない場合でも DNS レコードが作成されることを指定します。どのデータベースポッドでも 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デプロイ内のクラスターの各ステートメントに対して、StatusSet オーバーライドの構成を提供します。マルチ Kubernetes クラスターMongoDBデプロイ内のすべてのクラスターに適用されるグローバル構成を設定するには、spec.statefulSet.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 が Atlas Triggers をスケジュールするクラスターの名前。

externalAccess

タイプ: コレクション

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

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

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

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

フィールド	値	説明
Name	<pod-name>-svc-external	外部サービスの名前。 この値は変更できません。
Type	LoadBalancer	外部 LoadBalancer サービスを作成します。
Port	<Port Number>	mongodのポート。
publishNotReadyAddress	true	ポッドが準備ができていない場合でも DNS レコードが作成されることを指定します。どのデータベースポッドでも 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デプロイ内のクラスターの各ステートメントに対して、StatusSet オーバーライドの構成を提供します。マルチ Kubernetes クラスターMongoDBデプロイ内のすべてのクラスターに適用されるグローバル構成を設定するには、spec.statefulSet.spec を参照してください。

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

spec.shard.clusterSpecList

注意

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

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

必須topology=MultiClusterの場合）

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

clusterName

型: string

MongoDB Enterprise Kubernetes Operator が Atlas Triggers をスケジュールするクラスターの名前。

externalAccess

タイプ: コレクション

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

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

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

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

フィールド	値	説明
Name	<pod-name>-svc-external	外部サービスの名前。 この値は変更できません。
Type	LoadBalancer	外部 LoadBalancer サービスを作成します。
Port	<Port Number>	mongodのポート。
publishNotReadyAddress	true	ポッドが準備ができていない場合でも DNS レコードが作成されることを指定します。どのデータベースポッドでも 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デプロイ内のクラスターの各ステートメントに対して、StatusSet オーバーライドの構成を提供します。マルチ Kubernetes クラスターMongoDBデプロイ内のすべてのクラスターに適用されるグローバル構成を設定するには、spec.statefulSet.spec を参照してください。

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

spec.shardOverrides

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

任意

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

• 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 を 保持 するように設定します。これにより、永続的なボリューム要求が削除されてもデータが保持されます。