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

データソースを構成する設定

spec.source

型: オブジェクト

mongot のMongoDBソースを記述する設定。ソースはレプリカセットとシャーディングされたクラスターにすることができます。この設定は、次の場合に必要です。

• MongoDB は外部です

• MongoDB MongoDBSearch とは名前が異なります

MongoDBSearchリソースは常にMongoDB配置に接続されている必要があります。MongoDB または MongoDBCommunity CRD とともにKubernetes Operator を使用して配置した場合、かつ spec.source が空の場合、 Kubernetes Operator は metadata.name に基づいて次のコマンドを使用して、 Kubernetes内のデータベースを検索します。

• MongoDBSearch で、同じ名前空間で、metadata.name に設定されている名前と同じ名前の MongoDB または MongoDBCommunity リソースを検索します。

• <MongoDBSearch.metadata.name>-search-sync-source-password シークレットから mongot ユーザーのパスワードシークレットを見つけます。

spec.source.mongodbResourceRef.name

型: string

このMongoDB Search およびベクトル検索リソースに関連付ける MongoDB または MongoDBCommunityリソースの名前。Kubernetes演算子は、レプリカセットとシャーディングされたクラスターの両方をサポートします。同じ MongoDB または MongoDBCommunityリソースを参照する複数の MongoDBSearchリソースは存在できません。別の名前を指定する場合は、 MongoDB Search とベクトル検索を有効にする MongoDB または MongoDBCommunity を明示的に点必要があります。

シャーディングされたクラスターのMongoDBリソースを参照と、 Kubernetes Operator はシャードトポロジー（シャード名、レプリカセット、mongos ルーター）を自動検出し、シャードごとの mongotステートメントを自動的に作成します。追加の外部設定を実行する必要はありません。

このフィールドは、MongoDB または MongoDBCommunityリソースが同じKubernetesクラスターに配置され、 MongoDBSearchリソースと同じ名前空間にある場合にのみ使用します。このフィールドを に設定すると、 Kubernetes 演算子 は自動的に次のことを行います。

• データベースへの適切な接続文字列を設定します。

• 検索機能を有効にするために必要なパラメーターを設定してMongoDBデータベース配置を再構成し、検索ポッドのアドレスを構成します。

データベースがKubernetes外、または 別の名前空間にある場合は、spec.external を使用してデータベースへの接続を構成します。このフィールドはspec.external と排他関係にあります。

省略した場合、 Kubernetes 演算子 は、この MongoDBSearchリソースと同じ名前を持つ MongoDB または MongoDBCommunityリソースを検索します。

mongot ユーザーを構成するための 設定

spec.source.username

型: string

mongod で mongot を認証するために使用するユーザー名。指定されたユーザーには searchCoordinator ロールが必要です。省略した場合、Kubernetes演算子はユーザー名が search-sync-source であると想定します。

spec.source.passwordSecretRef.name

型: string

mongot が mongod で認証するために使用する必要があるパスワードを含むシークレットの名前。省略した場合、デフォルトは <MongoDBSearch.metadata.name>-search-sync-source-password になります。

spec.source.passwordSecretRef.key

型: string

パスワード値がシークレットで保存されるキー。省略した場合、デフォルトは password になります。

x509 認証の設定

spec.source.x509

型: オブジェクト

mongot 同期ソース接続の x509クライアント証明書認証を構成します。このフィールドを に設定すると、mongot はユーザー名とパスワードの代わりに x509 を使用してMongoDBに認証します。

このフィールドは、spec.source.passwordSecretRef、spec.source.username と相互に排他的です。x509 と パスワード認証 の両方を指定すると、 Kubernetes演算子は構成を拒否します。

spec.source.x509.clientCertificateSecretRef

型: オブジェクト

MongoDB同期ソースに認証するための x509クライアント証明書とキーを含むシークレット。シークレット には次のキーが含まれている必要があります。

• tls.crt — クライアント証明書（必須）

• tls.key — 秘密キー（必須）

• tls.keyFilePassword —秘密キーのパスワード（任意）

spec.source.x509 を設定する場合は、このフィールドを指定する必要があります。

例

spec:
  source:
    x509:
      clientCertificateSecretRef:
        name: mongot-x509-client-cert

外部MongoDBへの接続設定

次の設定は、 MongoDB配置への接続を構成する場合にのみ必要です。

spec.source.external

型: オブジェクト

外部データソースを説明する設定。このオブジェクトでは、 MongoDB Search およびベクトル検索リソースが外部のMongoDBに接続するための設定を記述します。これらの設定は、 Kubernetes演算子を使用して配置されなかった外部MongoDBに接続する場合にのみ指定する必要があります。指定すると、これらの設定は spec.source.mongodbResourceRef.name の 設定を上書きします。Kubernetes Operator を使用して同じクラスターにMongoDBをインストールした場合、これらの設定は任意です。

セキュリティ設定

spec.security

型: オブジェクト

mongot listenサーバーのセキュリティ設定。

spec.security.tls

型: オブジェクト

mongot の TLS 設定。省略した場合、mongot は受信接続に TLS を使用しません。

spec.security.tls.certificateKeySecretRef.name

型: string

バージョン 1.8.0 から非推奨 :代わりに spec.security.tls.certsSecretPrefix を使用してください。

秘密キー（tls.key）と証明書（tls.crt）を含む同じ名前空間内の TLS シークレットの名前。シークレットは、タイプ kubernetes.io/tls（証明書マネージャーによって発行される）または手動で作成することができます。

Kubernetes 演算子 は、下位互換性のためにレプリカセットの配置でこのフィールドを引き続きサポートします。ただし、

• シャーディングされたクラスターの配置の場合、 Kubernetes 演算子は検証中にこのフィールドを拒否します。代わりに spec.security.tls.certsSecretPrefix を使用してください。これは、単一のシークレット参照ではシャードごとの証明書をカバーできないためです。

• certificateKeySecretRef と certsSecretPrefix の両方を指定した場合、レプリカセットの配置では certificateKeySecretRef が優先されます。

新しい配置では、レプリカセットでも spec.security.tls.certsSecretPrefix を使用します。

spec.security.tls.certsSecretPrefix

型: string

Kubernetes 演算子が命名規則によって TLS シークレット名を生成するために使用するプレフィックス。このフィールドを に設定すると、各コンポーネントに対して明示的なシークレット参照が必要になるのではなく、 Kubernetes 演算子 はこれらのパターンに従ってシークレットを検索します。

コンポーネント	シークレット名パターン
レプリカセットの mongotサーバー証明書	{certsSecretPrefix}-{name}-search-cert
シャーディングされた mongot 証明書（シャードあたり）	{certsSecretPrefix}-{name}-search-0-{shardName}-cert
マネージド ロードバランサーサーバー証明書	{certsSecretPrefix}-{name}-search-lb-0-cert
マネージド ロードバランサークライアント証明書	{certsSecretPrefix}-{name}-search-lb-0-client-cert

以下の条件に一致するもの。

• {name} は、MongoDBSearchリソースの metadata.name です

• {shardName} は、次の値です: spec.source.external.shardedCluster.shards[*].shardName

省略した場合、このフィールドはデフォルトで空の文字列になり、 Kubernetes演算子は代わりに spec.security.tls.certificateKeySecretRef を使用します。

注意

シャーディングされたクラスター配置の場合は、certificateKeySecretRef ではなく certsSecretPrefix を使用する必要があります。Kubernetes演算子は、単一のシークレット参照ではシャードごとの証明書をカバーできないため、シャーディングされたトポロジーの certificateKeySecretRef を拒否します。

例

spec:
  security:
    tls:
      certsSecretPrefix: my-prefix

複数の Mongo インスタンスの設定

spec.replicas

タイプ: 整数

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

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

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

例

spec:
  replicas: 2

ロードバランシングの設定

spec.loadBalancer

型: オブジェクト

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

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

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

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

• マネージド ロードバランサー（spec.loadBalancer.managed）では、Envy プロキシは mongot に直接接続する唯一のコンポーネントです。Envy は、内部ヘッドレス サービス FQDN を使用して mongot ポッドに到達します。

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

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

  SANフィールドにこれらのクラスター ローカル ドメインを使用して mongot TLS 証明書を発行します。ワイルドカード証明書を使用すると、mongot ポッドの数が変更されたときに証明書が再発行されないようにできます。外部の mongod プロセスは Envy プロキシの TLS 証明書を参照するため、mongot 証明書ではなく Envy 証明書の SAN に外部ドメインを含めます。

Tip

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

spec.loadBalancer.managed

型: オブジェクト

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

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

例

spec:
  loadBalancer:
    managed: {}

spec.loadBalancer.managed.externalHostname

型: string

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

クラスターの場合、 値にはKubernetes 演算子がシャードごとに展開する {shardName} プレースホルダーが含まれている必要があります。各シャードには一意のホスト名が付けられます。Envy TLSサーバー証明書には SAN 内のすべての展開されたシャード ホスト名を含める必要があります。ワイルドカード証明書 を使用すると、すべてのシャードを単一の証明書でカバーし、シャードが追加されたときに再発行を回避できます。

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

例

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

spec.loadBalancer.managed.resourceRequirements

タイプ: Core/v1/ResourceRequirements

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

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

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

例

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

spec.loadBalancer.managed.deployment

型: オブジェクト

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

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

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

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

例

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

spec.loadBalancer.unmanaged

型: オブジェクト

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

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

spec.loadBalancer.unmanaged.endpoint

型: string

host:port形式の BIO ロードバランサーの エンドポイントとなる接続されたデバイス。Kubernetes 演算子は、この値を mongotHost と searchIndexManagementHostAndPort として mongod 構成に書込みます。

このフィールドは、 Kubernetes Operator がMongoDBの配置をマネージドしている場合にのみ必要です（spec.source.mongodbResourceRef を使用）。Kubernetes Operatorはmongod パラメータを構成するためにエンドポイントが必要であるためです。ロードバランサーとMongoDB の両方が外部（ Kubernetes 演算子 によって管理されていない）の場合、mongod パラメータを自分で構成するため、このフィールドは必須ではありません。

シャーディングされたクラスターの場合、 値にはKubernetes Operator がシャードごとに展開する {shardName} プレースホルダーが含まれている必要があります。

例

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

リソースのプロビジョニングの設定

spec.resourceRequirements

タイプ: Core/v1/ResourceRequirements

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

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

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

requests:
  cpu: 2
  memory: 2G

spec.resourceRequirements.limits

型: オブジェクト

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

spec.resourceRequirements.requests

型: オブジェクト

mongodb-searchコンテナに要求される CPU とメモリの量。省略した場合、 Kubernetes演算子は次のデフォルト値を使用します。

requests:
  cpu: 2
  memory: 2G

spec.persistence.single

型: オブジェクト

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

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

MongoDBSearch は single 永続フィールドのみをサポートしています。省略した場合、Kubernetes演算子は spec.persistence.single.storage を 10GB に設定します。

ログ記録の設定

spec.logLevel

型: string

mongot ログの冗長度。値は次のいずれかになります。

• TRACE

• DEBUG

• INFO

• WARN

• ERROR

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

メトリクスの設定

spec.prometheus

型: オブジェクト

これは、v1.6 以降でのみ使用できます。

Prometheus メトリクス エンドポイントとなる接続されたデバイスを有効にする構成。省略した場合、mongot のメトリクス エンドポイントとなる接続されたデバイスは無効になります。デフォルトポート（9946）で Prometheus メトリクス エンドポイントとなる接続されたデバイスを有効にするには、spec.prometheusフィールドに空の {}オブジェクトを指定します。ポートを変更するには、spec.prometheus.portフィールドに設定します。

spec.prometheus.port

型: string

Prometheus メトリクス エンドポイントとなる接続されたデバイスを有効にするポート。デフォルトでは、Prometheus メトリクス エンドポイントとなる接続されたデバイスはポート 9946 で有効になっています。

自動埋め込みの設定

spec.autoEmbedding

型: オブジェクト

コレクション内のテキスト データ用の自動埋め込みの構成。

spec.autoEmbedding.embeddingModelAPIKeySecret

型: オブジェクト

埋め込みモデルプロバイダーAPIキーの構成。自動埋め込みを有効にするには、2 つのキーを作成する必要があります。1 つはコレクション内のデータのインデックス時に埋め込みを生成するため、もう 1 つはクエリテキストのクエリ時に埋め込みを生成するためです。キーをまだ持っていない場合は、Atlas の 2 つのプロジェクトからキーを作成することをお勧めします。Atlas UIから Atlas プロジェクトのキーを作成する方法について詳しくは、 APIキーの管理 を参照してください。

spec.autoEmbedding.embeddingModelAPIKeySecret.name

型: string

mongot がインデックス時とクエリ時に埋め込みを生成するために使用する必要がある埋め込みモデルAPIキーを含むシークレットの名前。

spec.autoEmbedding.providerEndpoint

型: string

埋め込みを生成するための埋め込みモデルエンドポイントURL。値は、Atlas UIからキーを作成するか（推奨）、埋め込みサービスから直接キーを作成するか（Voyage AI）によって異なります。次から作成されたキーの場合。

• Atlas UI、値は https://ai.mongodb.com/v1/embeddings（デフォルト）

• Voyage AI、値は https://api.voyageai.com/v1/embeddings

JVM構成の設定

spec.jvmFlags

タイプ: 文字列の配列

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

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

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

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

例

spec:
  jvmFlags:
    - -Xms2g
    - -Xmx2g

その他の設定

spec.version

型: string

mongodb-search docker イメージのバージョン。省略した場合、 Kubernetes 演算子は MongoDBSearch の最新バージョンを自動的に選択します。Kubernetes 演算子のバージョンがアップグレードされるときに、自動アップグレードを防止するために明示的に設定することができます。

spec.statefulSet

タイプ: apps/v1/StatefulSet

ポッドを配置するために作成されたmongot Atlas App Services の仕様で、 Kubernetes演算子 が適用する設定を上書きします。上書きは常に最後に適用されます。spec.statefulSet.spec フィールドと spec.statefulSet.metadata フィールドの両方をサポートします。

注意

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