Docs Menu
Docs Home
/
MongoDB Enterprise Kubernetes 演算子
/

MongoDB Ops Managerリソース仕様

項目一覧

  • MongoDB Ops Managerの必要設定
  • MongoDB Ops Manager任意設定
  • 外部接続設定
  • バックアップ設定
  • S3 設定
  • アプリケーションデータベースに必要な設定
  • アプリケーションデータベースの任意設定
  • Prometheus 設定
  • マルチクラスター設定
  • MongoDB Ops Managerの必要設定
  • MongoDB Ops Manager任意設定
  • アプリケーションデータベースに必要な設定
  • アプリケーションデータベースの任意設定

MongoDB Enterprise Kubernetes演算子 は、書き込んだ仕様ファイルからコンテナ化された Ops Manager 配置を作成します。

MongoDB Ops Managerリソース仕様を作成または更新すると、 MongoDB Enterprise Kubernetes Operatorは、この仕様をKubernetes環境に適用するように指示します。 KubernetesOperator は、 に必要なサービスとカスタムKubernetes MongoDB Ops Managerリソースを作成し、MongoDB Ops Manager とそのバッキング アプリケーション データベースをKubernetes 環境のコンテナに配置します。

MongoDB Ops Manager の各リソースは、 オブジェクト を使用します。 配置の特性と設定を定義するための YAML の仕様。

次の例は、 MongoDB Ops Manager配置のリソース仕様を示しています。

1apiVersion: mongodb.com/v1
2kind: MongoDBOpsManager
3metadata:
4 name: om
5spec:
6 topology: SingleCluster # optional, SingleCluster by default
7 opsManagerURL: https://link.to.configured.load-balancer.example.com # optional OM URL for the operator
8replicas: 1
9version: "6.0.18"
10 adminCredentials: ops-manager-admin-secret
11 configuration:
12 mms.fromEmailAddr: admin@example.com
13 mms.security.allowCORS: "false"
14 security:
15 tls:
16 ca: issuer-ca
17 backup:
18 enabled: true
19 encryption:
20 kmip:
21 server:
22 url: kmip.corp.mongodb.com:5696
23 ca: mongodb-kmip-certificate-authority-pem
24 headDB:
25 storage: "30Gi"
26 labelSelector:
27 matchLabels:
28 app: my-app
29 opLogStores:
30 - name: oplog1
31 # Sets labels for the oplog store.
32 assignmentLabels: ["test1", "test2"]
33 mongodbResourceRef:
34 name: my-oplog-db
35 mongodbUserRef:
36 name: my-oplog-user
37 s3Stores:
38 - name: s3store1
39 # Sets labels for the S3 store.
40 assignmentLabels: ["test1", "test2"]
41
42 mongodbResourceRef:
43 name: my-s3-metadata-db
44 mongodbUserRef:
45 name: my-s3-store-user
46 s3SecretRef:
47 name: my-s3-credentials
48 pathStyleAccessEnabled: true
49 s3BucketEndpoint: s3.region.amazonaws.com
50 s3BucketName: my-bucket
51 applicationDatabase:
52 passwordSecretKeyRef:
53 name: om-db-user-secret
54 key: password
55 members: 3
56 topology: SingleCluster
57 version: "6.0.5-ubi8"
58 security:
59 tls:
60 ca: issuer-ca
61 secretRef:
62 prefix: appdb
1apiVersion: mongodb.com/v1
2kind: MongoDBOpsManager
3metadata:
4 name: om
5spec:
6 topology: MultiCluster # optional, SingleCluster by default
7 opsManagerURL: https://link.to.configured.lb.example.com # optional OM URL for the operator
8 clusterSpecList: # optional ClusterSpecOMItem list, the type is different than ClusterSpecItem for AppDB and MongoDB
9 - clusterName: cluster-1 # required
10 replicas: 1 # required, OM application replicas
11 # optional parameters to override those defined at MongoDBOpsManager level
12 clusterDomain: cluster-1.example.com # optional, default cluster.local
13 jvmParameters: ["-Xmx4352m","-Xms4352m"]
14 externalConnectivity: # optional to override
15 type: LoadBalancer
16 port: 9090
17 annotations:
18 key: value
19 statefulSet: # StatefulSetSpecWrapper override
20 spec: {}
21 metadata: {}
22 configuration:
23 automation.versions.source: mongodb
24 mms.adminEmailAddr: cloud-manager-support@mongodb.com
25 backup: # MongoDBOpsManagerBackup, optional, we only support a subset of fields
26 members: 1 # backup daemon replicas, optional, default=1
27 assignmentLabels: [] # assignment labels to override
28 jvmParameters: ["-Xmx4352m","-Xms4352m"] # optional
29 statefulSet: # mdbc.StatefulSetConfiguration, optional to override for backup daemon
30 spec: {}
31 metadata: {}
32 - clusterName: cluster-2
33 replicas: 1
34
35 ....
36
37replicas: 1
38 version: "6.0.18"
39 adminCredentials: ops-manager-admin-secret
40 configuration:
41 mms.fromEmailAddr: admin@example.com
42 mms.security.allowCORS: "false"
43 backup:
44 enabled: true
45 encryption:
46 kmip:
47 server:
48 url: kmip.corp.mongodb.com:5696
49 ca: mongodb-kmip-certificate-authority-pem
50 headDB:
51 storage: "30Gi"
52 labelSelector:
53 matchLabels:
54 app: my-app
55 opLogStores:
56 - name: oplog1
57 # Sets labels for the oplog store.
58 assignmentLabels: ["test1", "test2"]
59 mongodbResourceRef:
60 name: my-oplog-db
61 mongodbUserRef:
62 name: my-oplog-user
63 s3Stores:
64 - name: s3store1
65 # Sets labels for the S3 store.
66 assignmentLabels: ["test1", "test2"]
67
68 mongodbResourceRef:
69 name: my-s3-metadata-db
70 mongodbUserRef:
71 name: my-s3-store-user
72 s3SecretRef:
73 name: my-s3-credentials
74 pathStyleAccessEnabled: true
75 s3BucketEndpoint: s3.region.amazonaws.com
76 s3BucketName: my-bucket
77 security:
78 tls:
79 ca: issuer-ca
80 applicationDatabase:
81 passwordSecretKeyRef:
82 name: om-db-user-secret
83 key: password
84 version: "6.0.5-ubi8"
85 topology: MultiCluster
86 clusterSpecList:
87 - clusterName: cluster1.example.com
88 members: 4
89 - clusterName: cluster2.example.com
90 members: 3
91 - clusterName: cluster3.example.com
92 members: 2
93 security:
94 tls:
95 ca: issuer-ca
96 secretRef:
97 prefix: appdb

このセクションでは、すべてのMongoDB Ops Managerリソースに使用する必要がある設定について説明します。

apiVersion

: string

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

kind

: string

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

metadata.name

: string

必須。 作成している MongoDB Kubernetes リソースの名前。

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

spec.version

: string

必須。 この リソースにインストールする のバージョン。MongoDB Ops ManagerMongoDBKubernetes

spec.adminCredentials

: string

必須。 Kubernetes シークレット の名前 MongoDB Ops Manager 管理ユーザー用に作成したMongoDB Ops Managerリソースを配置すると、 Kubernetes Operator によってこれらの認証情報を持つユーザーが作成されます。

注意

単一クラスターの Kubernetes 配置でシークレットが保存されないようにするには、すべての シークレット を移行します シークレット ストレージ ツール に渡す追加オプション。複数の Kubernetes クラスターでの配置では、 HashiCorp Vault などのシークレット ストレージ ツールへのシークレットの保存はサポートされていません。 。

管理者ユーザーには、グローバル所有者ロールが付与されます。

spec.replicas

タイプ: 整数

条件付き。 並行して実行するMongoDB Ops Managerインスタンスの数。 spec.topologySingleClusterを指定する場合、このパラメータは必須です。 最小許容値は1です。

spec.topologyMultiClusterを指定すると、このパラメータは無視されます。

MongoDB Ops Manager リソースでは、次の設定も使用できます。

spec.backup.logging.logBackAccessRef

: string

MongoDB Ops Managerバックアップ ログを構成するためのカスタム logback-access.xml ファイルを含む ConfigMap への参照。

ConfigMap のキーは、 MongoDB Ops Managerポッド内のデフォルトの ファイルを置き換えるために、logback-access.xml の名前と完全に一致する必要があります。

詳しくは、「 CRD を使用してMongoDB Ops Managerログを構成する 」を参照してください。

spec.backup.logging.logBackRef

: string

Reference to a ConfigMap that contains a custom logback.xml file. このファイルは、ログ ローテーション ポリシー、ログ レベル、およびその他のロギング パラメーターを含む、 MongoDB Ops Managerバックアップの一般的なログ動作を構成します。

ConfigMap のキーは、 MongoDB Ops Managerポッド内のデフォルトの ファイルを置き換えるために、logback-access.xml の名前と完全に一致する必要があります。 詳しくは、「 CRD を使用してMongoDB Ops Managerログを構成する 」を参照してください。

spec.logging.logBackAccessRef

: string

MongoDB Ops Managerログを構成するためのカスタム logback-access.xml ファイルを含む ConfigMap への参照。

ConfigMap のキーは、 MongoDB Ops Managerポッド内のデフォルトの ファイルを置き換えるために、正確に logback-access.xml である必要があります。

詳しくは、「 CRD を使用してMongoDB Ops Managerログを構成する 」を参照してください。

spec.logging.logBackRef

: string

カスタムlogback.xmlファイルを含むコンフィギュレーションマップへの参照。 このファイルは、ログ ローテーション ポリシー、ログ レベル、およびその他のログ パラメーターを含む、 MongoDB Ops Managerの一般的なログ動作を構成します。

ConfigMap のキーは、 MongoDB Ops Managerポッド内のデフォルトの ファイルを置き換えるために、正確に logback.xml である必要があります。

詳しくは、「 CRD を使用してMongoDB Ops Managerログを構成する 」を参照してください。

spec.opsManagerURL

: string

任意。 Kubernetes Operator 内の MongoDB Ops Manager リソースの URL(例: https://link.to.configured.lb.example.com

  • このパラメータを省略すると、MongoDB Ops Manager インスタンスに接続するために、Kubernetes Operator は MongoDB Ops Manager インスタンスのデフォルトとして次の URL を使用します: <om-name>-svc.{namespace}.svc.cluster.local 。 これは、MongoDB Ops Manager のヘッドレス サービスのFQDNです。

  • このパラメータを指定すると、この URL を別の URL に変更できるようになります。

注意

アプリケーション データベースの MongoDB 配置とモニタリングエージェントを構成するために、特定の配置 のspec.opsManagerURL ConfigMap で指定する URL と を混同しないでください。KubernetesOperatorspec.opsManagerURL MongoDB Ops Managerは、MongoDB Ops Manager インスタンスに直接接続し、MongoDB とアプリケーション データベースの配置を構成するために持っている必要があります。Kubernetes 演算子は、特定の MongoDB データベースを管理するためにspec.opsManagerURLを使用しません。

次の場合は、 spec.opsManagerURLパラメータをカスタム URL に変更します。

  • MongoDB Ops Managerを複数のKubernetes クラスターにわたって配置しており、 のホスティングURL MongoDB Ops Managerポッドからデフォルト にアクセスできない場合。たとえば、MongoDB Ops Manager KubernetesKubernetesOperator を配置するクラスター以外の クラスターに配置する場合、MongoDB Ops Manager サービスの FQDN にアクセスできない可能性があります。この場合は、カスタム URL を指定できます。

  • 外部ドメイン上の MongoDB Ops Manager インスタンスへの外部アクセスを構成する場合は、カスタム URL を指定できます。 これには、Kubernetes Operator とアプリケーション データベースのモニタリングエージェントも、デフォルトではなくこのカスタム URL を使用する必要があります。

spec.clusterDomain

: string

Kubernetes は各 ポッド を割り当てます FQDN 。Kubernetes 演算子は、各 ポッド FQDN を計算しますclusterDomain 提供された を使用します。Kubernetes では、これらのホスト名をクエリするためのAPIは提供されていません。

spec.clusterName

重要

spec.clusterName は非推奨

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

: string

Kubernetes は各 ポッド を割り当てます FQDN 。Kubernetes 演算子は、各 ポッド FQDN を計算しますclusterName 提供された を使用します。Kubernetes では、これらのホスト名をクエリするためのAPIは提供されていません。

spec.configuration

タイプ: コレクション

MongoDB Ops Manager の構成プロパティ プロパティ名と説明については、「 MongoDB Ops Managerの構成設定」を参照してください。 各プロパティはstring型の値を受け取ります。

重要

MongoDB Ops Manager が、配置先の Kubernetes クラスターの外部に配置された MongoDB リソースを管理する場合は、 mms.centralUrl設定をspec.configurationに追加する必要があります。

URLMongoDB Ops ManagerがKubernetes クラスターの外部で公開される に値を設定します。

詳細については、「外部 MongoDB デプロイの管理 」を参照してください。

spec.configuration.mms.featureFlag.automation.verifyDownloads

: string

enabledに設定されている場合、MongoDB Agent は、MongoDB Ops Manager インスタンスが管理するすべての MongoDB 配置の署名ファイルを必要とします。

このオプションを有効にして MongoDB Agent をアップグレードすると、MongoDB Agent の現在のバージョンに新しい MongoDB Agent バイナリの署名ファイルが必要になります。

詳しくは、「 MongoDB 署名の検証 」を参照してください。

spec.configuration.mms.featureFlag.backup.queryable

タイプ: ブール値

クエリ可能なバックアップを無効にするには、 をfalseに設定します。

spec.configuration.mms.featureFlag.backup.wt.queryable

タイプ: ブール値

WiredTiger を使用する際にクエリ可能なバックアップを無効にするには、 をfalseに設定します。

spec.configuration.mms.mongoDbUsage.defaultUsageType

: string

Kubernetes サービスのデフォルトのサーバータイプ。

指定可能な値は、 PRODUCTION_SERVERTEST_SERVERDEV_SERVERRAM_POOLです。

spec.jvmParameters

タイプ: 文字列の配列

任意。 コンテナ内の アプリケーションに渡される JVM パラメータ。MongoDB Ops Manager指定されたすべてのパラメーターは、MongoDB Ops Manager アプリケーションのデフォルトの JVM パラメーターを置き換えます。

この Kubernetes Operator パラメーターのデフォルトは空のリストです。

spec:
jvmParameters: ["-XX:+HeapDumpOnOutOfMemoryError","-XX:HeapDumpPath=/tmp"]

重要

JVM メモリ ヒープの値は自分のリスクで変更

KubernetesOperator は、コンテナのメモリに基づいて アプリケーションの JVM メモリ ヒープ値を計算します。MongoDB Ops Manager-Xms-Xmxの値を変更すると、MongoDB Ops Manager で問題が発生する可能性があります。

spec.security.certsSecretPrefix

: string

Kubernetes シークレット のプレフィックスに適用するテキスト MongoDB Ops Manager の TLS キーと証明書を含む を作成した

シークレットには<prefix>-<metadata.name>-certという名前を付ける必要があります。

MongoDB Ops ManagerインスタンスをHTTPS 経由で実行するように構成する方法については、「 MongoDB Ops Managerリソースの配置 」を参照してください。

spec.security.tls.ca

KubernetesConfigMap の名前 のカスタム CA MongoDB Ops Managerファイルが含まれています。

重要

spec.security.tls.caカスタム CA を使用して MongoDB Ops Manager TLS 証明書に署名する場合は、 が必要です。

Kubernetes Operator では、ConfigMap でMongoDB Ops Managerリソース mms-ca.crt の証明書に名前を付ける必要があります。

このCAは、次の証明書に署名します。

  • クライアントが を使用して MongoDB Ops Manager アプリケーションに接続する、

  • アプリケーション データベース ポッド 内の エージェント を使用して MongoDB Ops Manager と通信します。

警告

アプリケーション データベースが再起動した場合に が操作不能になるのを防ぐために、 からカスタム CA ファイルと TLS 証明書チェーン全体を連結する必要があります。downloads.mongodb.comMongoDB Ops Manager

spec.security.tls.enabled

重要

spec.security.tls.enabledは非推奨であり、将来のリリースで削除される予定です。 TLSを有効にするには、 spec.security.certsSecretPrefix設定の値を指定します。

TLS証明書を使用して、クライアントとMongoDB Ops Manager間の通信を暗号化します。

spec.statefulSet.spec

タイプ: コレクション

ステートメントセット の仕様 がMongoDBEnterprise Kubernetes Operator MongoDB Ops Manager用に作成する

spec.statefulSet.specに追加できるフィールドを確認するには、「 StatulSetSpec v1 アプリ 」を参照してください (Kubernetes ドキュメント)。

spec.statefulSet.spec.template

タイプ: コレクション

テンプレート Kubernetesステートメント セット内の ポッドの場合 が 用に作成するMongoDBEnterprise Kubernetes OperatorMongoDB Ops Manager

spec.statefulSet.spec.template.metadata

タイプ: コレクション

StateftSet 内の ポッドのメタデータKubernetes がMongoDBEnterprise Kubernetes Operator MongoDB Ops Manager用に作成する

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

spec.statefulSet.spec.template.spec

タイプ: コレクション

StateftSet 内のKubernetes ポッドの仕様 がMongoDBEnterprise Kubernetes Operator MongoDB Ops Manager用に作成する

spec.statefulSet.spec.template.specに追加できるフィールドの完全なリストを確認するには、 Kubernetes のドキュメント を参照してください。

spec.statefulSet.spec.template.specMongoDB Ops Manager次の例では、MongoDBEnterprise Kubernetes Operator は、 が配置する 1 つの コンテナの最小と最大の CPU とメモリ容量を定義します。

statefulSet:
spec:
template:
spec:
containers:
- name: mongodb-ops-manager
resources:
requests:
cpu: "0.70"
memory: "6Gi"
limits:
cpu: "1"
memory: "7000M"
spec.statefulSet.spec.template.spec.containers

タイプ: コレクション

ステートメント セット内の ポッドに属するコンテナのリストKubernetes がMongoDBEnterprise Kubernetes Operator MongoDB Ops Manager用に作成する

MongoDB Ops Managerコンテナの仕様を変更するには、次の例に示すように、name フィールドを使用してコンテナの正確な名前を指定する必要があります。

backup:
statefulSet:
spec:
template:
spec:
containers:
- name: mongodb-ops-manager

注意

spec.statefulSet.spec.template.spec.containersにコンテナを追加すると、Kubernetes Operator はそれらを Kubernetes ポッドに追加します。 これらのコンテナは、ポッド内のMongoDB Ops Managerコンテナに追加されます。

spec.statefulSet.spec.template.spec.containers.resources.requests.cpu

: string

Kubernetes ノード で使用可能である必要がある最小 CPU 容量 は、MongoDB Ops Manager をホストします。

リクエスト値はspec.statefulSet.spec.template.spec.containers.resources.limits.cpu以下である必要があります。

spec.statefulSet.spec.template.spec.containers.resources.limits.cpu

: string

ノード の最大 CPU 容量MongoDB Ops Manager は、 をホストするために作成されています。省略した場合、この値はspec.statefulSet.spec.template.spec.containers.resources.requests.cpuに設定されます。

spec.statefulSet.spec.template.spec.containers.resources.requests.memory

: string

ノード で使用可能である必要がある最小メモリ容量KubernetesMongoDB Ops Manager Kubernetesは、 上で をホストします。この値は、 JEDEC表記では、整数とそれに続くメモリ単位として表されます。

MongoDB Ops Manager上の にKubernetes 6 ギガバイトのメモリが必要な場合は、この値を6Gi に設定します。

注意

MongoDB では、この値を少なくとも5Giに設定することを推奨しています。

リクエスト値はspec.statefulSet.spec.template.spec.containers.resources.limits.memory以下である必要があります。

spec.statefulSet.spec.template.spec.containers.resources.limits.memory

: string

ノード の最大メモリ容量 は、 をホストするために作成されています。MongoDB Ops Manager省略した場合、この値はspec.statefulSet.spec.template.spec.containers.resources.requests.memoryに設定されます。

Kubernetes Operator は、コンテナのメモリに基づいて Java ヒープ サイズのパラメータを計算し、設定します。

警告

この値は 32 GB 未満に制限します

この値を 32 GB( 32Gi )を超える値に設定すると、バックアップサービスに問題が発生する可能性があります。 ヒープが過剰な場合、 MongoDB Ops Managerで予期しない結果を引き起こす可能性があります。

このセクションでは、 MongoDB Ops Managerの外部接続に関連するオプションの設定について説明します。 MongoDB Ops Managerマルチクラスター配置に固有のオプションの外部接続設定については、「マルチクラスター設定 」を参照してください。

spec.externalConnectivity

タイプ: コレクション

MongoDB Ops Managerへの外部接続を有効にする 構成 オブジェクト。 指定した場合、Kubernetes Operator はKubernetes サービス を作成します これにより、Kubernetes クラスターの外部からのトラフィックはMongoDB Ops Manager アプリケーションに到達できます。

指定しない場合、Kubernetes Operator は Kubernetes サービスを作成しません。 手動で作成するか、サードパーティのソリューションを使用して外部トラフィックをMongoDB Ops Manager クラスター内のKubernetes アプリケーションにルーティングする必要があります。

spec.externalConnectivity.type

: string

Kubernetesサービス ServiceType MongoDB Ops ManagerKubernetesこれは を の外部で公開します。

が存在する場合は spec.externalConnectivity.type必須 。

指定可能な値はLoadBalancerNodePortです。 クラウドプロバイダーがサポートしている場合は、 LoadBalancerが推奨されます。 ローカル配置にはNodePortを使用します。

spec.externalConnectivity.port

タイプ: 整数

KubernetesサービスがMongoDB Ops Managerアプリケーションを外部トラフィックに使用するポートを示す値。

  • spec.externalConnectivity.typeNodePortの場合

    • Kubernetesサービスは、 MongoDB Ops Managerアプリケーションをこのポートを介して外部トラフィックに公開します。

    • spec.externalConnectivity.portKubernetes値を指定しない場合、MongoDB Ops Manager サービスは、次のデフォルト範囲からランダムに選択された使用可能なポートから30000 32767アプリケーションにトラフィックをルーティングします。

      注意

      このポート経由のトラフィックを許可するには、ネットワークのファイアウォールを設定する必要があります。

  • spec.externalConnectivity.typeLoadBalancerの場合

    • クラウドプロバイダーが作成するロード バランサー リソースは、このポートを介してMongoDB Ops Managerアプリケーションを公開します。

    • spec.externalConnectivity.port値を指定しない場合、 KubernetesサービスはMongoDB Ops ManagerアプリケーションをデフォルトのHTTP (8080)または HTTPS(8443)ポートを介して外部トラフィックに公開します。

spec.externalConnectivity.loadBalancerIP

: string

Kubernetes Operator による作成時にLoadBalancer Kubernetes サービスが使用する IP アドレス。

この設定は、クラウドプロバイダーがこの設定をサポートしており、かつspec.externalConnectivity.typeLoadBalancerである場合にのみ使用できます。 ロードバランサー の詳細については、 については、 Kubernetes のドキュメント を参照してください。

spec.externalConnectivity.externalTrafficPolicy

: string

MongoDB Ops Manager Kubernetesサービスへの外部トラフィックのルーティング ポリシー。 サービスは、この設定の値に応じて外部トラフィックをノードローカルまたはクラスター全体のエンドポイントにルーティングします。

指定可能な値はClusterLocalです。 要件を満たす値については、「 Kubernetes のソース IP 」を参照してください。 (Kubernetes ドキュメント)。

注意

Clusterを選択した場合、Kubernetes ネットワーク境界で発生するネットワーク ホスティング中にクライアントのSource-IPが失われます。

spec.externalConnectivity.annotations

タイプ: コレクション

クラウドプロバイダー固有の構成設定を提供できるキーと値のペア。

注釈 の詳細については、 での TLS サポート については、Amazon Web ServicesKubernetes のドキュメント を参照してください。

このセクションでは、 MongoDB Ops Managerのバックアップに関連するオプション設定について説明します。 マルチクラスターMongoDB Ops Manager配置に固有のオプションのバックアップ設定については、「マルチクラスター設定 」を参照してください。

spec.backup.assignmentLabels

タイプ: 文字列の配列

バックアップデーモン サービスプロセスの割り当てラベルのリスト。 割り当てラベル を使用して、特定のバックアップデーモン プロセスが特定のプロジェクトに関連付けられていることを識別します。 Kubernetes Operator を使用して割り当てラベルを設定すると、割り当てラベルのKubernetes構成ファイルで設定した値が、 MongoDB Ops Manager UI で定義された値を上書きします。 Kubernetes Operator を使用して設定しない割り当てラベルは、 MongoDB Ops Manager UI で設定された値を引き続き使用します。

spec.backup.enabled

タイプ: ブール値

MongoDB Ops Managerリソースのバックアップを有効にするフラグ。 falseに設定されている場合、バックアップは無効になります。

デフォルト値はtrueです。

spec.backup.encryption

: オブジェクト

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

spec.backup.encryption.kmip

: オブジェクト

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

注意

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

spec.backup.encryption.kmip.server

: オブジェクト

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

spec.backup.encryption.kmip.server.ca

: string

KMIP 認証に使用する CA 証明書(ca.pem )のエントリを含む ConfigMap を識別する、人間が判読可能なラベル。

spec.backup.encryption.kmip.server.url

: string

形式を使用する KMIP hostname.port192.168.1.3:5696my-kmip-server.mycorp.com:5696サーバーの URL (たとえば、 や など)。

spec.backup.headDB

タイプ: コレクション

ヘッドデータベースの構成設定。 Kubernetes Operator による 永続的なボリューム要求 の作成 指定された構成で。

スカラー
データ型
説明
labelSelector
string
タグ マウントされたボリュームをディレクトリにバインドするために使用されます。
storage
string

永続ボリューム の最小サイズ マウントする必要があるもの。この値は、 JEDEC表記では、整数とそれに続くストレージの単位として表されます。

デフォルト値は30Giです。

詳細については、「バックアップデーモンのハードウェア要件 」を参照してください。

たとえば、ヘッドデータベースに60ギガバイトのストレージが必要な場合は、この値を60Giに設定します。

storageClass
string

永続的なボリューム要求 で指定されるストレージのタイプ 。このストレージ タイプは、 StorageClass として作成できます。 この オブジェクト で使用する前にオブジェクトを 仕様。

StorageClass を必ず設定してください 保持 するreclaimPolicy 。これにより、 永続的なボリューム要求 が発生した場合にデータが保持できます は削除されます。

spec.backup.jvmParameters

タイプ: 文字列の配列

任意。 コンテナ内の バックアップ サービスに渡される JVM パラメータ。MongoDB Ops Manager

この Kubernetes Operator パラメーターのデフォルトは空のリストです。

spec:
backup:
jvmParameters: ["-XX:+UseStringCache"]

警告

JVM メモリ ヒープの値は自分のリスクで変更

Kubernetes Operator は、コンテナのメモリに基づいてバックアップ サービスのJVMメモリ ヒープ値を計算します。 -Xms-Xmxの値を変更すると、MongoDB Ops Manager で問題が発生する可能性があります。

spec.backup.members

タイプ: 整数

任意。 Kubernetes に配置するバックアップ デーモン サービスの数。 指定しない場合、デフォルトは1になります。 バックアップ サービスの高可用性を確保するには、 MongoDB Ops Managerで 複数のバックアップデーモン を配置します。

spec.backup.opLogStores

タイプ: コレクション

バックアップを有効にする場合は必須です。 バックアップに使用されるoplog ストアの配列。 配列内の各項目は、 Kubernetes Operator によって Kubernetes クラスターに配置された MongoDB database リソースを参照します。

spec.backup.opLogStores.assignmentLabels

タイプ: 文字列の配列

oplog ストアの割り当てラベルのリスト。 割り当てラベルを使用して、特定の oplog ストアが特定のプロジェクトに関連付けられていることを識別します。 Kubernetes Operator を使用して割り当てラベルを設定すると、割り当てラベルのKubernetes構成ファイルで設定した値が、 MongoDB Ops Manager UI で定義された値を上書きします。 Kubernetes Operator を使用して設定しない割り当てラベルは、 MongoDB Ops Manager UI で設定された値を引き続き使用します。

spec.backup.opLogStores.name

: string

バックアップを有効にする場合は必須です。 oplog ストアの名前。

重要

oplog ストアの名前を指定した後は、その名前を編集しないでください。

spec.backup.opLogStores.mongodbResourceRef.name

: string

バックアップを有効にする場合は必須です。 oplog スライスを保存するために作成するMongoDBリソースまたはMongoDBMultiClusterリソースの名前。 このリソースは、 MongoDB Ops Managerのリソースと同じ名前空間に配置する必要があります。

oplogデータベースは SCRAM 認証メカニズムのみをサポートしています。 他の認証メカニズムを有効にすることはできません。

oplog データベースでSCRAM認証を有効にする場合は、次の操作を行う必要があります。

  • MongoDBMongoDB Ops Managerをoplog データベースに接続するための ユーザー リソースを作成します。

  • nameのリソース定義でユーザーのMongoDB Ops Manager を指定します。

この名前の MongoDB database リソースが存在しない場合、 backupリソースはPending状態になります。 Kubernetes Operator は、この名前の MongoDB database リソースが作成されるまで、10 秒ごとに再試行します。

注意

この設定で参照するデータベース リソースにセキュリティを変更すると、 Kubernetes Operator はMongoDB Ops Managerリソースの調整を自動的に開始します。 Kubernetes Operator は、 の変更に基づいてMongoDB Ops Manager構成の mongoURI フラグと ssl フラグを更新します。

spec.backup.opLogStores.mongodbUserRef.name

: string

SCRAMOplog Store Databaseで 認証が有効になっている場合は必須です。MongoDBへの接続に使用される ユーザーOplog Store Database リソースの名前。このユーザー リソースをMongoDB Ops Managerのリソースと同じ名前空間に、次のすべてのロールを使用して配置します。

spec.backup.blockStores

タイプ: コレクション

ブロックストアを使用してバックアップを有効にする場合は必須です。 バックアップに使用されるブロックストアの配列。 配列内の各項目は、 Kubernetes Operator によって Kubernetes クラスターに配置された MongoDB database リソースを参照します。

spec.backup.blockStores.assignmentLabels

タイプ: 文字列の配列

ブロックストア の割り当てラベルのリスト。 割り当てラベルを使用して、特定のブロックストアが特定のプロジェクトに関連付けられていることを識別します。 Kubernetes Operator を使用して割り当てラベルを設定すると、割り当てラベルのKubernetes構成ファイルで設定した値が、 MongoDB Ops Manager UI で定義された値を上書きします。 Kubernetes Operator を使用して設定しない割り当てラベルは、 MongoDB Ops Manager UI で設定された値を引き続き使用します。

spec.backup.blockStores.name

: string

ブロックストアを使用してバックアップを有効にする場合は必須です。 ブロックストアの名前。

重要

一度指定したブロックストアの名前は編集しないでください。

spec.backup.blockStores.mongodbResourceRef.name

: string

ブロックストアを使用してバックアップを有効にする場合は必須です。 ブロックストア用に作成する MongoDB database リソースの名前。 このデータベース リソースは、 MongoDB Ops Managerリソースと同じ名前空間に配置する必要があります。

ブロックストア データベースはSCRAM認証メカニズムのみをサポートしています。 他の認証メカニズムを有効にすることはできません。

ブロックストア データベースでSCRAM認証を有効にする場合は、次の操作を行う必要があります。

  • をブロックストア データベースに接続するための MongoDBユーザー リソースを作成します。MongoDB Ops Manager

  • nameのリソース定義でユーザーのMongoDB Ops Manager を指定します。

この名前の MongoDB database リソースが存在しない場合、 backupリソースはPending状態になります。 Kubernetes Operator は、この名前の MongoDB database リソースが作成されるまで、10 秒ごとに再試行します。

注意

この設定で参照するデータベース リソースにセキュリティを変更すると、 Kubernetes Operator はMongoDB Ops Managerリソースの調整を自動的に開始します。 Kubernetes Operator は、 の変更に基づいてMongoDB Ops Manager構成の mongoURI フラグと ssl フラグを更新します。

spec.backup.blockStores.mongodbUserRef.name

: string

ブロックストア データベースで SCRAM 認証が有効になっている場合は必須です。 ブロックストア データベースに接続するために使用される MongoDB ユーザー リソースの名前。 このユーザー リソースをMongoDB Ops Managerのリソースと同じ名前空間に、次のすべてのロールを使用して配置します。

spec.backup.queryableBackupSecretRef.name

: string

配置の TLS 要件に基づいてバックアップへのアクセスとクエリを実行するために使用する からの Queryable.pem ファイルを含むシークレットの名前 。PEM ファイルには公開鍵証明書とそれに関連付けられた秘密キーが含まれており、 でバックアップ スナップショットに対してクエリを実行します。MongoDB Ops ManagerMongoDB Ops Managerバックアップをクエリするには、このパラメーターの値を指定します。 設定されていない場合、バックアップは影響を受けませんが、クエリはできません。

spec.backup.statefulSet.spec

タイプ: コレクション

ステートメントセット MongoDBEnterprise Kubernetes Operatorの仕様 が バックアップ デーモン サービス 用に作成する

spec.backup.statefulSet.specに追加できるフィールドを確認するには、「 StatulSetSpec v1 アプリ 」を参照してください (Kubernetes ドキュメント)。

spec.backup.statefulSet.spec.template

タイプ: コレクション

テンプレート Kubernetesステートメント セット内の ポッドの場合MongoDBEnterprise Kubernetes Operator が バックアップ デーモン サービス 用に作成する

spec.backup.statefulSet.spec.template.metadata

タイプ: コレクション

StateftSet 内の Kubernetes ポッドのメタデータ MongoDB Enterprise Kubernetes Operator が バックアップ デーモン サービス 用に作成する

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

spec.backup.statefulSet.spec.template.spec

タイプ: コレクション

StateftSet 内の Kubernetes ポッドの仕様 MongoDB Enterprise Kubernetes Operator が バックアップ デーモン サービス 用に作成する

spec.backup.statefulSet.spec.template.specに追加できるフィールドの完全なリストを確認するには、 Kubernetes のドキュメント を参照してください。

次の例では、 spec.backup.statefulSet.spec.template.specは、MongoDB Enterprise Kubernetes Operator が配置する 1 つのバックアップ デーモン サービスコンテナの最小と最大の CPU とメモリ容量を定義します。

statefulSet:
spec:
template:
spec:
containers:
- name: mongodb-backup-daemon
resources:
requests:
cpu: "0.50"
memory: "4500M"
limits:
cpu: "1"
memory: "6000M"
spec.backup.statefulSet.spec.template.spec.containers

タイプ: コレクション

ステートメントセット内の Kubernetes ポッドに属するコンテナのリスト MongoDB Enterprise Kubernetes Operator バックアップ デーモン サービス 用に作成する

バックアップデーモンのサービスコンテナの仕様を変更するには、次の例に示すように、 nameフィールドを使用してコンテナの正確な名前を指定する必要があります。

backup:
statefulSet:
spec:
template:
spec:
containers:
- name: mongodb-backup-daemon

注意

spec.backup.statefulSet.spec.template.spec.containersにコンテナを追加すると、Kubernetes Operator はそれらを Kubernetes ポッドに追加します。 これらのコンテナは、ポッド内のバックアップデーモン サービスコンテナに追加されます。

spec.backup.statefulSet.spec.template.spec.containers.resources.requests.cpu

: string

Kubernetes ノード で使用可能である必要がある最小 CPU 容量 バックアップデーモン サービスをホストします。

リクエスト値はspec.backup.statefulSet.spec.template.spec.containers.resources.limits.cpu以下である必要があります。

spec.backup.statefulSet.spec.template.spec.containers.resources.limits.cpu

: string

ノード の最大 CPU 容量 は、 バックアップ デーモン サービス をホストするために作成されています。省略された場合、この値はspec.backup.statefulSet.spec.template.spec.containers.resources.requests.cpuに設定されます。

spec.backup.statefulSet.spec.template.spec.containers.resources.requests.memory

: string

Kubernetes ノード で使用可能である必要がある最小メモリ容量 使用して、Kubernetes で バックアップ デーモン サービス をホストします。この値は、 JEDEC表記では、整数とそれに続くメモリ単位として表されます。

注意

この値は少なくとも4.5Giに設定します。 4.5Gi未満の値ではエラーが発生する可能性があります。

リクエスト値はspec.backup.statefulSet.spec.template.spec.containers.resources.limits.memory以下である必要があります。

spec.backup.statefulSet.spec.template.spec.containers.resources.limits.memory

: string

ノード の最大メモリ容量 は、 バックアップ デーモン サービス をホストするために作成されています。省略された場合、この値はspec.backup.statefulSet.spec.template.spec.containers.resources.requests.memoryに設定されます。

Kubernetes Operator は、コンテナのメモリに基づいて Java ヒープ サイズのパラメータを計算し、設定します。

警告

この値は 32 GB 未満に制限します

この値を 32 GB( 32Gi )を超える値に設定すると、バックアップサービスに問題が発生する可能性があります。 ヒープが過剰な場合、 MongoDB Ops Managerで予期しない結果を引き起こす可能性があります。

は、oplog MongoDB Ops Managerとバックアップ スナップショットの保存に S3 を使用し、カスタム CA によって発行されたキーを使用して TLS によって S3 への接続を保護するように構成できます。

カスタム CA キーを構成するに は、 リソース の配置TLS-Encrypted Connection (HTTPS) {2 タブで説明されているように、アプリケーション データベースの TLS を構成したMongoDB Ops Manager ConfigMap を使用します。この ConfigMap にspec.applicationDatabase.security.tls.caを設定します。

S3 とアプリケーション データベースの両方に TLS を使用することも、 S3 にのみ TLS を使用することもできます。

  • 両方にTLSを使用するには、ConfigMap で参照されている同じca-pemから両方の目的の証明書を取得します。

  • S3 のみで TLSspec.security.applicationDatabase.certsSecretPrefix を使用するには、ConfigMap で を定義しないでください。

spec.backup.s3OpLogStores.assignmentLabels

タイプ: 文字列の配列

S 3 oplog ストアの割り当てラベルのリスト。 割り当てラベルを使用して、特定のS 3 oplog ストアが特定のプロジェクトに関連付けられていることを識別します。 Kubernetes Operator を使用して割り当てラベルを設定すると、割り当てラベルのKubernetes構成ファイルで設定した値が、 MongoDB Ops Manager UI で定義された値を上書きします。 Kubernetes Operator を使用して設定しない割り当てラベルは、 MongoDB Ops Manager UI で設定された値を引き続き使用します。

spec.backup.s3OpLogStores.customCertificate

タイプ: ブール値

非推奨。 代わりにspec.backup.s3OpLogStores.customCertificateSecretRefsを使用してください。

S3 oplog ストアのカスタム TLS 証明書として AppDB 証明書(appdb-ca )を使用するかどうかを示すフラグ。デフォルトはFalseです。

spec.backup.s3OpLogStores.customCertificateSecretRefs

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

Kubernetes シークレット を使用した S3 oplog ストアのカスタム証明書のリスト 。基本64 でエンコードされた x。509 証明書は Kubernetes シークレット にすでに存在している必要があります キーと Java CertificateFactory によって解析可能である必要があります 。1 つのシークレット内で連鎖的に複数の証明書を指定することはできません。 1 つのシークレット内でチェーンに複数の証明書を指定した場合、Kubernetes Operator はチェーン内の最初の証明書のみを使用します。 customCertificate設定も指定した場合、Kubernetes Operator はバックアップのカスタム証明書としてspec.applicationDatabase.security.tls.caを使用します。

リスト内の各エントリは、 namekeyを指定します。 複数のシークレットを指定すると、Kubernetes Operator は指定されたシークレット内のすべての証明書を使用します。

この設定を指定しない場合、MongoDBMongoDB Ops Manager Ops Manager は、 で使用される JVM デフォルトの信頼ストアMongoDB Ops Manager を使用します。

spec.backup.s3OpLogStores.customCertificateSecretRefs.name

: string

S 3 oplog ストアのカスタム証明書を使用するために必要です。 Kubernetes secret カスタム証明書を含む

spec.configuration.mms.mongoDbUsage.defaultUsageType

: string

Kubernetes サービスのデフォルトのサーバータイプ。

spec.backup.s3OpLogStores.customCertificateSecretRefs.key

: string

S 3 oplog ストアのカスタム証明書を使用するために必要です。 シークレット 内のキーを表すファイル 基本64 でエンコードされた x509 を含む。 証明書この設定を指定しない場合、Kubernetes Operator はS 3 oplog ストアのバックアップにカスタム証明書を利用できません。

spec.backup.s3OpLogStores.irsaEnabled

タイプ: ブール値

サービス Amazon Web ServicesアカウントにAmazon Web Services IAM ロールの 使用を有効にするフラグ EKS3oplog の S ストアを構成します。デフォルトはFalseです。 Amazon Web Services EKS を使用していない場合、このフラグは効果がありません。 False に設定すると、EKS のサービスアカウントにAmazon Web Services IAM ロールを使用してS3 oplogストアを構成する方法が無効になります。 詳しくは、「 EKS のサービス アカウントの IAM ロール 」を参照してください。

spec.backup.s3OpLogStores.name

: string

S 3ストアを使用して oplog を保存するために必要です。 S 3 oplog ストアの名前。

spec.backup.s3OpLogStores.mongodbResourceRef.name

: string

S3 oplog ストアのメタデータを保存するために作成する MongoDB database リソースの名前。 このデータベース リソースは、 MongoDB Ops Managerリソースと同じ名前空間に配置する必要があります。

注意

この設定を省略すると、アプリケーション データベースを使用してS 3 oplog ストアのメタデータを保存します。

この設定を省略する場合は、 spec.backup.s3OpLogStores.mongodbUserRef.name設定も省略する必要があります。 Kubernetes Operator はSCRAMユーザー認証を内部的に処理します。

このデータベースでSCRAM認証を有効にする場合は、次の操作を行う必要があります。

  • をデータベースに接続するための MongoDBユーザー リソースを作成します。MongoDB Ops Manager

  • nameのリソース定義でユーザーのMongoDB Ops Manager を指定します。

spec.backup.s3OpLogStores.mongodbUserRef.name

: string

S 3 oplog メタデータを保存するための MongoDB データベース リソースを作成し、 かつ このデータベースで SCRAM が有効になっている場合は必須です。 S 3 oplog ストアのメタデータ データベースに接続するために使用される MongoDB ユーザー リソースの名前。 このユーザー リソースをMongoDB Ops Managerのリソースと同じ名前空間に、次のすべてのロールを使用して配置します。

重要

一度指定した後は、 S3メタデータ oplog ストアのユーザー名を編集しないでください。

spec.backup.s3OpLogStores.s3SecretRef.name

: string

S 3ストアを使用して oplog を保存するために必要です。 accessKeyフィールドとsecretKey フィールドを含むシークレットの名前。バックアップデーモン サービスは、これらのフィールドの値を認証情報として使用して、 Amazon Web Services S3またはS3互換バケットにアクセスします。 S 3 oplog ストアを構成するには、シークレットに両方のキーを指定する必要があります。

spec.backup.s3OpLogStores.pathStyleAccessEnabled

タイプ: ブール値

バケットエンドポイント URL のスタイルを示します。

説明
true
パス形式 URL
s3.amazonaws.com/<bucket>
false
仮想ホスト形式の URL
<bucket>.s3.amazonaws.com

注釈 についての詳細は、 での TLS サポート については、Amazon Web ServicesKubernetes のドキュメント を参照してください。

デフォルト値はtrueです。

spec.backup.s3OpLogStores.s3BucketEndpoint

: string

S 3ストアを使用して oplog を保存するために必要です。 URLストアをホストするAmazon Web Services S3バケットまたはS3互換バケットのoplog 。

注意

エンドポイントのURLにリージョンが含まれていない場合は、 s3RegionOverrideフィールドを指定します。

spec.backup.s3OpLogStores.s3BucketName

: string

S 3ストアを使用して oplog を保存するために必要です。 ストアをホストする Amazon Web ServicesS3 バケットまたは S3 互換バケットの名前。oplog

spec.backup.s3OpLogStores.s3RegionOverride

: string

S 3互換バケットが存在するリージョン。 S 3 oplog ストアのs3BucketEndpointがリージョン スコープをサポートしていない場合にのみ、このフィールドを使用します。 リージョンのスコープは 、エンドポイントがURLにリージョンを含めていない場合です。

このフィールドはAmazon Web Services S3バケットでは使用しないでください。 詳しくは、「 S 3ブロックストア構成 」を参照してください。

spec.backup.s3Stores.assignmentLabels

タイプ: 文字列の配列

がデータベースバックアップ スナップショットを 保存 する S3 または S 互換バケットの割り当てラベルのリスト。3割り当てラベルを使用して、特定のS 3ストアが特定のプロジェクトに関連付けられていることを識別します。 Kubernetes Operator を使用して割り当てラベルを設定すると、割り当てラベルのKubernetes構成ファイルで設定した値が、 MongoDB Ops Manager UI で定義された値を上書きします。 Kubernetes Operator を使用して設定しない割り当てラベルは、 MongoDB Ops Manager UI で設定された値を引き続き使用します。

spec.backup.s3Stores.customCertificate

タイプ: ブール値

非推奨。 代わりにspec.backup.s3Stores.customCertificateSecretRefsを使用してください。

アプリケーション データベースの証明書(appdb-ca )を S3 バックアップのカスタム TLS 証明書として使用するかどうかを示すフラグ。デフォルトはFalseです。

spec.backup.s3Stores.customCertificateSecretRefs

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

Kubernetes シークレット を使用した S3 スナップショット ストアのカスタム証明書のリスト 。基本64 でエンコードされた x。509 証明書は Kubernetes シークレット にすでに存在している必要があります キーと Java CertificateFactory によって解析可能である必要があります 。1 つのシークレット内で連鎖的に複数の証明書を指定することはできません。 1 つのシークレット内でチェーンに複数の証明書を指定した場合、Kubernetes Operator はチェーン内の最初の証明書のみを使用します。 spec.backup.s3Stores.customCertificate設定も指定した場合、Kubernetes Operator はバックアップのカスタム証明書としてspec.applicationDatabase.security.tls.caを使用します。

リスト内の各エントリは、 namekeyを指定します。 複数のシークレットを指定した場合、Kubernetes Operator は指定されたすべてのシークレットを使用します。

この設定を指定しない場合、Kubernetes Operator はバックアップに が使用する JVM デフォルトトラストMongoDB Ops Manager ストアを使用します。

spec.backup.s3Stores.customCertificateSecretRefs.name

: string

S 3 oplog ストアのカスタム証明書を使用するために必要です。 Kubernetes secret カスタム証明書を含む

spec.backup.s3Stores.customCertificateSecretRefs.key

: string

S 3 oplog ストアのカスタム証明書を使用するために必要です。 シークレット 内のキーを表すファイル 基本64 でエンコードされた x509 を含む。 証明書この設定を指定しない場合、Kubernetes Operator は S3 スナップショット ストアのカスタム証明書を利用できず、デフォルトは で使用されるデフォルトの JVM {Java Virtual Machine)MongoDB Ops Manager 信頼ストアになります。

spec.backup.s3Stores.irsaEnabled

タイプ: ブール値

サービス アカウントにAmazon Web Services IAM ロールの Amazon Web Services使用を有効にするフラグ EKS S スナップショット ストアを構成します。3デフォルトはFalseです。 Amazon Web Services EKS を使用していない場合、このフラグは効果がありません。 False に設定すると、EKS のサービスアカウントにAmazon Web Services IAM ロールを使用してS3スナップショット ストアを構成する方法が無効になります。 詳しくは、「 EKS のサービス アカウントの IAM ロール 」を参照してください。

spec.backup.s3Stores.name

: string

S 3ストアを使用して oplog を保存するために必要です。 S 3スナップショットストアの名前。

重要

S3スナップショットストアの名前を指定した後は、その名前を編集しないでください。 バックアップに古い名前が使用されている場合、この変更は失敗する可能性があります。 変更が成功した場合の影響は予測できません。

spec.backup.s3Stores.mongodbResourceRef.name

: string

S3スナップショット ストアのメタデータを保存するために作成するMongoDBリソースまたはMongoDBMultiClusterリソースの名前。 このデータベース リソースは、 MongoDB Ops Managerリソースと同じ名前空間に配置する必要があります。

注意

この設定を省略すると、アプリケーション データベースを使用してS 3スナップショット ストアのメタデータを保存します。

この設定を省略する場合は、 spec.backup.s3Stores.mongodbUserRef.name設定も省略する必要があります。 Kubernetes Operator はSCRAMユーザー認証を内部的に処理します。

このデータベースでSCRAM認証を有効にする場合は、次の操作を行う必要があります。

  • をデータベースに接続するための MongoDBユーザー リソースを作成します。MongoDB Ops Manager

  • nameのリソース定義でユーザーのMongoDB Ops Manager を指定します。

重要

S3スナップショットストアの名前を指定した後は、その名前を編集しないでください。 バックアップに古い名前が使用されている場合、この変更は失敗する可能性があります。 変更が成功した場合の影響は予測できません。

この名前の MongoDB database リソースが存在しない場合、 backupリソースはPending状態になります。 Kubernetes Operator は、この名前の MongoDB database リソースが作成されるまで、10 秒ごとに再試行します。

注意

この設定で参照するデータベース リソースにセキュリティを変更すると、 Kubernetes Operator はMongoDB Ops Managerリソースの調整を自動的に開始します。 Kubernetes Operator は、 の変更に基づいてMongoDB Ops Manager構成の mongoURI フラグと ssl フラグを更新します。

spec.backup.s3Stores.mongodbUserRef.name

: string

|s 3 | を保存するための MongoDB データベース リソースを作成した場合に必要このデータベースではスナップショット メタデータと SCRAM が有効になっています。 S 3スナップショット ストアのメタデータ データベースに接続するために使用される MongoDB ユーザー リソースの名前。 このユーザー リソースをMongoDB Ops Managerのリソースと同じ名前空間に、次のすべてのロールを使用して配置します。

重要

これを指定した後は、 S3メタデータ スナップショット ストアのユーザー名を編集しないでください。

spec.backup.s3Stores.s3SecretRef.name

: string

S 3ストアを使用してバックアップを有効にする場合は必須です。 accessKeyフィールドとsecretKey フィールドを含むシークレットの名前。バックアップデーモン サービスは、これらのフィールドの値を認証情報として使用して、 Amazon Web Services S3またはS3互換バケットにアクセスします。 シークレットにいずれかのキーがない場合、 S 3スナップショット ストアを構成することはできません。

spec.backup.s3Stores.pathStyleAccessEnabled

タイプ: ブール値

バケットエンドポイント URL のスタイルを示します。

説明
true
パス形式 URL
s3.amazonaws.com/<bucket>
false
仮想ホスト形式の URL
<bucket>.s3.amazonaws.com

デフォルト値はtrueです。

spec.backup.s3Stores.s3BucketEndpoint

: string

S 3ストアを使用してバックアップを有効にする場合は必須です。 URLAmazon Web Servicesスナップショット3 ストアをホストする S バケットまたは S3 互換バケットの 。

注意

エンドポイントのURLにリージョンが含まれていない場合は、 s3RegionOverrideフィールドを指定します。

spec.backup.s3Stores.s3BucketName

: string

S 3ストアを使用してバックアップを有効にする場合は必須です。 スナップショットストアをホストするAmazon Web Services S3バケットまたはS3互換バケットの名前。

spec.backup.s3Stores.s3RegionOverride

: string

S 3互換バケットが存在するリージョン。 S 3ストアのs3BucketEndpointがリージョン スコープをサポートしていない場合にのみ、このフィールドを使用します。 リージョンのスコープは 、エンドポイントがURLにリージョンを含めていない場合です。

このフィールドはAmazon Web Services S3バケットでは使用しないでください。 詳しくは、「 S 3ブロックストア構成 」を参照してください。

このセクションでは、 を構成するために、 必要なMongoDB Ops Manager 設定Ops Manager Application Database に加えて使用する必要がある設定について説明します。

spec.applicationDatabase.version

: string

必須Application Database MongoDBにインストールされているMongoDB Ops Manager のバージョン。コンテナ レジストリ のタグに基づいて、互換性のあるエンタープライズ MongoDB バージョンを指定する必要があります 。たとえば、 6.0.0-ubi8 。 Kubernetes Operator バージョン1以降。 20 、 タグが-entで終わることがなくなりました。

重要

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

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

注意

この値を Application Database 用のMongoDBの新しいバージョンに更新しても、機能の互換性バージョンはアップグレード元のMongoDBバージョンのままになり、必要に応じてダウングレードのオプションが提供されます。 機能の互換性バージョンを新しいMongoDBバージョンと一致させる場合は、 spec.applicationDatabaseの下のfeatureCompatibilityVersionパラメータを手動で設定する必要があります。

このセクションでは、Ops Manager Application Database に関連するオプションの設定について説明します。 MongoDB Ops Managerのマルチクラスター配置に固有のオプションのアプリケーション データベース設定については、「マルチクラスター設定 」を参照してください。

spec.applicationDatabase

タイプ: コレクション

MongoDB Ops Manager Application Databaseリソースの定義。

レプリカセットリソース仕様の次の設定は任意です。

注意

spec.applicationDatabase.agentの下のすべての設定は、 spec.applicationDatabase.agentspec.applicationDatabase.monitoringAgentでオートメーションとモニタリングの値を個別に指定しない限り、オートメーションとモニタリングの両方に適用されます。

spec.applicationDatabase.agent.<component>.logRotate

: オブジェクト

コンポーネントを次のいずれかの値に置き換えます。

  • mongod

  • backupAgent

  • monitoringAgent

プロセスの MongoDB ログをローテーションするための MongoDB 構成オブジェクト 。 設定を使用するには、ホストの syslog システムにログを書き込む場合に agent.<component>.logRotate設定を使用できないため、 をsystemLog.destination に設定する必要があります。fileagent.<component>.logRotate

spec.applicationDatabase.agent.mongod.logRotate.numTotal

タイプ: 整数

デフォルト: 0

MongoDB Ops Managerが保持するログファイルの合計数。 デフォルトを変更しない場合、 MongoDB Ops Managerは他の agent.<compenet>.logRotate 設定に基づいてローテーションを行います。

spec.applicationDatabase.agent.mongod.logRotate.numUncompressed

タイプ: 整数

デフォルト: 5

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

spec.applicationDatabase.agent.mongod.logRotate.percentOfDiskspace

タイプ: 数値

デフォルト: 0.02

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

spec.applicationDatabase.agent.<component>.logRotate.sizeThresholdMB

タイプ: 数値

コンポーネントを次のいずれかの値に置き換えます。

  • mongod

  • backupAgent

  • monitoringAgent

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

spec.applicationDatabase.agent.<component>.logRotate.timeThresholdHrs

タイプ: 整数

コンポーネントを次のいずれかの値に置き換えます。

  • mongod

  • backupAgent

  • monitoringAgent

ログ のローテーションに必須です。 次のローテーションまでの個々のログファイルの最大期間(時間単位)。 は最後のローテーション以降の時間です。 MongoDB Ops Managerは、 timeThresholdHrsまたはlogRotate.sizeThresholdMのいずれかに指定された値を満たす場合、ログファイルをすぐにローテーションします。

spec.applicationDatabase.agent.mongod.auditlogRotate

: オブジェクト

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

spec.applicationDatabase.agent.mongod.auditlogRotate.numTotal

タイプ: 整数

デフォルト: 0

MongoDB Ops Managerが保持する 監査ログ ファイルの合計数。 デフォルト値を変更しない場合、 MongoDB Ops Managerは他の agent.mongod.auditlogRotate 設定に基づいてローテーションを行います。

spec.applicationDatabase.agent.mongod.auditlogRotate.numUncompressed

タイプ: 整数

デフォルト: 5

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

spec.applicationDatabase.agent.mongod.auditlogRotate.percentOfDiskspace

タイプ: 数値

デフォルト: 0.02

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

spec.applicationDatabase.agent.mongod.auditlogRotate.sizeThresholdMB

タイプ: 数値

監査ログをローテーションする場合は必須です。 MongoDB Ops Managerが監査ログファイルをローテーションする前の個々の監査ログファイルの最大サイズ(MB 単位)。 MongoDB Ops Managerは、 sizeThresholdMBまたはauditlogRotate.timeThresholdHrs制限のいずれかで の値に達すると、監査ログファイルをすぐにローテーションします。

spec.applicationDatabase.agent.mongod.auditlogRotate.timeThresholdHrs

タイプ: 整数

監査ログ をローテーションする場合は必須です。 次のローテーションまでの個々の監査ログファイルの最大期間(時間単位)。 は最後のローテーション以降の時間です。 MongoDB Ops Managerは、監査ログファイルがtimeThresholdHrsまたはauditlogRotate.sizeThresholdMのいずれかで の値に達すると、すぐに監査ログファイルをローテーションします。

spec.applicationDatabase.agent.startupOptions

: オブジェクト

スタートアップ オプション用の MongoDB 構成オブジェクト 。 使用可能なフィールドについては、「 MongoDB Agent 設定」を参照してください。

spec.applicationDatabase.agent.systemLog

: オブジェクト

systemLogオプションを構成するための MongoDB 構成オブジェクト。

spec.applicationDatabase.agent.systemLog.path

: string

デフォルト: /var/log/mongodb-mms-automation/mongodb.log

mongodまたはmongosが標準出力やホストのsyslogではなく、すべての診断ログ情報を送信すべきログファイルのパス。 MongoDB は指定したパスにログファイルを作成します。

Linux パッケージ初期化スクリプトでは、 systemLog.pathがデフォルトから変更されることは想定されていません。 Linux パッケージを使用してsystemLog.pathを変更する場合は、独自の初期化スクリプトを使用し、組み込みスクリプトを無効にする必要があります。

spec.applicationDatabase.agent.systemLog.logAppend

タイプ: ブール値

デフォルト: false

trueの場合、mongos または インスタンスの再起動時に、mongod mongosmongodまたは は既存のログファイルの末尾に新しいエントリを追加します。このオプションを指定しない場合、 mongodは既存のログをバックアップして新しいファイルを作成します。

spec.applicationDatabase.agent.systemLog.destination

: string

MongoDB がすべてのログ出力を送信する宛先です。file または syslog を指定します。file を指定する場合は、systemLog.path も指定する必要があります。

systemLog.pathを指定しない場合、MongoDB はすべてのログ出力を標準出力に送信します。

警告

syslog デーモンは、MongoDB によりメッセージが発行されたときではなく、メッセージがログに記録されたときにタイムスタンプを生成します。 この動作により、特にシステムの負荷が高い場合に、ログエントリのタイムスタンプに誤りが生じる可能性があります。 タイムスタンプが正確になるように、実稼働システムではfileオプションを使用することをお勧めします。

spec.applicationDatabase.memberConfig

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

MongoDB Ops Manager配置内の各アプリケーション データベース レプリカセット ノードの仕様。

重要

spec.topologyMultiClusterspec.applicationDatabase.clusterSpecList.memberConfig spec.applicationDatabase.memberConfigに設定する場合は、 ではなく を使用します。MongoDB Ops Managerのマルチクラスター配置では、 Kubernetes Operator はspec.applicationDatabase.memberConfig の下のすべてのパラメータを無視します。

memberConfigリスト内の要素数はspec.applicationDatabase.membersと等しくなければなりません。

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

アプリケーション データベースの 3 つのノードからなるレプリカセットの次の指定例を検討してみましょう。

spec:
applicationDatabase:
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"
tags:
tag2: "value2"
environment: "prod"
spec.applicationDatabase.memberConfig.priority

: string

アプリケーション データベースのレプリカセットがプライマリ になる相対的な可能性を示す数値。

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

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

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

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

spec.applicationDatabase.memberConfig.tags

タイプ: map

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

spec.applicationDatabase.memberConfig.votes

タイプ: 数値

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

spec.applicationDatabase.passwordSecretKeyRef.name

: string

MongoDB Ops Manager データベース ユーザーmongodb-ops-managerのパスワードを含むシークレットの名前。 MongoDB Ops Manager はこのパスワードを使用して、アプリケーション データベースに認証します。

spec.applicationDatabase.passwordSecretKeyRef.key

: string

MongoDB Ops Manager データベース ユーザーmongodb-ops-managerのパスワードを含むシークレット内のフィールドの名前。 MongoDB Ops Manager はこのパスワードを使用して、アプリケーション データベースに認証します。

デフォルト値は password です。

spec.applicationDatabase.security.certsSecretPrefix

: string

Kubernetes シークレット のプレフィックスに適用するテキスト アプリケーション データベースの TLS キーと証明書を含む、 作成した

シークレットには<prefix>-<metadata.name>-db-certという名前を付ける必要があります。

MongoDB Ops ManagerインスタンスをHTTPS 経由で実行するように構成する方法については、「 MongoDB Ops Managerリソースの配置 」を参照してください。

spec.applicationDatabase.security.tls.ca

: string

Kubernetes ConfigMap の名前 。アプリケーション データベースの CA ファイルが含まれています。

重要

spec.applicationDatabase.security.tls.caカスタム CA を使用してアプリケーション データベースの TLS 証明書に署名する場合は、 が必要です。

Kubernetes Operator では、ConfigMap でアプリケーション データベースの証明書ca-pemに名前を付ける必要があります。

このセクションで指定される CA は、 またはspec.backup.s3OpLogStores.customCertificatespec.backup.s3Stores.customCertificate のいずれかが に設定されている場合に、 S3 ストレージ用のカスタム TLStrue 証明書の構成にも使用されます。

このCAは、次の証明書に署名します。

  • アプリケーション データベースのレプリカセットのノードは相互に通信するために使用し、

  • MongoDB Ops Manager は を使用して Application Database レプリカセットと通信します。

警告

アプリケーション データベースが再起動した場合に が操作不能になるのを防ぐために、 からカスタム CA ファイルと TLS 証明書チェーン全体を連結する必要があります。downloads.mongodb.comMongoDB Ops Manager

spec.applicationDatabase.security.tls.enabled

重要

spec.security.applicationDatabase.tls.enabled は非推奨であり、将来のリリースで削除される予定です。 TLSを有効にするには、 spec.security.applicationDatabase.certsSecretPrefix設定の値を指定します。

MongoDB Ops Manager とアプリケーション データベース間のTLS証明書を使用して通信を暗号化します。

アプリケーション データベースで Prometheus を使用する場合、次の設定が適用されます。

spec.applicationDatabase.prometheus

タイプ: 配列

任意。 Prometheus にメトリクスを公開するためのパラメーターを含むリスト。

spec.applicationDatabase.prometheus.metricsPath

: string

デフォルト: "/metrics"

任意。 メトリクス エンドポイントへのパスを示す、人間が判読可能なstring 。 この設定を指定しない場合、デフォルトが適用されます。

spec.applicationDatabase.prometheus.passwordSecretRef

: オブジェクト

シークレット の詳細を含む 条件付き オブジェクト 基本的な HTTP 認証用。アプリケーション データベースで Prometheus を使用する場合は、この設定を指定する必要があります。

spec.applicationDatabase.prometheus.passwordSecretRef.key

: string

デフォルト: "password"

任意。 シークレット 内の鍵を識別する、人間が判読可能な 基本的なstringHTTP 認証のパスワードを保存します。この設定を指定しない場合、デフォルトが適用されます。

spec.applicationDatabase.prometheus.passwordSecretRef.name

: string

条件付き

秘密 を識別する、人間が判読可能なラベル 基本的な HTTP 認証用のパスワードを含むアプリケーション データベースで Prometheus を使用する場合は、この設定を指定する必要があります。

spec.applicationDatabase.prometheus.port

タイプ: 整数

デフォルト: 9216

任意。 メトリクス エンドポイントがバインドするポートを識別する番号。 この設定を指定しない場合、デフォルトが適用されます。

spec.applicationDatabase.prometheus.tlseSecretKeyRef

: オブジェクト

任意シークレット の詳細を含むオブジェクト TLS 認証用。

spec.applicationDatabase.prometheus.tlseSecretKeyRef.key

: string

デフォルト: "password"

任意。 シークレットstring 内の鍵を識別する、人間が判読可能な は TLS 認証用のパスワードを保存します。この設定を指定しない場合、デフォルトが適用されます。

spec.applicationDatabase.prometheus.tlseSecretKeyRef.name

: string

条件付き秘密 を識別する、人間が判読可能なラベル TLS 認証用のパスワードを含むアプリケーション データベースで Prometheus を使用し、 TLS認証を使用する場合は、この設定を指定する必要があります。

spec.applicationDatabase.prometheus.username

: string

条件付き。 基本的な HTTP 認証のユーザーを識別する、人間が判読可能なラベル。 アプリケーション データベースで Prometheus を使用する場合は、この設定を指定する必要があります。

このセクションでは、必要な MongoDB Ops Manager 設定に加えて、マルチクラスターMongoDB Ops Manager配置に使用する必要がある設定について説明しMongoDB Ops Manager 。

spec.clusterSpecList.members

タイプ: 整数

条件付き。 マルチ Kubernetes クラスター MongoDB Ops Manager配置内の クラスター内の OpsMongoDB Ops ManagerMongoDB Manager ノードの数。spec.topologyMultiClusterに設定する場合は、このパラメータの値を指定する必要があります。 単一クラスター配置の場合は、このパラメーターを省略します。 このパラメーターを 0 に設定すると、このMongoDB Ops Managerノードクラスターは、 MongoDB Ops Managerインスタンスのマルチ Kubernetes クラスター内のノードクラスターのリストから削除されます。

spec.topology

: string

KubernetesリソースのMongoDB Ops Manager 配置のタイプ。

  • 値はSingleClusterまたはMultiClusterです。 省略した場合、デフォルト値はSingleClusterです。

  • MultiClusterを指定した場合

MongoDB Ops Managerのリソースでは、マルチクラスターのMongoDB Ops Manager配置に固有の次の設定も使用できます。

spec.clusterSpecList

タイプ: コレクション

条件付き。 またはバックアップデーモン Kubernetesインスタンスを配置する予定の複数のKubernetes クラスターで、選択した ノード クラスターの詳細。MongoDB Ops Managerリソース仕様の例も参照してください。

spec.clusterSpecList.clusterName

: string

任意。 が をスケジュールする の複数の配置にある クラスターのノード名Kubernetes KubernetesMongoDBMongoDBEnterprise Kubernetes Operatorまたはバックアップデーモン用。MongoDB Ops Manager

spec.clusterSpecList.clusterDomain

: string

任意spec.clusterDomain特定のMongoDB Ops Manager ノードクラスターの の上書き。この値を省略すると、 はデフォルトでspec.clusterDomainに設定された値になります。 Kubernetes は各 ポッド を割り当てます FQDN 。Kubernetes 演算子は、各 ポッド の FQDN を計算します 指定されたclusterDomain 値を使用します。Kubernetes では、これらのホスト名をクエリするためのAPIは提供されていません。

spec.clusterSpecList.configuration

タイプ: コレクション

任意。 MongoDB Ops Manager特定のクラスターのspec.configuration で設定したプロパティを上書きする の構成プロパティ。プロパティ名と説明については、「 MongoDB Ops Managerの構成設定」を参照してください。 各プロパティはstring型の値を受け取ります。 たとえば、これらのプロパティを設定すると、その特定のノード クラスター内のMongoDB Ops Managerとバックアップ デーモンに渡す必要がある環境変数を変更できます。

値の指定を省略すると、 はデフォルトでspec.configurationに設定された値になります。

spec.clusterSpecList.jvmParameters

タイプ: 文字列の配列

任意。 このノード クラスターの MongoDB Ops Manager インスタンスとバックアップデーモン インスタンスに渡されるJVMパラメーター。

spec.clusterSpecList.externalConnectivity

タイプ: コレクション

任意。 特定のクラスターの MongoDB Ops Manager への外部接続を有効にする 構成 オブジェクト。 これは、特定のクラスターのspec.externalConnectivityの上書きです。

MongoDB Ops Managerアプリケーションがさまざまなクラスターで外部に公開される方法を変更するには、このパラメーターの値を指定します。 たとえば、異なるクラウドプロバイダーのMongoDB Ops Manager Kubernetesノードに配置する場合は、このパラメーターにクラウドプロバイダー固有の値を指定する必要がある場合があります。

このパラメーターを設定すると、次の効果が生じます。

  • Kubernetesspec.externalConnectivity演算子は、このノードの クラスターにMongoDB Ops Manager 値を使用しません。

  • KubernetesOperator はKubernetes サービス を作成します<om-name>-svc-ext 、 という名前のKubernetes は、MongoDB Ops Manager クラスターの外部から送信されるトラフィックが、このノード クラスター上の アプリケーションに到達することを許可します。

このパラメーターを省略すると、Kubernetes Operator はこのノードクラスターに対してspec.externalConnectivityの値を使用します。

spec.clusterSpecList.statefulSet.spec

タイプ: コレクション

任意。 ステートメントセット MongoDBEnterprise Kubernetes OperatorKubernetesMongoDB Ops Managerの仕様 が、複数の クラスター 配置内の特定のノードクラスターに対して作成するこのパラメータはspec.statefulSet.specの上書きです。 省略すると、Kubernetes 演算子はspec.statefulSet.specの値を使用します。 たとえば、このパラメーターを使用して、Kubernetes クラスター のマルチ配置内の各 クラスターに対して異なるストレージ値を指定できます。MongoDB Ops ManagerMongoDB

spec.clusterSpecList.statefulSet.specに追加できるフィールドを確認するには、「 StatulSetSpec v1 アプリ 」を参照してください (Kubernetes ドキュメント)。

spec.clusterSpecList[*].backup

任意。 その特定のノード クラスターのspec.backupで指定された値を上書きするバックアップ設定。

  • これらの値は、 spec.backup.enabledtrueに設定されている場合にのみ設定できます。

  • このパラメータの値を設定しない場合、デフォルトはspec.backupの下の設定で指定された値になります。

  • このオーバーライドでは、すべてのバックアップ設定がサポートされていません。 次のバックアップ設定は、 spec.backupで指定されている場合、すべてのノード クラスターにグローバルに適用されるため、上書きできません。

    • externalServiceEnabled

    • headDB

    • opLogStores

    • blockStores

    • s3Stores

    • fileSystemStores

    • queryableBackupSecretRef

    • encryption

spec.clusterSpecList[*].backup.members

タイプ: 整数

任意spec.backup.membersのオーバーライド。 このクラスターに配置するバックアップデーモン インスタンスの数。 この値を省略するか、 0の値を指定すると、Kubernetes Operator は特定のノードクラスターにバックアップデーモン インスタンスを配置しません。

spec.clusterSpecList[*].backup.assignmentLabels

タイプ: 文字列の配列

任意spec.backup.assignmentLabelsのオーバーライド。 指定すると、Kubernetes Operator は、特定のノードクラスター内のすべてのバックアップデーモン インスタンスに対して、このオーバーライドで指定した値を使用します。 このパラメータの値を省略すると、値はデフォルトで ノードクラスター内のすべてのバックアップデーモン インスタンスのspec.backup.assignmentLabelsで指定された値になります。

spec.clusterSpecList[*].backup.jvmParameters

タイプ: 文字列の配列

任意spec.backup.jvmParametersのオーバーライド。 特定のノード クラスター内のバックアップデーモン インスタンスのJVM値をカスタマイズできます。

spec.clusterSpecList[*].backup.statefulSet

: string

任意spec.backup.statefulSet.specのオーバーライド。 特定のノードクラスター内のバックアップデーモンの 値をカスタマイズできます。 spec.clusterSpecList[*].backup.statefulSetに追加できるフィールドを確認するには、「 StatulSetSpec v1 アプリ 」を参照してください (Kubernetes ドキュメント)。

このセクションでは、アプリケーション データベースで使用する必要があるマルチクラスターMongoDB Ops Manager配置に固有の設定について説明します。

spec.applicationDatabase.clusterSpecList

タイプ: コレクション

MongoDB のマルチ Kubernetes クラスター配置で、アプリケーション データベースをホストするノードとして機能する選択した Kubernetes ノード クラスターの詳細。

spec.applicationDatabase.clusterSpecList.clusterName

: string

MongoDB Enterprise Kubernetes Operator がステートメントをスケジュールする MongoDB のマルチ Kubernetes クラスター MongoDB 配置内のメンバーの Kubernetes クラスターの名前 : アプリケーション データベース用。

重要

CRDclusterSpecListtopology と の設定を変更して、単一の インスタンスを複数のMongoDB Ops Manager Kubernetes クラスターの 配置インスタンスに変換することはできません。MongoDB

spec.applicationDatabase.clusterSpecList.members

タイプ: 数値

指定されたノード クラスター内のステートメント ノードの数。 ノードクラスターは、Kubernetes クラスターの MongoDB 配置でアプリケーション データベースをホストするノード クラスターの 1 つです。

spec.applicationDatabase.topology

: string

アプリケーション データベースの Kubernetes 配置のタイプ。

  • 値はSingleClusterまたはMultiClusterです。 省略した場合、デフォルト値はSingleClusterです。

  • MultiClusterを指定する場合は、少なくとも 1 つのメンバーを指定する必要があります

  • clusterSpecListclusterNamemembersパラメータを使用してアプリケーション データベースを配置するクラスター。

  • MultiClusterを指定すると、Kubernetes Operator はspec.applicationDatabase.membersフィールドに設定した値を無視します。

詳しくは、 マルチクラスターのリソース仕様 の例を参照してください。

このセクションでは、アプリケーション データベースで使用できるマルチクラスターMongoDB Ops Manager配置に固有の設定について説明します。

spec.applicationDatabase.clusterSpecList.memberConfig

タイプ: 文字列の配列

マルチクラスターMongoDB Ops Manager配置内の各アプリケーション データベース レプリカセット ノードの仕様。

重要

spec.topologySingleClusterspec.applicationDatabase.clusterSpecList.memberConfigspec.applicationDatabase.memberConfig に設定する場合は、 ではなく を使用します。

memberConfigリスト内の要素数はspec.applicationDatabase.clusterSpecList.membersと等しくなければなりません。

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

アプリケーション データベースの 3 つのノードからなるレプリカセットの次の指定例を検討してみましょう。

spec:
replicas: 3
version: 4.4.1
backup:
enabled: true
storage:
resources:
requests:
storage: 10Gi
storageClassName: standard
applicationDatabase:
clusterSpecList:
- name: appdb
members: 3
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"
tags:
tag2: "value2"
environment: "prod"
spec.applicationDatabase.clusterSpecList.memberConfig.priority

: string

アプリケーション データベースのレプリカセットがプライマリ になる相対的な可能性を示す数値。

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

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

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

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

spec.applicationDatabase.clusterSpecList.memberConfig.tags

タイプ: map

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

spec.applicationDatabase.clusterSpecList.memberConfig.votes

タイプ: 数値

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

戻る

参照