MongoDB Search とベクトル検索の設定

外部レプリカセットへの接続設定

spec.source.external.hostAndPorts

タイプ: 文字列の配列

外部レプリカセットのホスト名とポートのリスト。これは、 MongoDBレプリカセットへのホストシードリストです。mongot はレプリカセットモードでデータベースに接続し、db.hello() を使用して他のすべてのノードのリストを取得します。

このフィールドは spec.source.external.shardedCluster と排他関係にあります。レプリカセットソースには hostAndPorts を使用し、シャーディングされたクラスターソースには shardedCluster を使用します。

例

hostAndPorts:
  - mdbc-rs-0.my-external-domain.example.com:27017
  - mdbc-rs-1.my-external-domain.example.com:27017
  - mdbc-rs-2.my-external-domain.example.com:27017

spec.source.external.tls

型: オブジェクト

TLS 設定は、外部MongoDBデータベースに接続するときに mongot が使用する必要があります。

spec.source.external.tls.ca.name

型: string

mongod ノードで使用される TLS 証明書を発行した証明機関の信頼できるチェーンを含む ConfigMap の名前。

例

spec:
  source:
    external:
      tls:
        ca:
          name: trusted-ca

この ConfigMap 内の ca.crt キーの下に証明書（または証明書チェーン）を指定する必要があります。

例

kind: ConfigMap
apiVersion: v1
metadata:
  name: trusted-ca
data:
  ca.crt: |
    -----BEGIN CERTIFICATE-----
    MIIDBTCCAe2gAwIBAgIIH3EOUAGAsx0wDQYJKoZIhvcNAQELBQAwFTETMBEGA1UE
    [...]
    U/4rN8Ias/FONYFRtGfs9uXHmo2MP04BF+9ED2dlbNDUbat+6XCozLJj98nI4VEi
    qaV3JrVFHTgN
    -----END CERTIFICATE-----

外部クラスターに接続するための設定

次の設定は、外部MongoDBシャーディングされたクラスターへの接続を構成する場合にのみ必要です。既存の spec.source.external 設定を拡張します。

spec.source.external.shardedCluster

型: オブジェクト

外部のシャーディングされたMongoDBクラスターを mongot のデータソースとして宣言します。mongos ルーターとシャードごとのレプリカセットの構成が含まれます。

MongoDB クラスターがKubernetesの外部に配置され、 Kubernetes 演算子 によってマネージドではない場合にのみ、これを使用してください。MongoDB CRD を使用して配置されたオペレーターマネージドのシャーディングされたクラスターの場合は、代わりに spec.source.mongodbResourceRef を使用します。Kubernetes 演算子は シャードトポロジーを自動検出します。

例

spec:
  source:
    external:
      shardedCluster:
        router:
          hosts:
            - "mongos1.external:27017"
            - "mongos2.external:27017"
        shards:
          - shardName: "shard-0"
            hosts:
              - "shard0-node1.external:27018"
              - "shard0-node2.external:27018"
          - shardName: "shard-1"
            hosts:
              - "shard1-node1.external:27018"
              - "shard1-node2.external:27018"

spec.source.external.shardedCluster.router

型: オブジェクト

外部シャーディングされたクラスターの mongos（ルーター）インスタンスの構成。

spec.source.external.shardedCluster.router.hosts

タイプ: 文字列の配列

host:port形式の mongos ルーター インスタンスのエンドポイントとなる接続されたデバイスのリスト。すべての mongot インスタンスがこれらのルーターに接続します。少なくとも 1 つのエントリを指定します。

例

router:
  hosts:
    - "mongos1.external:27017"
    - "mongos2.external:27017"

spec.source.external.shardedCluster.shards

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

外部MongoDBクラスター内のすべてのシャードのリスト。各エントリは、1 つのシャードのレプリカセットについて説明します。Kubernetes 演算子は、シャードごとに 1 つの mongot StatefulSet を作成します。各StatefulSetには、spec.clusters[].replicas で指定されたポッドの数が含まれます。少なくとも 1 つのシャード エントリを指定します。

spec.source.external.shardedCluster.shards[*].shardName

型: string

シャードの論理名。Kubernetes 演算子 は、 Kubernetesリソースの名前付け（StateulSets、 Services、 Secrets）にこの名前を使用します。値はMongoDBシャード名とは異なる場合があります。

命名制約:

• すべてのシャードで一意である必要があります。

• Kubernetes DNS ラベル名のルール（RFC 1123）に準拠する必要があります。このルールでは、小文字の英数字とハイフン（-）が使用でき、名前は英数字で始まり、末尾も英数字で終わる必要があります。ピリオド（.）とアンダースコア（_）は許可されていません。最大長さは63文字です。

• Kubernetes Operator は、metadata.name、クラスター インデックス、および shardName を結合して作成する Kubernetes リソースの名前にし、生成されたすべての名前がラベルの Kubernetes DNS 制限 63 文字、サブドメイン名の 253 文字に収まることを検証します（例: {name}-search-{clusterIndex}-{shardName}）。これらの制限に収まるよう、shardName を十分に短くしてください。

例

shards:
  - shardName: "shard-0"
    hosts:
      - "shard0-node1.external:27018"

spec.source.external.shardedCluster.shards[*].hosts

タイプ: 文字列の配列

このシャードの mongodレプリカセットのエンドポイントのリスト（ host:port形式 ）。mongot インスタンスは、これらのホストからデータを複製します。少なくとも 1 つのエントリを指定します。

各レプリカセット（シャード）には独自の mongot インスタンスのグループがあり、そのレプリカセットからのみデータをソースとします。異なるシャードで同じ mongot インスタンスが共有されることはありません。

例

shards:
  - shardName: "shard-0"
    hosts:
      - "shard0-node1.external:27018"
      - "shard0-node2.external:27018"
      - "shard0-node3.external:27018"

サイズ設定とストレージ

spec.clusters[].replicas

タイプ: 整数

この Kubernetes クラスターに配置する mongot ポッドの数。レプリカセットの場合、これは mongot ポッドの合計数です。シャーディングされたクラスターの場合、これはシャードごとの mongot ポッドの数です。

spec.clusters[].replicas が 1 より大きい場合は、mongod と複数の mongot インスタンス間でトラフィックをルーティングするように spec.clusters[].loadBalancer も構成する必要があります。

spec.clusters[].replicas を 0 に設定すると、Kubernetes 演算子 はこのクラスターの mongot 配置をオフラインにします。Kubernetes 演算子は StatefulSet をゼロポッドに増やし、MongoDBSearch リソースとその他の Kubernetes リソースを所定の場所に保持します。

省略した場合、デフォルトは 1 になります。

例

spec:
  clusters:
    - replicas: 2

spec.clusters[].resourceRequirements

タイプ: Core/v1/ResourceRequirements

mongodb-searchコンテナがリクエスト、制限する CPU とメモリ。spec.clusters[].statefulSet で上書きするのではなく、このフィールドを使用してリソース割り当てをカスタマイズすることをおすすめします。

spec.clusters[].jvmFlags でJVMヒープ サイズをオーバーライドしない場合、Kubernetes Operator はデフォルトのヒープ サイズ（-Xmx）を mongot コンテナのメモリ リクエストの 50% に設定します。ポッド リソースとJVMヒープ サイズの両方を制御するには、それに応じて spec.clusters[].resourceRequirements を調整します。

省略した場合、 Kubernetes演算子は次のデフォルト値を使用します。

requests:
  cpu: 2
  memory: 4Gi

spec.clusters[].resourceRequirements.limits

型: オブジェクト

mongodb-searchコンテナが消費できるリソース（CPUとメモリ）の上限。デフォルトでは、制限は設定されていません。省略すると、ポッドは制限されないため、ノード上のすべてのリソースを使用する可能性があります。ワークロードに基づいて制限を設定することをお勧めします。

spec.clusters[].resourceRequirements.requests

型: オブジェクト

mongodb-search コンテナに要求される CPU とメモリの量。cpu または memory のいずれか 1 つだけを指定した場合、Kubernetes 演算子は他方にデフォルト値を適用します。省略した場合、Kubernetes 演算子は次のデフォルト値を使用します。

requests:
  cpu: 2
  memory: 4Gi

spec.clusters[].persistence.single

型: オブジェクト

MongoDB Search およびベクトル検索永続ボリュームのストレージ構成。MongoDB Search インデックスとベクトル検索インデックスが保存されます。各検索インスタンス（ポッド）には、インデックスを維持するための独自のストレージがあります。これはMongoDBデータベースとは共有されません。データベース自体には、インデックスメタデータ（定義）のみが保存されます。

スカラー	データ型	説明
labelSelector	string	マウントされたボリュームをディレクトリにバインドするために使用されるタグ。
storage	string	マウントする永続ボリュームの最小サイズ。この値は、整数とその後に続く JEDEC 表記のストレージ単位として表されます。 デフォルト値は16Gです。 例えば、レプリカセットに 60 ギガバイトのストレージ容量が必要な場合は、この値を 60G に設定します。
storageClass	string	永続ボリューム要求 で指定されたストレージのタイプ。このオブジェクト仕様で使用する前に、このストレージ タイプを StorageClass オブジェクトとして作成できます。 StorageClass reclaimPolicy を 保持 するように設定します。これにより、永続的なボリューム要求が削除されてもデータが保持されます。

MongoDBSearch は、single 持続モードのみをサポートします。これは、すべてのデータに 1 つのボリュームを使用します。CRD スキーマには spec.clusters[].persistence.multiple フィールドも含まれていますが、Kubernetes Operator はこれを適用しません。persistence を省略すると、Kubernetes Operator は spec.clusters[].persistence.single.storage を 16G に設定します。

ロード バランシング

spec.clusters[].loadBalancer

型: オブジェクト

mongod（または mongos）と mongot の間の L7 負荷分散の構成。このフィールドは、spec.clusters[].replicas が 1 より大きい場合に必要です。spec.clusters[].replicas が 1 の場合、このフィールドは任意です。後でスケールアップするために、単一の mongotインスタンスに対してもロードバランサーを構成できます。

正確に managed または unmanaged の 1 つを設定する必要があります。

spec.clusters 内のすべてのエントリは、ロード バランサー モードに同意する必要があります。すべてのエントリで loadBalancer.managed を設定するか、すべてのエントリで loadBalancer.unmanaged を設定するか、またはどのエントリも loadBalancer を設定しないかのいずれかです。Kubernetes Operator はミックス モードを拒否します。マルチクラスター配置はマネージド モードのみをサポートします。

ロードバランサーは、mongod クライアントが表示する TLS 証明書と、それらの証明書に含める必要があるホスト名に影響します。

• ロードバランサーがない場合、mongod は mongot に直接接続します。mongod に提示される TLS 証明書は mongot の証明書です。MongoDBクラスターがKubernetesの外部にある場合、mongot サービスは外部ドメインに公開されます。その外部ドメインは、mongot TLS 証明書の SAN（サブジェクト代替名）フィールドに含める必要があります。

• マネージド ロードバランサー（spec.clusters[].loadBalancer.managed）では、Envoy プロキシは mongot に直接接続する唯一のコンポーネントです。Envoy プロキシは内部サービス FQDN を使用して mongot にアクセスします。

  • レプリカセット: <name>-search-<clusterIndex>-svc.<ns>.svc.cluster.local

  • シャーディングされたクラスター: <name>-search-<clusterIndex>-<shard>-svc.<ns>.svc.cluster.local

  mongot TLS 証明書の SAN フィールドにこれらのサービス FQDN を含めることをお勧めします。演算子マネージド Envoy プロキシは現在、認証機関に対してのみ mongot 証明書を検証し、SAN ホスト名と一致しません。外部の mongod プロセスは Envoy プロキシの TLS 証明書を参照するため、外部ドメインを mongot 証明書ではなく Envoy 証明書の SAN に含めます。

Tip

最初に単一の mongot ポッドを配置する場合でも、マネージド ロードバランサーを有効にします。ロードバランサーが設定されている状態で、後で spec.clusters[].replicas を増やすアップしても、TLS 証明書内のドメインは安定したままになります。これは、ロードバランサーがmongod と mongot の間にすでに存在するためです。

spec.clusters[].loadBalancer.managed

型: オブジェクト

演算子がEnvoyロードバランサーをマネージド構成します。Kubernetes 演算子は、正しいルーティング、mTLS、 HTTP/2+gRPC ストリームの固定を使用して Envy プロキシ を配置しますおよび管理します。デフォルトを使用するには、このフィールドを空のオブジェクト（{}）に設定します。

このフィールドは spec.clusters[].loadBalancer.unmanaged と排他関係にあります。

シャーディングされたクラスターソースの場合は、マネージドロードバランサーを使用する場合は spec.security.tls も構成する必要があります。Envoy プロキシは、TLS を必要とする SNI を使用して正しいシャードにトラフィックをルーティングします。

例

spec:
  clusters:
    - loadBalancer:
        managed: {}

spec.clusters[].loadBalancer.managed.externalHostname

型: string

Envy プロキシが受信リクエストの SNI 一致を要求するホスト名。Kubernetes 演算子 はこの値を使用して、受信 mongod 接続からの TLS SNIフィールドに一致するルーティング ルールを構成します。Envy TLSサーバー証明書の SAN（サブジェクト代替名）フィールドにこのホスト名を含める必要があります。

シャーディングされたクラスターソースの場合、値には Kubernetes Operator がシャードごとに展開する {shardName} プレースホルダーが含まれている必要があります。各シャードには固有のホスト名があり、Envoy TLS サーバー証明書には、展開されたすべてのシャードホスト名が SAN に含まれている必要があります。ワイルドカード証明書を使用すると、単一の証明書ですべてのシャードをカバーでき、シャードの追加時の再発行を回避できます。レプリカセットソースの場合、{shardName} プレースホルダーは使用しないでください。

このフィールドは、 MongoDBが外部マネージドされている場合（ Kubernetes 演算子 によって配置されていない場合）に必要です。MongoDB が同じクラスターで演算子によって管理されている場合は、 Kubernetes Operator がルーティングを自動構成するため、このフィールドを省略します。

複数のクラスター配置では、各クラスターエントリは通常、独自のホスト名を使用します。ただし、Kubernetes Operator は、複数のクラスターで 1 つのホスト名の共有を許可します。例えば、複数のクラスターの Envoy プロキシの前面にアベイラビリティーゾーンにまたがるフェイルオーバープロキシがある場合です。

例

# Replica set with external MongoDB
spec:
  clusters:
    - loadBalancer:
        managed:
          externalHostname: "search.apps.example.com"
# Sharded cluster with external MongoDB
spec:
  clusters:
    - loadBalancer:
        managed:
          externalHostname: "{shardName}.search.example.com"

spec.clusters[].loadBalancer.managed.routerHostname

型: string

mongos ルーターがマネージド Envoy ロードバランサーを介してこのクラスターの mongot インスタンスにアクセスするためのエンドポイントで、host:port 形式です。Kubernetes Operator は、クラスター レベルのルーティング チェーンでの SNI マッチングにホスト名を使用するため、Envoy TLS サーバー証明書にはこのホスト名を SAN に含める必要があります。

外部のシャーディングされた MongoDB ソース (spec.source.external.shardedCluster)でマネージドロード バランサーを使用する場合、このフィールドが必要になります。Kubernetes 演算子は、レプリカセット ソースおよび演算子マネージド MongoDB についてはこのフィールドを無視します。

externalHostname とは異なり、Kubernetes 演算子はこの値をそのまま使用します。したがって、値に {shardName} プレースホルダーを含めることはできません。このエンドポイントは、mongos のシャードに依存しないエントリポイントです。

マルチクラスター配置では、各クラスターエントリは通常、個別の値を使用します。ただし、Kubernetes 演算子では、複数のクラスターの Envoy プロキシの前面にアベイラビリティーゾーンにまたがるフェイルオーバー プロキシがある場合など、クラスター間で 1 つの値を共有できます。

例

spec:
  clusters:
    - loadBalancer:
        managed:
          externalHostname: "{shardName}.search.example.com"
          routerHostname: "search-router.example.com:27028"

spec.clusters[].loadBalancer.managed.replicas

タイプ: 整数

この Kubernetes クラスターに配置する Envoy プロキシのポッド数。値は 1 以上である必要があります。省略された場合、デフォルトは 1 になります。

spec.clusters[].loadBalancer.managed.resourceRequirements

タイプ: Core/v1/ResourceRequirements

Envyコンテナがリクエスト、制限することができる CPU とメモリ。この設定を指定すると、 Kubernetes Operator はデフォルトを完全に置き換えます。

省略した場合、 Kubernetes演算子は次のデフォルト値を使用します。

requests:
  cpu: 100m
  memory: 128Mi
limits:
  cpu: 500m
  memory: 512Mi

例

spec:
  clusters:
    - loadBalancer:
        managed:
          resourceRequirements:
            requests:
              cpu: "200m"
              memory: "256Mi"
            limits:
              cpu: "1"
              memory: "1Gi"

spec.clusters[].loadBalancer.managed.deployment

型: オブジェクト

Kubernetes演算子が 演算子が作成した 環境への配置 にマージする上書き。MongoDBリソースで spec.statefulSet と同じ規則に従います。省略した場合、 Kubernetes演算子は環境配置にデフォルトを使用します。

このオブジェクトには 2 つのフィールドが含まれています。

• metadata には、 Kubernetes演算子が 環境配置メタデータにマージする labels フィールドと annotations フィールドが含まれています。

• spec — apps/v1/DeploymentSpecオブジェクト。Kubernetes 演算子はこれらのオーバーライドを Envy 配置 仕様にマージします。

例

spec:
  clusters:
    - loadBalancer:
        managed:
          deployment:
            spec:
              template:
                spec:
                  nodeSelector:
                    kubernetes.io/os: linux

spec.clusters[].loadBalancer.managed.retryPolicy

型: オブジェクト

Envoy プロキシがアップストリーム mongot インスタンスへの個別の gRPC ストリームに適用する再試行動。Envoy プロキシは、失敗した試行とは異なる mongot ホストに各再試行を送信します。

このフィールドを省略すると、Envoy プロキシはデフォルト値で再試行します。デフォルト値は、トライごとのタイムアウトが 60s の場合に 2 回再試行するというものです。

例

spec:
  clusters:
    - loadBalancer:
        managed:
          retryPolicy:
            numRetries: 2
            perTryTimeout: "60s"

spec.clusters[].loadBalancer.managed.retryPolicy.numRetries

タイプ: 整数

リクエストごとの最大再試行回数。値は 1 以上である必要があります。省略すると、リクエストごとに合計 3 回の試行が許可される 2 がデフォルトに設定されます。

spec.clusters[].loadBalancer.managed.retryPolicy.perTryTimeout

型: string

元のリクエストを含む各個の試行のタイムアウトを期間 string として表示します（例："30s"）。省略された場合、デフォルトは "60s" になります。

spec.clusters[].loadBalancer.managed.minMongotReadyReplicas

タイプ: 整数

mongot グループ (例えば、1 シャードの mongot インスタンス)が Envoy プロキシがトラフィックをルーティングする前に持つ必要がある、準備できている mongot レプリカの最小数。グループがこのスレッショルを下回っている間、Envoy プロキシはそのグループ宛てのトラフィックを正常な mongot グループに転送し、リクエストを routed_from_another_shard ヘッダーでマークします。これらのリクエストはエラーではなく、空の結果を返します。

値は 1 以上である必要があります。省略された場合、デフォルトは 1 になります。

spec.clusters[].loadBalancer.unmanaged

型: オブジェクト

ユーザー提供の（独自の） L7 ロードバランサーを構成します。ロードバランサーの外部での配置と構成は、ユーザーの責任となります。

このフィールドは spec.clusters[].loadBalancer.managed と排他関係にあります。マルチクラスター配置は管理対象外のロードバランサーをサポートしていません。

spec.clusters[].loadBalancer.unmanaged.endpoint

型: string

host:port 形式の BYO ロード バランサーのエンドポイントとなる接続されたデバイス。spec.clusters[].loadBalancer.unmanaged を構成する場合は、このフィールドを指定する必要があります。

Kubernetes Operator が MongoDB の配置を管理する場合（spec.source.mongodbResourceRefを使用）、Kubernetes Operator はこの値を mongod 構成に mongotHost および searchIndexManagementHostAndPort として書き込みます。MongoDB が外部にある場合は、同じ値を使用して mongod パラメータを自分で構成します。

外部のシャーディングされたクラスターソースの場合、値には Kubernetes Operator がシャードごとに展開する {shardName} プレースホルダーが含まれている必要があり、プレースホルダー以外の内容も含まれている必要があります。外部のレプリカセットソースの場合、値に {shardName} プレースホルダーを含めることはできません。

例

# Replica set example
spec:
  clusters:
    - loadBalancer:
        unmanaged:
          endpoint: "search-lb.corp.example.com:443"
# Sharded cluster example
spec:
  clusters:
    - loadBalancer:
        unmanaged:
          endpoint: "{shardName}-lb.corp.example.com:443"

シャードごとの上書き

spec.clusters[].shardOverrides

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

このクラスターエントリ内の特定のシャードのサイズ設定をクラスターのデフォルトとは異なる方法でオーバーライドします。このフィールドを使用して、個別のシャードにクラスターの他のシャードよりも多くまたは少なく mongot レプリカ、リソース、またはストレージを付与します。

このフィールドは、外部のシャーディングされたクラスターソース (spec.source.external.shardedCluster) のみで使用できます。参照する各シャード名は spec.source.external.shardedCluster.shards[*].shardName に存在する必要があり、各シャードはクラスターエントリーごとに最大 1 回だけ上書きできます。

オーバーライドで replicas、resourceRequirements、persistence、jvmFlags を設定すると、名前付きシャードのクラスター値が置き換えられます。Kubernetes Operator は statefulSet をクラスター値にディープマージします。設定しないフィールドはクラスター値を継承します。

例

spec:
  clusters:
    - replicas: 2
      shardOverrides:
        - shardNames:
            - shard-0
          replicas: 3
          resourceRequirements:
            requests:
              cpu: "4"
              memory: 8Gi

spec.clusters[].shardOverrides[*].shardNames

タイプ: 文字列の配列

オーバーライドが適用されるこのクラスターエントリ内のシャードの名前。このフィールドは必須であり、少なくとも 1 つのエントリを含む必要があります。

spec.clusters[].shardOverrides[*].replicas

タイプ: 整数

名前付きシャードのクラスターの mongot レプリカカウントを置き換えます。0 の値は、これらのシャードの mongot インスタンスをオフラインにします。

spec.clusters[].shardOverrides[*].resourceRequirements

タイプ: Core/v1/ResourceRequirements

クラスターの CPU とメモリのリクエストと名前付きシャードの制限を置き換えます。

spec.clusters[].shardOverrides[*].persistence

型: オブジェクト

指定されたシャードのクラスターの永続ボリューム構成を置き換えます。spec.clusters[].persistence と同じスキーマを使用します。

spec.clusters[].shardOverrides[*].statefulSet

型: オブジェクト

名前付きシャードの StatefulSet オーバーライド。他のオーバーライド フィールドとは異なり、Kubernetes 演算子はこの値をクラスターの spec.clusters[].statefulSet 値に置き換えるのではなく、ディープマージします。

spec.clusters[].shardOverrides[*].jvmFlags

タイプ: 文字列の配列

空でないリストに設定すると、名前付きシャードのクラスターの spec.clusters[].jvmFlags が置き換えられます。spec.clusters[].jvmFlags の形式ルールはこのフィールドにも適用されます。

同期ソースの選択

spec.clusters[].syncSourceSelector

型: オブジェクト

このクラスターエントリの mongot インスタンスがデータを同期する mongod ノードを選択します。

spec.clusters[].syncSourceSelector.matchTagSets

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

レプリカセットタグにより同期ソース mongod ノードを選択するレプリカセットタグセットの順序付きリスト。Kubernetes Operator は、リストを mongot 構成に渡します。mongot は、最初に一致するタグセットが選択したノードから同期し、セカンダリノードを優先します。

各エントリは、タグ名とタグ値のマップです。空のドキュメント ({})はどのノードにもマッチするため、前のタグセットがマッチしない場合のマッチオールのフォールバックとして末尾の{}エントリを追加できます。最大50エントリを指定できます。

例

spec:
  clusters:
    - syncSourceSelector:
        matchTagSets:
          - region: us-east-1
            workload: search
          - {}

JVM Flags

spec.clusters[].jvmFlags

タイプ: 文字列の配列

mongot プロセスに渡されるJVMフラグ。Kubernetes演算子は、--jvm-flags "<all flags space-separated>" を使用する mongotスタートアップコマンドに変更せずに フラグを含めます。

各フラグは -X、-XX:、または -D で始まる必要があります。スペースを含めることはできません。英数字と .、_、+、:、-、= の文字のみを含めることができます。Kubernetes 演算子は、これらのルールに一致しないフラグを拒否します。

このフィールドに -Xms または -Xmx を指定しない場合、 Kubernetes Operator は両方を spec.clusters[].resourceRequirements.requests.memory の半分に設定して、ヒープサイズを自動計算します。リソース要件を指定しない場合、 Kubernetes 演算子はデフォルトの 4Gi メモリリクエストを使用し、約 -Xmx2048m -Xms2048m を生成します。

独自の -Xms または -Xmx 値を指定すると、 Kubernetes 演算子 はそれらを使用し、値を上書きしません。Kubernetes Operator は、演算子によって計算されたフラグの後に、指定したフラグを常に追加します。

「mongot のハードウェア サイズ」を参照してください。

例

spec:
  clusters:
    - jvmFlags:
        - -Xms2g
        - -Xmx2g

StatefulSet の上書き

spec.clusters[].statefulSet

型: オブジェクト

Kubernetes 演算子が mongot ポッドを配置するために作成する StatefulSet の上書き。Kubernetes 演算子は常に上書きを最後に適用するため、Kubernetes 演算子が計算した設定が上書きされます。

このオブジェクトには 2 つのフィールドが含まれています。

• metadata には、Kubernetes 演算子が StatefulSet メタデータにマージする labels フィールドと annotations フィールドが含まれます。

• spec — apps/v1/StatefulSetSpec オブジェクト。Kubernetes 演算子はこれらのオーバーライドを StatefulSet 仕様にマージします。

注意

spec.clusters[].statefulSet を使用してリソース要件や永続性設定を設定しないでください。代わりに、それぞれ spec.clusters[].resourceRequirements と spec.clusters[].persistence フィールドを使用してください。

mongot詳細設定

spec.clusters[].advancedMongotConfigs

型: オブジェクト

このクラスターエントリの高度な mongot 設定。Kubernetes 演算子は、mongot 構成ファイルの advancedConfigs キーの下の値を、読み取りまたは変更せずにそのままレンダーします。このフィールドは、Kubernetes 演算子が mongot 構成内の他の場所で生成する設定には影響しません。

このフィールドは、MongoDBSearch リソースがファーストクラスのフィールドとして公開していない mongot 設定にのみ使用します。