マルチKubernetes-クラスター リソース仕様
MongoDBMultiCluster{0Kubernetes MongoDBMongoDBEnterprise Kubernetes OperatorMongoDB Ops ManagerKubernetesリソースは、複数の クラスター 配置を定義し、 を提供します クラスター、 の配置、 ステートメント を作成または更新するために必要な情報 、 サービス、およびその他の リソース。
例
次の例は、マルチ 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: 6.0.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.portnet.tls.certificateKeyFilenet.tls.clusterFilereplication.replSetNamesecurity.clusterAuthModesharding.clusterRolestorage.dbPathsystemLog.destinationsystemLog.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タイプ: 配列
バックアップデーモン サービスプロセスの割り当てラベルのリスト。 割り当てラベル を使用して、特定のバックアップデーモン プロセスが特定のプロジェクトに関連付けられていることを識別します。 Kubernetes Operator を使用して割り当てラベルを設定すると、割り当てラベルのKubernetes構成ファイルで設定した値が、 MongoDB Ops Manager UI で定義された値を上書きします。 Kubernetes Operator を使用して設定しない割り当てラベルは、 MongoDB 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.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設定を使用できます。 ただし、次の接続では、外部ドメインを含むホスト名は引き続き使用されます。警告:このフィールドを指定すると、 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 仕様の詳細については、 ServiceSpec を参照してください （Kubernetes ドキュメント）。
spec.clusterSpecList.externalAccess.externalService.annotationsタイプ: コレクション
キーと値のペア: マルチ Kubernetes クラスター MongoDB 配置内の特定のクラスターにクラウドプロバイダー固有の構成設定を追加できます。 この設定はグローバル設定 （ spec.externalAccess.externalService.annotations ）を上書きします。 詳細については、 注釈 を参照してください Kubernetes クラウドプロバイダーのドキュメントとドキュメントを参照してください。
注釈 を使用できます で、Kubernetes Operator の配置で使用される外部サービスのプレースホルダー値を指定します。Kubernetes Operator は、これらの値を次の表に記載されている正しい値に自動的に置き換えます。 プレースホルダーを使用すると、特定のポッドの各サービスに特定の注釈を提供できます。
値説明{resourceName}{namespace}{podIndex}ステートフルセット によって割り当てられたポッドのインデックス 現在の外部サービスが対象とする と{podName}{resourceName}-{clusterIndex}-{podIndex}に等しい。{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: 6.0.0-ent type: ReplicaSet duplicateServiceObjects: false credentials: my-credentials opsManager: configMapRef: name: my-project clusterSpecList: - clusterName: cluster1.example.com members: 2 memberConfig: - votes: 1 priority: "0.5" tags: tag1: "value1" environment: "prod" - votes: 1 priority: "1.5" tags: tag2: "value2" environment: "prod" - clusterName: cluster2.example.com members: 1 memberConfig: - votes: 1 priority: "0.5" tags: tag1: "value1" environment: "prod" - clusterName: cluster3.example.com members: 1 memberConfig: - votes: 1 priority: "0.5" tags: tag1: "value1" environment: "prod"
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タイプ: コレクション
ステートフルセット の構成を提供します MongoDB のマルチ Kubernetes クラスター配置で、クラスターの各StatusSets に対して の上書きを適用します。MongoDB のマルチ Kubernetes クラスター配置のすべてのクラスターに適用されるグローバル構成を設定するには、 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に設定します。 DNS プロキシの例については、「 DNS プロキシ 」を参照してください。 （ Istio ドキュメント ）。
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外部サービスの名前。 この値は変更できません。TypeLoadBalancer外部 LoadBalancer を作成します servicePort<Port Number>mongodのポート。publishNotReadyAddresstrueDNS レコード を指定する は、Ped が準備ができていない場合でも作成されます。どのデータベース ポッドでも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 仕様の詳細については、 ServiceSpec を参照してください （Kubernetes ドキュメント）。
spec.externalAccess.externalService.annotationsタイプ: コレクション
MongoDB のマルチ Kubernetes クラスター配置内のすべてのクラスターにクラウドプロバイダー固有の構成設定を追加できるキーと値のペア。 クラスター固有のオーバーライドについては、 spec.clusterSpecList.externalAccess.externalService.annotationsを参照してください。 詳細については、 注釈 を参照してください Kubernetes 配置に使用するクラウドプロバイダーのドキュメントと のドキュメントを参照してください。
注釈 を使用できます で、Kubernetes Operator の配置で使用される外部サービスのプレースホルダー値を指定します。Kubernetes Operator は、これらの値を次の表に記載されている正しい値に自動的に置き換えます。 プレースホルダーを使用すると、特定のポッドの各サービスに特定の注釈を提供できます。
値説明{resourceName}{namespace}{podIndex}ステートフルセット によって割り当てられたポッドのインデックス 現在の外部サービスが対象とする と{podName}{resourceName}-{clusterIndex}-{podIndex}に等しい。{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タイプ: 数値
新しいメジャー バージョンへのアップグレードに関連して発生するデータの変更を制限します。 This allows you to downgrade to the previous major version. 機能の互換性の詳細については、MongoDB マニュアルの
setFeatureCompatibilityVersionを参照してください。
spec.logLevel型: string
ポッド 内のオートメーションエージェントのログ記録のレベルを構成します 。受け入れ可能な値は以下の通りです。
DEBUGINFOWARNERRORFATAL
spec.opsManager.configMapRef.name型: string
ConfigMap の名前Cloud Manager またはMongoDB Ops Manager 接続構成の場合。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 IOPSProcesses、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タイプ: コレクション
シークレット の詳細 仕様.security.authentication.agents.automationUserName のパスワードを含むユーザー。
この設定は、 spec.security.authentication.agents.modeが
LDAPの場合に必要です。
spec.security.authentication.agents.automationPasswordSecretRef.key型: string
spec.security.authentication.agents.automationPasswordSecretRef.name シークレット 仕様.security.authentication.agents.automationUserName にユーザーのパスワードが含まれるドキュメント
この設定は、 spec.security.authentication.agents.modeが
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 配置のユーザー。
この設定は、 spec.security.authentication.agents.modeが
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 配置にすでに存在している必要があります。
この設定は、 spec.security.authentication.agents.modeが
LDAPの場合に必要です。
spec.security.authentication.agents.clientCertificateSecretRef.name型: string
デフォルト: Agent-certs
シークレット を指定します MongoDB Agent の TLS 証明書が含まれる。
このシークレットには、次のキーが含まれている必要があります。これらのキーの値は、サーバーによって検証できるTLS証明書です。
mms-automation-agent-pemmms-backup-agent-pemmms-monitoring-agent-pem
このシークレットは、Kubernetes Operator を配置するのと同じ名前空間に作成する必要があります。
kubectl create secret generic agent-certs \ --from-file=mms-automation-agent-pem=<automation-cert.pem> \ --from-file=mms-backup-agent-pem=<backup-cert.pem> \ --from-file=mms-monitoring-agent-pem=<monitoring-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.ignoreUnknownUsersタイプ: ブール値
デフォルト: false
Kubernetes Operator、またはCloud ManagerまたはMongoDB Ops Managerユーザー インターフェイスを通じて構成されていないデータベースユーザーを変更できるかどうかを決定します。
spec.security.authentication.internalCluster型: string
X. 509内部クラスター認証を有効にするかどうかを指定します。
X.509 内部クラスター認証を有効にするには、 を
"X509"に設定します。 次の設定を指定する必要があります。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 認可に必要です。
RFC4515 と RFC4516 ユーザーが属する LDAP グループを取得するために MongoDB によって実行される LDAP 形式のクエリ URL テンプレート。クエリは、
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 認証に必要です。
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タイプ: 整数
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 recommendSCRAM-SHA-256 (SCRAM)overSCRAM-SHA-1.SCRAM-SHA-1を指定する場合は、MONGODB-CRも指定する必要があります。注意
509またはCloud Manager MongoDB Ops Managerプロジェクトで X. 内部クラスター認証 を有効にするには、この値を
["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
Kubernetes シークレット のプレフィックスへのテキスト 作成した、レプリカセットの TLS キーと証明書を含む。
シークレットの前に
<prefix>-<metadata.name>を付ける必要があります。たとえば、配置を
my-deploymentmdbと呼び出し、プレフィックスを に設定する場合は、クライアント 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.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
ConfigMap の名前を指定する は CA を保存します。
重要
カスタム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 ホスト
クライアント（
mongoshell、ドライバー、 MongoDB Compassなど）と MongoDB の配置
spec.statefulSet.specタイプ: コレクション
ステートメント のグローバル仕様 MongoDB Enterprise Kubernetes Operator が複数の Kubernetes クラスター MongoDB 配置用に作成する
spec.statefulSet.specに追加できるフィールドを確認するには、「 StatulSetSpec v1 アプリ 」を参照してください （Kubernetes ドキュメント）。