AI エージェント向け: ドキュメントインデックスは https://www.mongodb.com/ja-jp/docs/llms.txt で利用できます。すべてのページの markdown バージョンは、いずれかの URL パスに .md を追加することで利用できます。
Docs Menu
Docs Home
/ /
参照
Docs Home
/
管理
/
Kubernetes 演算子のコントローラー
/
参照
Docs Home
/
管理
/
Kubernetes 演算子のコントローラー
/
参照

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

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

例

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

1# This example provides statefulSet overrides per cluster.
2
3apiVersion: mongodb.com/v1
4kind: MongoDBMultiCluster
5metadata:
6  name: multi-replica-set
7spec:
8  version: 8.0.0
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

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

認証情報を保持する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 リソースが使用する基本イメージによって異なります。

任意のMongoDBMultiCluster リソース設定

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

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 設定のリストについては、以下を参照してください。

spec.backup

タイプ: コレクション

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

spec.backup.assignmentLabels

タイプ: 配列

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

spec.backup.autoTerminateOnDeletion

タイプ: ブール値

リソースを削除すると、 Kubernetes OperatorMongoDBMultiCluster がバックアップを停止して終了するかどうかを示すフラグ。デフォルト値は です。このフラグを に設定すると、falsetrue の指定中にMongoDBMultiCluster リソースを削除する場合に便利です。バックアップ。モード設定は enabledに設定されています。

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です。

注意

の仕様。バックアップ。モード設定は、Ops Manager で有効になっているバックアップに依存し、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

タイプ: 数値

時刻の UTC 時間で、24 時間制でスナップショットをスケジュールする。 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 Controls for 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 Operatorprocesses[n].hostname は外部ドメインを含むホスト名を使用して、Ops Managerオートメーション構成の フィールドを上書きします。次に、 MongoDB Agent はこのホスト名を使用してmongod に接続します。

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

  • に接続するMongoDB Agent。mongod

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

警告: このフィールドを指定すると、Ops Manager がmongod プロセスを登録する方法が変更されます。このフィールドまたは実行中のレプリカセット配置のprocesses[n].hostname Ops Managerオートメーション構成内の任意の フィールドの値は変更できません。

重要

この設定は、マルチ 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: 8.0.0
  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 Controls for 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 外部からの両方で通信が可能になります。

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

注意

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

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

フィールド
値
説明

Name

<pod-name>-svc-external

外部サービスの名前。 この値は変更できません。

Type

LoadBalancer

外部 LoadBalancer を作成します service

Port

<Port Number>

mongodのポート。

publishNotReadyAddress

true

ポッドが準備ができていない場合でも DNS レコードが作成されることを指定します。どのデータベースポッドでもfalse に設定しないでください。

注意

spec.clusterSpecList.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 クラスターMongoDBデプロイ内のすべてのクラスターに追加できるキーと値のペア。クラスター固有のオーバーライドについては、spec.clusterSpecList.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.externalAccess.externalService.spec

タイプ: コレクション

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

spec.featureCompatibilityVersion

タイプ: 数値

新しいメジャー バージョンへのアップグレードに関連して発生するデータの変更を制限します。これにより、以前のメジャー バージョンにダウングレードできます。機能の互換性の詳細については、 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演算子は、fsGroup = 2000 runAsUser = 2000で 、 、 を設定します。 Kubernetes Operator は、 をrunAsNonRoot = true securityContextfsgrouprunAsUserと等しく設定して、コンテナでメイン プロセスを実行するユーザーがボリュームを書込み可能にします。詳細については、 Kubernetesドキュメントの「 ポッドまたはコンテナのセキュリティ コンテキストの構成 」および関連するディスカッションを参照してください。リソースを再デプロイしても永続ボリュームの問題が修正されない場合は、 MongoDBサポート にお問い合わせください。

Disk Usage永続ボリュームを使用しない場合、この配置のデータを確認するときに、Disk 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.agents.automationPasswordSecretRef

タイプ: コレクション

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

この設定は system.security の場合は必須です。認証. エージェントモードはLDAP です。

spec.security.authentication.agents.automationPasswordSecretRef.key

型: string

spec.security.authentication.agents.automationPasswordSecretRef.name シークレット 仕様.security.authentication.agents.automationUserName にユーザーのパスワードが含まれるドキュメント

この設定は system.security の場合は必須です。認証. エージェントモードはLDAP です。

spec.security.authentication.agents.automationPasswordSecretRef.name

型: string

シークレット の名前 仕様.security.authentication.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 配置のユーザー。

この設定は system.security の場合は必須です。認証. エージェントモードはLDAP です。

spec.security.authentication.agents.automationPasswordSecretRef.optional

タイプ: ブール値

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

spec.security.authentication.agents.automationUserName

型: string

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

この設定は system.security の場合は必須です。認証. エージェントモードは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

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

この設定は、spec.security に複数の値を指定した場合に必要です。認証. モード

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"に設定します。 次の設定を指定する必要があります。

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

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

  • "" または省略: 内部クラスター認証が有効になっていません。

重要

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

spec.security.authentication.ldap

タイプ: コレクション

LDAP 認証に必要です。

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

spec.security.authentication.ldap.authzQueryTemplate

型: string

LDAP 認可に必要です。

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

  • {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 認証に必要です。

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

spec.security.authentication.ldap.caConfigMapRef

タイプ: コレクション

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

ConfigMap は、 LDAP サーバーの TLS 証明書を検証する CA を含みます。

spec.security.authentication.ldap.caConfigMapRef.key

型: string

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

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

spec.security.authentication.ldap.caConfigMapRef.name

型: string

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

ConfigMap の名前 は、 LDAP サーバーの TLS 証明書を検証する CA を含みます。

spec.security.authentication.ldap.caConfigMapRef.optional

タイプ: ブール値

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

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

タイプ: 整数

Specifies how many seconds MongoDB waits to flush the LDAP user cache. Defaults to 30 seconds.

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も指定する必要があります。

注意

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

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

spec.security.authentication.requireClientTLSAuthentication

タイプ: ブール値

デフォルト: false

Specifies whether the MongoDB host requires clients to connect using a TLS certificate. Defaults to true if you enable TLS authentication.

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

spec.security.certsSecretPrefix

型: string

Kubernetes シークレット のプレフィックスへのテキスト 作成した、レプリカセットの TLS キーと証明書を含む。

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

For example, if you call your deployment my-deployment and you set the prefix to mdb, you must name the TLS secret for the client TLS communications mdb-my-deployment-cert. Also, you must name the TLS secret for internal cluster authentication (if enabled) mdb-my-deployment-clusterfile.

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

spec.security.roles

タイプ: 配列

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

ユーザー定義のロールを有効にするには、.security.認証.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.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.privates の値も指定する必要があります。リソース.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

タイプ: コレクション

List of every domain that should be added to TLS certificates to each Pod in this deployment. When you set this parameter, every CSR that the Kubernetes Operator transforms into a TLS certificate includes a SAN in the form <pod name>.<additional cert domain>.

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

注意

If you add this parameter to a TLS-enabled resource, Kubernetes displays an error when the resource reaches the Pending state. This error displays: Please manually remove the |csr| in order to proceed. To remedy this issue:

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

  2. Kubernetes が CSR を生成した後に、 CSRを承認します。

spec.security.tls.ca

型: string

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

重要

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

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

spec.security.tls.enabled

タイプ: ブール値

重要

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

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

spec.statefulSet.spec

タイプ: コレクション

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

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

戻る
Databases
次へ
Enterprise インストール設定
このページを評価

項目一覧