マルチKubernetes-クラスターリソース仕様

このバージョンのドキュメントはアーカイブされており、サポートされなくなりました。のバージョンをアップグレードする方法については、現在のドキュメントMongoDBEnterprise Kubernetes Operator を表示します。

MongoDBMultiClusterリソースは、複数の Kubernetes クラスターのMongoDBデプロイを定義し、MongoDB Enterprise Kubernetes Operator に、クラスター、MongoDB Ops Manager の配置、StatefulSets、サービス、およびその他のKubernetesリソースを作成または更新するために必要な情報を提供します。

例

次の例は、マルチ Kubernetes クラスター MongoDB 配置のリソース仕様を示しています。

1 # This example provides statefulSet overrides per cluster.
2 
3 apiVersion: mongodb.com/v1
4 kind: MongoDBMultiCluster
5 metadata:
6   name: multi-replica-set
7 spec:
8   version: 4.4.0-ent
9   type: ReplicaSet
10   duplicateServiceObjects: false
11   credentials: my-credentials
12   opsManager:
13     configMapRef:
14       name: my-project
15   clusterSpecList:
16     - clusterName: cluster1.example.com
17       members: 2
18       statefulSet:
19         spec:
20           template:
21             spec:
22               containers:
23                 # Example of custom sidecar containers. Remove it before using the file in production.
24                 - name: sidecar1
25                   image: busybox
26                   command: [ "sleep" ]
27                   args: [ "infinity" ]
28           # Use the following settings to override the default storage size of the "data" Persistent Volume.
29           volumeClaimTemplates:
30             - metadata:
31                 name: data
32               spec:
33                 resources:
34                   requests:
35                     storage: 1Gi
36     - clusterName: cluster2.example.com
37       members: 1
38       statefulSet:
39         spec:
40           template:
41             spec:
42               containers:
43                 # Example of custom sidecar containers. Remove it before using the file in production.
44                 - name: sidecar2
45                   image: busybox
46                   command: [ "sleep" ]
47                   args: [ "infinity" ]
48           volumeClaimTemplates:
49             - metadata:
50                 name: data
51               spec:
52                 resources:
53                   requests:
54                     storage: 1Gi
55     - clusterName: cluster3.example.com
56       members: 1
57       statefulSet:
58         spec:
59           template:
60             spec:
61               containers:
62                 # Example of custom sidecar containers. Remove it before using the file in production.
63                 - name: sidecar3
64                   image: busybox
65                   command: [ "sleep" ]
66                   args: [ "infinity" ]
67           volumeClaimTemplates:
68             - metadata:
69                 name: data
70               spec:
71                 resources:
72                   requests:
73                     storage: 1Gi
74 
75 ...

必要な`MongoDBMultiCluster` リソース設定

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

apiVersion

型: string

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

kind

型: string

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

metadata.name

型: string

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

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

spec.credentials

型: string

通信するための Operator MongoDB Ops ManagerAPIの認証情報としてが作成KubernetesMongoDB Ops Manager したシークレットの名前。

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

重要

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

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

spec.type

型: string

作成する MongoDB Kubernetes リソースのタイプ。 MongoDB のマルチ Kubernetes クラスター配置で使用される値はReplicaSetのみです。

spec.version

型: string

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

重要

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

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

注意

この値を新しいバージョンにアップデートする場合は、必要に応じてダウングレードのオプションを付与するために、 spec.featureCompatibilityVersionを設定することを検討してください。

任意の`MongoDBMultiCluster` リソース設定

MongoDBMultiCluster リソースは、次の設定を使用できます。

spec.additionalMongodConfig

タイプ: コレクション

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

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

net.port
net.tls.certificateKeyFile
net.tls.clusterFile
net.tls.PEMKeyFile
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

spec.backup

タイプ: コレクション

spec.backup.modeのコレクションコンテナ、これにより、Kubernetes Operator 内の MongoDB リソースの継続的なバックアップが可能になります。

spec.backup.assignmentLabels

タイプ: 配列

A list of assignment labels for the backup-daemon processes. Use assignment labels to identify that specific backup daemon processes are associated with particular projects. If you set assignment labels using the Kubernetes Operator, the values that you set in the Kubernetes configuration file for assignment labels override the values defined in the Ops Manager UI. Assignment labels that you don't set using the Kubernetes Operator continue to use the values set in the Ops Manager UI.

spec.backup.autoTerminateOnDeletion

タイプ: ブール値

MongoDBMultiClusterリソースを削除すると、Kubernetes Operator がバックアップを停止して終了するかどうかを示すフラグ。デフォルト値はfalseです。このフラグをtrueに設定すると、 spec.backup.mode設定がenabledに設定されているときにMongoDBMultiClusterリソースを削除する場合に役立ちます。

spec.backup.encryption

型: オブジェクト

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

spec.backup.encryption.kmip

型: オブジェクト

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

spec.backup.encryption.kmip.client

型: オブジェクト

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

spec.backup.mode

型: string

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

注意

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

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

spec.backup.snapshotSchedule

タイプ: コレクション

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

spec.backup.snapshotSchedule.dailySnapshotRetentionDays

タイプ: 数値

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

spec.backup.snapshotSchedule.fullIncrementalDayOfWeek

型: string

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

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.snapshotIntervalHours

タイプ: 数値

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

spec.backup.snapshotSchedule.snapshotRetentionDays

タイプ: 数値

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

spec.backup.snapshotSchedule.weeklySnapshotRetentionWeeks

タイプ: 数値

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

spec.cloudManager.configMapRef.name

型: string

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

spec.clusterSpecList

タイプ: コレクション

MongoDBMultiClusterリソース内の各 Kubernetes クラスターの仕様のリスト。

spec.clusterSpecList.clusterName

型: string

MongoDB Enterprise Kubernetes Operator がステートメントをスケジュールするクラスターの名前。Kubernetes Operator がこの MongoDBMultiClusterリソースを配置すると、サービスアカウントが作成されます。この名前は、演算子クラスター内のサービスアカウントがワークロードクラスターと通信するために使用するものです。

spec.clusterSpecList.externalAccess.externalDomain

型: string

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

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

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

以下に例を挙げます。

multi-replica-set-0-1.cluster-0.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 フィールドの値を変更することはできません。

重要

この設定は、マルチ Kubernetes クラスターの MongoDB 配置レプリカセットをサービスキャッシュなしで配置する場合にのみ使用します。「サービスメッシュを使用せずにマルチ Kubernetes クラスターにレプリカセットを配置する」を参照してください。

spec.clusterSpecList.externalAccess.externalService

タイプ: コレクション

マルチ Kubernetes クラスター MongoDB 配置で特定のクラスターを外部で公開するための構成。これらの設定は、グローバルspec.externalAccess.externalService 設定。

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.clusterSpecList.externalAccess.externalService.annotations

タイプ: コレクション

キーと値のペア。このペアでは、マルチ Kubernetes クラスターMongoDBデプロイ内の特定のクラスターにクラウドプロバイダー固有の構成設定を追加できます。この設定はグローバル設定（spec.externalAccess.externalService.annotations）を上書きします。詳しくは、「 Kubernetesクラウドプロバイダー」の注釈とドキュメントを参照してください。

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

値	説明
`{resourceName}`	`metadata.name`に等しい。
`{namespace}`	`metadata.namespace`に等しい。
`{podIndex}`	StateftSet によって割り当てられ、現在の外部サービスが対象とするポッドのインデックス。
`{podName}`	`{resourceName}-{clusterIndex}-{podIndex}`に等しい。
`{clusterName}`	spec.clusterSpecList.clusterName に設定されている現在のクラスター名。
`{clusterIndex}`	spec.clusterSpecList.clusterName で設定された現在のクラスター名に対してKubernetes Operator によって最初に割り当てられたインデックス。この値は、spec.clusterSpecList で定義されたノードクラスターの順序を反映していない可能性があります。spec.clusterSpecList でメンバークラスターの順序を変更できますが、 Kubernetes Operator は現在のクラスター名に最初に割り当てられたインデックスを引き続き使用します。
`{statefulSetName}`	ステートメント。は `{resourceName}-{clusterIndex}` と等しいです。
`{externalServiceName}`	指定したプレースホルダー値に基づいて、外部サービスの生成された名前。 `{resourceName}-{clusterIndex}-{podIndex}-svc-external`に等しい。
`{mongodProcessDomain}`	mongodプロセスをホストしているサーバーのドメイン名。 spec.externalAccess.externalDomain と等しい指定されている場合それ以外の場合は、`mongod` プロセス FQDN に使用されるドメインと等しくなります。たとえば、プロセスホスト名`mdb-rs-1.example.com`の場合、 `example.com`はドメイン名になります。
`{mongodProcessFQDN}`	`mongod`オートメーション構成で設定されたプロセスのホスト名。プロセスホスト名は、配置構成によって異なります。サービスメトリクスがない配置など、外部ドメインを使用するように複数の Kubernetes クラスターMongoDBデプロイを構成した場合、プロセスホスト名は次の形式を使用します。 `{resourceName}-{clusterIndex}-{podIndex}.{mongodProcessDomain}` 以下に例を挙げます。 `mdb-rs-0-1.example.com` 配置で外部ドメインを使用しない場合、プロセスホスト名は次の形式を使用します。 `{resourceName}-{clusterIndex}-{podIndex}-svc.{namespace}.svc.cluster.local` 以下に例を挙げます。 `mdb-rs-1-svc.ns.svc.cluster.local`

注意

表に指定されている既知のプレースホルダー値のみを使用し、プレースホルダーが空または null 値を使用しないようにする必要があります。それ以外の場合、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.clusterSpecList.externalAccess.externalService.spec

タイプ: コレクション

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

spec.clusterSpecList.memberConfig

タイプ: コレクション

マルチ Kubernetes クラスター MongoDB 配置内の各 MongoDB レプリカセットとそのノードの仕様。

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

例

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

apiVersion: mongodb.com/v1
kind: MongoDBMultiCluster
metadata:
  name: multi-replica-set
spec:
  version: 4.4.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"

spec.clusterSpecList.memberConfig.priority

型: string

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

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

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

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

spec.clusterSpecList.memberConfig.tags

タイプ: map

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

spec.clusterSpecList.memberConfig.votes

タイプ: 数値

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

spec.clusterSpecList.members

タイプ: 数値

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

spec.clusterSpecList.service

型: string

デフォルト: <resource_name>+"-service"

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

spec.clusterSpecList.statefulSet.spec

タイプ: コレクション

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

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

spec.connectivity.replicaSetHorizons

タイプ: コレクション

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

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

注意

この配列内の各値が一意であることを確認してください。
この配列内のエントリの数がspec.clusterSpecList.members に指定された値と一致していることを確認します。
spec.security.certsSecretPrefixの値の指定 TLSを有効にするには、に設定します。このメソッドでスプリットホライズンを使用するには、 TLSプロトコルのサーバー名表示拡張機能が必要です。
外部ホスト名のルーティングを構成します。

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

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.duplicateServiceObjects

タイプ: ブール値

デフォルト: true

Kubernetes Operator が DNS 解決を可能にするために各クラスター内のポッドのサービスキャッシュオブジェクトを複製するかどうかを指定します。サービスメッシュに DNS プロキシを構成する場合は、を false に設定します。例については、 Istio ドキュメントの DNS プロキシを参照してください。

spec.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 ）を追加します。

spec.externalAccess.externalService

タイプ: コレクション

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

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 クラスターMongoDBデプロイ内のすべてのクラスターに追加できるキーと値のペア。クラスター固有のオーバーライドについては、spec.clusterSpecList.externalAccess.externalService.annotations を参照してください。詳細については、「 Kubernetes配置に使用するクラウドプロバイダーの注釈」と「ドキュメント」を参照してください。

値	説明
`{resourceName}`	`metadata.name`に等しい。
`{namespace}`	`metadata.namespace`に等しい。
`{podIndex}`	StateftSet によって割り当てられ、現在の外部サービスが対象とするポッドのインデックス。
`{podName}`	`{resourceName}-{clusterIndex}-{podIndex}`に等しい。
`{clusterName}`	spec.clusterSpecList.clusterName に設定されている現在のクラスター名。
`{clusterIndex}`	spec.clusterSpecList.clusterName で設定された現在のクラスター名に対してKubernetes Operator によって最初に割り当てられたインデックス。この値は、spec.clusterSpecList で定義されたノードクラスターの順序を反映していない可能性があります。spec.clusterSpecList でメンバークラスターの順序を変更できますが、 Kubernetes Operator は現在のクラスター名に最初に割り当てられたインデックスを引き続き使用します。
`{statefulSetName}`	ステートメント。は `{resourceName}-{clusterIndex}` と等しいです。
`{externalServiceName}`	指定したプレースホルダー値に基づいて、外部サービスの生成された名前。 `{resourceName}-{clusterIndex}-{podIndex}-svc-external`に等しい。
`{mongodProcessDomain}`	mongodプロセスをホストしているサーバーのドメイン名。 spec.externalAccess.externalDomain と等しい指定されている場合それ以外の場合は、`mongod` プロセス FQDN に使用されるドメインと等しくなります。たとえば、プロセスホスト名`mdb-rs-1.example.com`の場合、 `example.com`はドメイン名になります。
`{mongodProcessFQDN}`	`mongod`オートメーション構成で設定されたプロセスのホスト名。プロセスホスト名は、配置構成によって異なります。サービスメトリクスがない配置など、外部ドメインを使用するように複数の Kubernetes クラスターMongoDBデプロイを構成した場合、プロセスホスト名は次の形式を使用します。 `{resourceName}-{clusterIndex}-{podIndex}.{mongodProcessDomain}` 以下に例を挙げます。 `mdb-rs-0-1.example.com` 配置で外部ドメインを使用しない場合、プロセスホスト名は次の形式を使用します。 `{resourceName}-{clusterIndex}-{podIndex}-svc.{namespace}.svc.cluster.local` 以下に例を挙げます。 `mdb-rs-1-svc.ns.svc.cluster.local`

注意

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.featureCompatibilityVersion

タイプ: 数値

新しいメジャーバージョンへのアップグレードに関連して発生するデータの変更を制限します。 This allows you to downgrade to the previous major version. 機能の互換性の詳細については、MongoDB マニュアルのsetFeatureCompatibilityVersionを参照してください。

spec.logLevel

型: string

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

DEBUG
INFO
WARN
ERROR
FATAL

spec.opsManager.configMapRef.name

型: string

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

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

重要

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

Kubernetes 演算子は、ConfigMap への変更を追跡し、 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.security.authentication

タイプ: コレクション

マルチ Kubernetes クラスター MongoDB 配置の認証仕様。

spec.security.authentication.agents

タイプ: コレクション

MongoDB AgentCloud ManagerまたはMongoDB Ops Manager プロジェクトの認証構成。

spec.security.authentication.agents.automationLdapGroupDN

型: string

MongoDB Agent ユーザーが属する LDAP グループの DN（Distinguished Name、識別名）。

この設定は、次の場合に必要です。

spec.security.authentication.ldap.authzQueryTemplateが存在し、かつ
spec.security.authentication.agents.modeはLDAPまたはX509です。

spec.security.authentication.agents.automationPasswordSecretRef

タイプ: コレクション

spec.security のパスワードを含むシークレットの詳細。認証. Agents.AutomationUserNameユーザー。

この設定は、 spec.security.authentication.agents.modeがLDAPの場合に必要です。

spec.security.authentication.agents.automationPasswordSecretRef.key

型: string

spec.security 内のキー。認証.agents.automationPasswordSecretRef.name のシークレット。認証

この設定は、 spec.security.authentication.agents.modeがLDAPの場合に必要です。

spec.security.authentication.agents.automationPasswordSecretRef.name

型: string

spec.security のパスワードを含むシークレットの名前。認証. Agents.AutomationUserNameユーザー。このシークレットは、 Kubernetes Operator を配置するのと同じ名前空間に作成する必要があります。

kubectl create secret generic ldap-agent-user \
--from-literal="password=<password>" -n <metadata.namespace>

このシークレットには 1 つのキーが含まれている必要があり、その値はspec.security.authentication.agents.automationUserNameのパスワードと一致します。 LDAP 配置のユーザー。

この設定は、 spec.security.authentication.agents.modeがLDAPの場合に必要です。

spec.security.authentication.agents.automationPasswordSecretRef.optional

タイプ: ブール値

これらのオプションが必須か任意かを指定します。

spec.security.authentication.agents.automationPasswordSecretRef.key
spec.security.authentication.agents.automationPasswordSecretRef.name

spec.security.authentication.agents.automationUserName

型: string

MongoDB エージェントがマルチ Kubernetes クラスター MongoDB 配置を操作するために使用するユーザーの名前。ユーザー名は、 spec.security.authentication.ldap.userToDNMappingに従って、LDAP Distinguished Name（DN）にマップされます。結果の DN は LDAP 配置にすでに存在している必要があります。

この設定は、 spec.security.authentication.agents.modeがLDAPの場合に必要です。

spec.security.authentication.agents.clientCertificateSecretRef.name

型: string

デフォルト: Agent-certs

MongoDB Agent の TLS 証明書を含むシークレットを指定します。

このシークレットには mms-automation-agent-pem キーが含まれている必要があります。このキーの値は、サーバーによって検証できる TLS 証明書である必要があります。

このシークレットは、Kubernetes Operator を配置するのと同じ名前空間に作成する必要があります。

kubectl create secret generic agent-certs \
--from-file=mms-automation-agent-pem=<automation-cert.pem> \
--namespace=<metadata.namespace>

spec.security.authentication.enabled

タイプ: ブール値

デフォルト: false

Cloud ManagerまたはMongoDB Ops Managerプロジェクトで認証が有効になっているかどうかを指定します。 trueに設定されている場合は、 spec.security.authentication.mode で認証メカニズムを設定する必要があります。

重要

この設定を含めると、 falseに設定されている場合でも、Kubernetes Operator はこの MongoDB リソースの認証を管理します。この設定がリソース仕様に存在している間は、 Cloud ManagerまたはMongoDB Ops Managerユーザーインターフェースまたは API を使用してこのリソースの認証を構成することはできません。

Cloud ManagerまたはMongoDB Ops Managerユーザーインターフェースまたは API を使用して認証を管理する場合は、この設定を省略します。

spec.security.authentication.agents.mode

型: string

マルチ Kubernetes クラスター MongoDB 配置の MongoDB エージェントが使用する認証メカニズム。有効な値は、 SCRAM 、 SCRAM-SHA-1 、 MONGODB-CR 、 X509 、 LDAPです。指定する値は、 spec.security.authentication.modesにも存在する必要があります。 SCRAM-SHA-1よりもSCRAM-SHA-256 (SCRAM)を推奨しています。 SCRAM-SHA-1を指定する場合は、 MONGODB-CRも指定する必要があります。

この設定は、 spec.security.authentication.mode に複数の値を指定した場合に必要です。

spec.security.authentication.ignoreUnknownUsers

タイプ: ブール値

デフォルト: false

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

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

spec.security.authentication.internalCluster

型: string

X. 509内部クラスター認証を有効にするかどうかを指定します。

X.509 内部クラスター認証を有効にするには、を"X509"に設定します。次の設定を指定する必要があります。

spec.security.authentication.mode : ["X509"]
spec.security.certsSecretPrefix

Kubernetes 演算子は次の値を受け入れます。

["X509"]: X.509 内部クラスター認証が有効になっています。
"" または省略: 内部クラスター認証が有効になっていません。

重要

内部クラスター認証を有効にした後で、無効にすることはできません。

spec.security.authentication.ldap

タイプ: コレクション

LDAP 認証に必要です。

LDAPCloud ManagerまたはMongoDB Ops Manager プロジェクトの認証を構成します。LDAP認証を有効にするには、 spec.security.authentication.modeを["LDAP"]に設定します。

spec.security.authentication.ldap.authzQueryTemplate

型: string

LDAP 認可に必要です。

ユーザーが属する LDAP グループを取得するためにMongoDBによって実行される RFC4515 および RFC LDAP 形式のクエリURLテンプレート。4516クエリは、spec.security.authentication.ldap.serversで指定されたホストに対して相対的です。テンプレートでは、次のトークンを使用できます。

{USER}
認証されたユーザー名、またはtransformedユーザー名を LDAP クエリに置き換えます。
{PROVIDED_USER}
認証または LDAP 変換の前に、指定されたユーザー名を LDAP クエリに置き換えます。（ MongoDB バージョン 4.2 以降で利用可能）。

詳細については、MongoDB マニュアルの「 LDAP クエリテンプレート」を参照してください。

spec.security.authentication.ldap.bindQueryPasswordSecretRef

タイプ: コレクション

LDAP 認証に必要です。

LDAPサーバーに接続するときにMongoDB がバインドするパスワードを含むシークレットを指定します。

spec.security.authentication.ldap.bindQueryPasswordSecretRef.name

型: string

LDAP 認証に必要です。

LDAPサーバーに接続するときにMongoDB がバインドするパスワードを含むシークレットの名前。

シークレットには、パスワードを保存する passwordフィールドのみを含める必要があります。

spec.security.authentication.ldap.bindQueryUser

型: string

LDAP 認証に必要です。

MongoDB が LDAP サーバーに接続するときにバインドする LDAP 識別名。

spec.security.authentication.ldap.caConfigMapRef

タイプ: コレクション

TLS による LDAP 認証に必要です。

LDAP サーバーの TLS 証明書を検証する CA を含む ConfigMap 。

spec.security.authentication.ldap.caConfigMapRef.key

型: string

TLS による LDAP 認証に必要です。

LDAP サーバーの TLS 証明書を検証する CA を保存するフィールド名。

spec.security.authentication.ldap.caConfigMapRef.name

型: string

TLS による LDAP 認証に必要です。

LDAP サーバーの TLS 証明書を検証する CA を含む ConfigMap の名前。

spec.security.authentication.ldap.caConfigMapRef.optional

タイプ: ブール値

これらのオプションが必須か任意かを指定します。

spec.security.authentication.ldap.caConfigMapRef.key
spec.security.authentication.ldap.caConfigMapRef.name

spec.security.authentication.ldap.servers

タイプ: 文字列の配列

LDAP 認証に必要です。

LDAPサーバーのホスト名とポートのリスト。次の形式で、それぞれのポートを持つホスト名を指定します。

spec:
   security:
      authentication:
      ldap:
         servers:
            - "<hostname1>:<port1>"
            - "<hostname2>:<port2>"

spec.security.authentication.ldap.timeoutMS

タイプ: 整数

認証リクエストがタイムアウトするまでの待機時間をミリ秒単位で指定します。

spec.security.authentication.ldap.transportSecurity

型: string

LDAP 認証に必要です。

LDAPサーバーがTLSを受け入れるかどうかを指定します。

LDAPサーバーがTLSを受け入れている場合は、値をtlsに設定します。 LDAPサーバーがTLSを受け入れていない場合は、この値を空白のままにするか、値をnoneに設定します。

注意

noneまたはtls以外の string を指定した場合でも、Kubernetes Operator は設定をtlsに設定します。

spec.security.authentication.ldap.userCacheInvalidationInterval

タイプ: 整数

MongoDB がLDAPユーザーキャッシュをフラッシュするまでの待機時間を秒単位で指定します。デフォルトは 30 秒です。

spec.security.authentication.ldap.userToDNMapping

型: string

認証用にmongodまたはmongosに指定されたユーザー名を LDAP 識別名（DN）にマッピングします。

詳細については、MongoDB マニュアルのsecurity.ldap.userToDNMappingを参照してください。

spec.security.authentication.modes

タイプ: 配列

MongoDB 配置で使用する認証メカニズムを指定します。有効な値は、 SCRAM 、 SCRAM-SHA-1 、 MONGODB-CR 、 X509 、 LDAPです。 We recommend SCRAM-SHA-256 (SCRAM) over SCRAM-SHA-1. SCRAM-SHA-1を指定する場合は、 MONGODB-CRも指定する必要があります。

注意

509またはCloud Manager MongoDB Ops Managerプロジェクトで X. 内部クラスター認証を有効にするには、この値を["X509"] に設定し、次の設定を指定します。

spec.security.authentication. internalCluster : "X509"
spec.security.certsSecretPrefixの値を指定する設定。

spec.security.authentication.modesに複数の値を指定する場合は、 spec.security.authentication.agents.mode の値も指定する必要があります。

spec.security.authentication.requireClientTLSAuthentication

タイプ: ブール値

デフォルト: false

MongoDB ホストがクライアントにTLS証明書を使用して接続することを要求するかどうかを指定します。 TLS認証を有効にする場合、デフォルトはtrueになります。

TLS認証を有効にするには、 spec.security.certsSecretPrefixの値を指定します設定。

spec.security.certsSecretPrefix

型: string

レプリカセットの TLS キーと証明書を含む作成したKubernetesシークレットにプレフィックスを入力します。

シークレットの前に<prefix>-<metadata.name>を付ける必要があります。

たとえば、配置をmy-deployment mdbと呼び出し、プレフィックスをに設定する場合は、クライアント TLS 通信の TLS シークレットにmdb-my-deployment-cert という名前を付ける必要があります。また、内部クラスター認証用のTLSシークレット（有効になっている場合） mdb-my-deployment-clusterfileに名前を付ける必要があります。

TLS証明書を含むシークレットの名前付けの詳細については、配置に適用されるマルチ Kubernetes-クラスタークイックスタートのトピックを参照してください。

spec.security.roles

タイプ: 配列

マルチ Kubernetes クラスター MongoDB 配置に対するきめ細かなアクセス制御を提供するユーザー定義のロールを定義する配列。

ユーザー定義ロールを有効にするには、 spec.security.authentication.enabledはtrueである必要があります。

例

上記の例では、 customRoleという名前のユーザー定義ロールにより、このロールを割り当てられたユーザーには次の操作を許可します。

petsデータベースのcatsコレクションにドキュメントを挿入し、
petsデータベース内のdogsコレクションにドキュメントを検索して挿入します。

1   security:
2     authentication:
3       enabled: true
4       modes:
5         - "SCRAM"
6     roles:
7       - role: "customRole"
8         db: admin    
9         privileges:
10         - actions:
11           - insert
12           resource:
13             collection: cats
14             db: pets
15         - actions:
16           - insert
17           - find
18           resource:
19             collection: dogs
20             db: pets
21 ...

spec.security.roles.authenticationRestrictions

タイプ: 配列

このspec.security.roles.roleを割り当てられたユーザーが接続できる IP アドレスと IP アドレスを定義する配列。

spec.security.roles.authenticationRestrictions.clientSource

タイプ: 配列

このspec.security.roles.roleを割り当てられたユーザーが接続できる IP アドレスまたは CIDR ブロックの配列。

MongoDB サーバーは、リクエストがこの配列に存在しないクライアントからの接続リクエストである場合、このロールを持つユーザーからの接続リクエストを拒否します。

spec.security.roles.authenticationRestrictions.serverAddress

タイプ: 配列

このspec.security.roles.roleを割り当てられたユーザーが接続できる IP アドレスまたは CIDR ブロックの配列。

MongoDB サーバーは、クライアントがこの配列に存在しないサーバーへの接続をリクエストした場合、このロールを持つユーザーからの接続リクエストを拒否します。

spec.security.roles.db

型: string

ユーザー定義ロールを保存するデータベース。

例

admin

spec.security.roles.privileges

タイプ: 配列

このロールに付与されたユーザーが持つ特権を記述する配列。

spec.security.roles.privileges.actions

タイプ: 配列

このロールを付与されたユーザーが実行できるアクションのリスト。許容値のリストについては、Kubernetes Operator で配置する MongoDB バージョンの MongoDB マニュアルの「特権アクション」を参照してください。

spec.security.roles.privileges.resource

タイプ: コレクション

特権が適用されるリソースは、 .security.roles.privateges.actionsです。

このコレクションには、次のいずれかを含める必要があります。

spec.security.roles.rivileges.resource.dbおよびspec.security.roles.rivileges.resource.collection設定、または
trueの値を持つspec.security.roles.privateregions.resource.cluster設定。

spec.security.roles.privileges.resource.cluster

タイプ: ブール値

デフォルト: false

特権がMongoDB配置内のすべてのデータベースとコレクションに適用されることを示すフラグ。

true に設定されている場合、 spec.security.roles.rivileges.resource.dbおよびspec.security.roles.rivileges.resource.collection の値を指定しません。

spec.security.roles.privileges.resource.collection

型: string

特権 spec.security.roles.privateles.actions が適用される spec.security.roles.privateges.resource.db 内のコレクション。

この設定に値を指定する場合は、 spec.security.roles.privateges.resource.db の値も指定する必要があります。

spec.security.roles.privileges.resource.db

型: string

特権spec.security.roles.privates.actionsが適用されるデータベース。

この設定に値を指定する場合は、 spec.security.roles.privateges.resource.collection にも値を指定する必要があります。

spec.security.roles.role

型: string

ユーザー定義ロールの名前。

spec.security.tls.additionalCertificateDomains

タイプ: コレクション

この配置内の各ポッドへのTLS証明書に追加する必要があるすべてのドメインのリスト。このパラメーターを設定すると、Kubernetes Operator が TLS 証明書に変換するすべての CSR に、形式の SAN が含まれ<pod name>.<additional cert domain> 。

レプリカセットリソースには、このパラメーターは必要ありません。 spec.connector.replicaSetHorizons の使用ください。

注意

このパラメータをTLS対応のリソースに追加すると、リソースがPending状態に達したときに Kubernetes にエラーが表示されます。このエラーは表示されます。 Please manually remove the |csr| in order to proceed.この問題を解決するには、以下の手順を行います。

Kubernetes が新しい CSR を生成できるように、既存の CSR を削除します。リソースを削除する方法については、Kubernetesドキュメントのリソースの削除を参照してください。
Kubernetes が CSR を生成した後に、 CSRを承認します。

spec.security.tls.ca

型: string

CA を保存する ConfigMap の名前を指定します。

重要

カスタムCAを使用してMongoDBMultiClusterリソースのTLS証明書に署名する場合は、このパラメータを指定する必要があります。

Kubernetes Operator では、ConfigMap でMongoDBMultiClusterリソースca-pemの証明書に名前を付ける必要があります。

spec.security.tls.enabled

タイプ: ブール値

重要

spec.security.tls.enabled は Kubernetes Operator バージョン1.19以降では非推奨となり、今後の Kubernetes Operator リリースでは削除される予定です。 TLSを有効にするには、 spec.security.certsSecretPrefixの値を指定します設定。

TLS 証明書を使用して以下の間の通信を暗号化します。

レプリカセットまたはシャーディングされたクラスター構成内の MongoDB ホスト
クライアント（ mongo shell、ドライバー、 MongoDB Compassなど）と MongoDB の配置

spec.statefulSet.spec

タイプ: コレクション

MongoDB Enterprise Kubernetes Operator がマルチ Kubernetes クラスターMongoDBデプロイ用に作成する Atlas Triggers のグローバル仕様。

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

戻る

Databases

Enterprise インストール設定

1	# This example provides statefulSet overrides per cluster.
2
3	apiVersion: mongodb.com/v1
4	kind: MongoDBMultiCluster
5	metadata:
6	name: multi-replica-set
7	spec:
8	version: 4.4.0-ent
9	type: ReplicaSet
10	duplicateServiceObjects: false
11	credentials: my-credentials
12	opsManager:
13	configMapRef:
14	name: my-project
15	clusterSpecList:
16	- clusterName: cluster1.example.com
17	members: 2
18	statefulSet:
19	spec:
20	template:
21	spec:
22	containers:
23	# Example of custom sidecar containers. Remove it before using the file in production.
24	- name: sidecar1
25	image: busybox
26	command: [ "sleep" ]
27	args: [ "infinity" ]
28	# Use the following settings to override the default storage size of the "data" Persistent Volume.
29	volumeClaimTemplates:
30	- metadata:
31	name: data
32	spec:
33	resources:
34	requests:
35	storage: 1Gi
36	- clusterName: cluster2.example.com
37	members: 1
38	statefulSet:
39	spec:
40	template:
41	spec:
42	containers:
43	# Example of custom sidecar containers. Remove it before using the file in production.
44	- name: sidecar2
45	image: busybox
46	command: [ "sleep" ]
47	args: [ "infinity" ]
48	volumeClaimTemplates:
49	- metadata:
50	name: data
51	spec:
52	resources:
53	requests:
54	storage: 1Gi
55	- clusterName: cluster3.example.com
56	members: 1
57	statefulSet:
58	spec:
59	template:
60	spec:
61	containers:
62	# Example of custom sidecar containers. Remove it before using the file in production.
63	- name: sidecar3
64	image: busybox
65	command: [ "sleep" ]
66	args: [ "infinity" ]
67	volumeClaimTemplates:
68	- metadata:
69	name: data
70	spec:
71	resources:
72	requests:
73	storage: 1Gi
74
75	...

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	...

1	security:
2	authentication:
3	enabled: true
4	modes:
5	- "SCRAM"
6	roles:
7	- role: "customRole"
8	db: admin
9	privileges:
10	- actions:
11	- insert
12	resource:
13	collection: cats
14	db: pets
15	- actions:
16	- insert
17	- find
18	resource:
19	collection: dogs
20	db: pets
21	...

例

必要なMongoDBMultiCluster リソース設定

重要

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

重要

注意

任意のMongoDBMultiCluster リソース設定

注意

重要

注意

例

例

注意

注意

注意

例

重要

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

重要

重要

注意

注意

例

例

注意

重要

重要

必要な`MongoDBMultiCluster` リソース設定

任意の`MongoDBMultiCluster` リソース設定