Configuraciones de MongoDB Search y búsqueda vectorial

Configuraciones para la configuración de la fuente de datos

spec.source

Tipo: objeto

Configuración que describe el origen de MongoDB para mongot. El origen puede ser un conjunto de réplicas o un clúster fragmentado. Esta configuración es necesaria si:

• MongoDB es externo

• MongoDB tiene un nombre diferente de MongoDBSearch

El recurso MongoDBSearch siempre debe estar conectado a una implementación de MongoDB. Si implementó utilizando el operador de Kubernetes con MongoDB el MongoDBCommunity CRD o, y si spec.source está vacío, el operador de Kubernetes utiliza lo siguiente en función metadata.name de para buscar la base de datos en Kubernetes:

• Encuentra MongoDB o MongoDBCommunity recursos con el mismo nombre que se establece para metadata.name en MongoDBSearch, en el mismo namespace.

• Encuentre la contraseña secreta para el usuario mongot a partir del secreto <MongoDBSearch.metadata.name>-search-sync-source-password.

spec.source.mongodbResourceRef.name

Tipo: string

Nombre del recurso MongoDB o MongoDBCommunity que se asociará con este recurso de MongoDB Search y Vector Search. El operador de Kubernetes admite conjuntos de réplicas y clústeres fragmentados. No puede haber más de un recurso MongoDBSearch que haga referencia al mismo recurso MongoDB o MongoDBCommunity. Si especifica un nombre diferente, debe indicar explícitamente el recurso MongoDB o MongoDBCommunity donde desea habilitar MongoDB Search y Vector Search.

Si haces referencia a un recurso de clúster fragmentado MongoDB, el operador de Kubernetes descubre automáticamente la topología de fragmentación (nombres de fragmentación, miembros del conjunto de réplicas, enrutadores mongos) y crea conjuntos de estado mongot por fragmentación de forma automática. No necesitas realizar ninguna configuración externa adicional.

Utilice este campo solo si su recurso MongoDB o MongoDBCommunity está implementado en el mismo clúster de Kubernetes y se encuentra en el mismo espacio de nombres que su recurso MongoDBSearch. Si configura este campo, el operador de Kubernetes automáticamente:

• Establece las cadenas de conexión adecuadas a la base de datos.

• Reconfigura las implementaciones de la base de datos MongoDB estableciendo los parámetros necesarios para habilitar la funcionalidad de búsqueda y configura las direcciones de los pods de búsqueda.

Si tu base de datos está implementada fuera de Kubernetes o se encuentra en un diferente namespace, usa spec.external para configurar la conexión a la base de datos. Este campo es excluyente con spec.external.

Si se omite, el operador de Kubernetes busca un recurso MongoDB o MongoDBCommunity con el mismo nombre que este recurso MongoDBSearch.

Configuración para configurar el mongot usuario

spec.source.username

Tipo: string

Nombre de usuario para usar para autenticar mongot con mongod. El usuario especificado debe tener el rol de searchCoordinator. Si se omite, el Operador Kubernetes asume que el nombre de usuario es search-sync-source.

spec.source.passwordSecretRef.name

Tipo: string

Nombre del secreto que contiene la contraseña que mongot debe usar para autenticarse con mongod. Si se omite, el valor predeterminado es <MongoDBSearch.metadata.name>-search-sync-source-password.

spec.source.passwordSecretRef.key

Tipo: string

Clave bajo la cual se almacena el valor de la contraseña en el secreto. Si se omite, el valor predeterminado es password.

Configuración para la autenticación x509

spec.source.x509

Tipo: objeto

Configura la autenticación del certificado de cliente x509 para la conexión de la fuente de sincronización mongot. Si configura este campo, mongot se autentica en MongoDB usando x509 en lugar de nombre de usuario y contraseña.

Este campo es mutuamente excluyente con spec.source.passwordSecretRef y spec.source.username. El operador de Kubernetes rechaza la configuración si se especifica tanto x509 como autenticación por contraseña.

spec.source.x509.clientCertificateSecretRef

Tipo: objeto

Secreto que contiene el certificado de cliente x509 y la clave para autenticarse en la fuente de sincronización de MongoDB. El secreto debe contener las siguientes claves:

• tls.crt — Certificado de cliente (obligatorio)

• tls.key — Clave privada (obligatoria)

• tls.keyFilePassword — Contraseña para la clave privada (opcional)

Debe especificar este campo si establece spec.source.x509.

Ejemplo

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

Configuraciones para conectar con MongoDB externo

Los siguientes ajustes son necesarios únicamente para configurar una conexión a una implementación externa de MongoDB.

spec.source.external

Tipo: objeto

Configuraciones que describen la fuente de datos externa. Este objeto describe la configuración del recurso de MongoDB Search y búsqueda vectorial para conectarse a un MongoDB externo. Estos ajustes solo deben especificarse si deseas conectarte a una MongoDB externa que no fue implementada mediante el Operador de Kubernetes. Si se especifica, estas configuraciones anulan las configuraciones para spec.source.mongodbResourceRef.name. Si usaste el Operador de Kubernetes para instalar MongoDB en el mismo clúster, estas configuraciones son opcionales.

Configuración de seguridad

spec.security

Tipo: objeto

Configuración de seguridad del servidor de escucha mongot.

spec.security.tls

Tipo: objeto

TLS configuración para mongot. Si se omite, mongot no utilizará TLS para conexiones entrantes.

spec.security.tls.certificateKeySecretRef.name

Tipo: string

Obsoleto desde la 1.8.0 versión: utilice spec.security.tls.certsSecretPrefix en su lugar.

Nombre del secreto TLS en el mismo espacio de nombres que contiene la clave privada (tls.key) y el certificado (tls.crt). El secreto puede ser de tipo kubernetes.io/tls (emitido por cert-manager) o puede crearse manualmente.

El operador de Kubernetes aún admite este campo para implementaciones de conjuntos de réplicas por motivos de compatibilidad con versiones anteriores. Sin embargo:

• Para implementaciones de clústeres fragmentados, el operador de Kubernetes rechaza este campo durante la validación. En su lugar, utilice spec.security.tls.certsSecretPrefix, ya que una única referencia secreta no puede abarcar los certificados por fragmento.

• Si especifica tanto certificateKeySecretRef como certsSecretPrefix, certificateKeySecretRef tendrá prioridad para las implementaciones de conjuntos de réplicas.

Para nuevas implementaciones, utilice spec.security.tls.certsSecretPrefix incluso para conjuntos de réplicas.

spec.security.tls.certsSecretPrefix

Tipo: string

Prefijo que el operador de Kubernetes utiliza para derivar nombres de secretos TLS mediante una convención de nomenclatura. Si configura este campo, el operador de Kubernetes buscará secretos que sigan estos patrones en lugar de requerir referencias explícitas de secretos para cada componente:

Componente	Patrón de nombre secreto
Certificado del servidor mongot del conjunto de réplicas	{certsSecretPrefix}-{name}-search-cert
Certificados fragmentados mongot (por fragmento)	{certsSecretPrefix}-{name}-search-0-{shardName}-cert
Certificado de servidor de balanceador de carga administrado	{certsSecretPrefix}-{name}-search-lb-0-cert
Certificado de cliente de balanceador de carga administrado	{certsSecretPrefix}-{name}-search-lb-0-client-cert

Dónde:

• {name} es metadata.name del recurso MongoDBSearch

• {shardName} es el valor de spec.source.external.shardedCluster.shards[*].shardName

Si se omite, este campo toma por defecto una cadena vacía y el operador de Kubernetes utiliza spec.security.tls.certificateKeySecretRef en su lugar.

Nota

Para implementaciones de clústeres fragmentados, debe usar certsSecretPrefix en lugar de certificateKeySecretRef. El operador de Kubernetes rechaza certificateKeySecretRef para topologías fragmentadas porque una única referencia secreta no puede cubrir certificados por fragmento.

Ejemplo

spec:
  security:
    tls:
      certsSecretPrefix: my-prefix

Configuración para múltiples instancias de Mongot

spec.replicas

Tipo: entero

Número de mongot pods a desplegar. Para una fuente de conjunto de réplicas, este es el número total de mongot pods. Para una fuente de clúster fragmentado, este es el número de mongot pods por fragmento.

Si spec.replicas es mayor que 1, también debe configurar spec.loadBalancer para enrutar el tráfico entre mongod y las múltiples instancias mongot.

Si se omite, es por defecto 1.

Ejemplo

spec:
  replicas: 2

Configuración para el equilibrio de carga

spec.loadBalancer

Tipo: objeto

Configuración para el balanceo de carga L7 entre mongod (o mongos) y mongot. Este campo es obligatorio si spec.replicas es mayor que 1. Si spec.replicas es igual a 1, este campo es opcional. Puede configurar un balanceador de carga incluso para una única instancia mongot para prepararse para el escalado posterior.

Se debe establecer exactamente uno de managed o unmanaged.

El balanceador de carga afecta a qué certificados TLS ven los clientes mongod y qué nombres de host deben contener esos certificados:

• Sin un balanceador de carga, semongod conecta directamente mongot a. El certificado TLS presentado a mongod es el mongot propio certificado de. Si el clúster de MongoDB está fuera de Kubernetes, el mongot servicio se expone en un dominio externo. Debe incluir ese dominio externo en el mongot campo SAN (Subject Alternative Name) del certificado TLS.

• Con un balanceador de carga administrado spec.loadBalancer.managed(), el proxy Envoy es el único componente que se conecta directamente mongot a. Envoy llega a los mongot pods utilizando sus FQDN de servicio internos sin cabeza:

  • Conjunto de réplicas: <pod>.<name>-search-svc.<ns>.svc.cluster.local

  • Clúster fragmentado: <pod>.<name>-search-0-<shard>-svc.<ns>.svc.cluster.local

  Emita el mongot certificado TLS con estos dominios locales del clúster en el campo SAN. Puede usar un certificado comodín para evitar volver a emitir certificados cuando cambie el número de mongot pods. Los mongod procesos externos ven el certificado TLS del proxy Envoy, por lo que debe incluir los dominios externos en los SAN del certificado Envoy, no en el mongot certificado.

Tip

Habilite un balanceador de carga administrado incluso si inicialmente implementa un solo pod mongot. Con el balanceador de carga configurado, los dominios en sus certificados TLS se mantienen estables si aumenta la escala spec.replicas posteriormente, ya que el balanceador de carga ya está presente entre mongod y mongot.

spec.loadBalancer.managed

Tipo: objeto

Configura un balanceador de carga Envoy administrado por el operador. El operador de Kubernetes implementa y administra el proxy Envoy con enrutamiento, mTLS y fijación de flujo HTTP/2+gRPC correctos. Establezca este campo en un objeto vacío{} () para usar los valores predeterminados.

Este campo es mutuamente excluyente con spec.loadBalancer.unmanaged.

Ejemplo

spec:
  loadBalancer:
    managed: {}

spec.loadBalancer.managed.externalHostname

Tipo: string

Nombre de host que el proxy Envoy espera para la coincidencia SNI en las solicitudes entrantes. El operador de Kubernetes utiliza este valor para configurar reglas de enrutamiento que coincidan con el campo SNI de TLS de las conexiones entrantes mongod. El certificado del servidor TLS de Envoy debe incluir este nombre de host en su campo SAN (Subject Alternative Name).

Para clústeres fragmentados, el valor debe contener un marcador de posición {shardName} que el operador de Kubernetes expande para cada fragmento. Cada fragmento obtiene un nombre de host único, y el certificado del servidor TLS de Envoy debe incluir todos los nombres de host de los fragmentos expandidos en sus SAN. Puede usar un certificado comodín para cubrir todos los fragmentos con un solo certificado y evitar tener que volver a emitirlo cuando se agreguen fragmentos.

Este campo es obligatorio si MongoDB se gestiona externamente (no se implementa mediante el operador de Kubernetes). Si MongoDB se gestiona mediante el operador en el mismo clúster, omita este campo, ya que el operador de Kubernetes configura automáticamente el enrutamiento.

Ejemplo

# 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

Tipo: core/v1/ResourceRequirements

CPU y memoria que el contenedor Envoy puede solicitar y a las que puede estar limitado. Si especifica esta configuración, el operador de Kubernetes reemplaza por completo los valores predeterminados.

Si se omite, el Operador de Kubernetes utiliza los siguientes valores por defecto:

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

Ejemplo

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

spec.loadBalancer.managed.deployment

Tipo: objeto

Anula las configuraciones que el operador de Kubernetes incorpora al despliegue de Envoy creado por el operador. Sigue la misma convención que spec.statefulSet en los recursos de MongoDB. Si se omite, el operador de Kubernetes utiliza la configuración predeterminada para el despliegue de Envoy.

Este objeto contiene dos campos:

• metadata — contiene campos labels y annotations que el operador de Kubernetes fusiona en los metadatos de la implementación de Envoy.

• spec — un objeto apps/v1/DeploymentSpec. El operador de Kubernetes fusiona estas anulaciones en la especificación de despliegue de Envoy.

Ejemplo

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

spec.loadBalancer.unmanaged

Tipo: objeto

Configura un balanceador de carga L7 proporcionado por el usuario (Bring Your Own). Usted es responsable de implementar y configurar el balanceador de carga externamente.

Este campo es mutuamente excluyente con spec.loadBalancer.managed.

spec.loadBalancer.unmanaged.endpoint

Tipo: string

El punto final del balanceador de carga BYO en formato host:port. El operador de Kubernetes escribe este valor en la configuración mongod como mongotHost y searchIndexManagementHostAndPort.

Este campo solo es necesario cuando el operador de Kubernetes gestiona el despliegue de MongoDB (mediante spec.source.mongodbResourceRef), ya que el operador de Kubernetes necesita el punto final para configurar los parámetros mongod. Si tanto el balanceador de carga como MongoDB son externos (no gestionados por el operador de Kubernetes), este campo no es necesario, ya que usted mismo configura los parámetros mongod.

Para clústeres fragmentados, el valor debe contener un marcador de posición {shardName} que el operador de Kubernetes expande por cada fragmento.

Ejemplo

# 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"

Configuraciones para el provisionamineto de recursos

spec.resourceRequirements

Tipo: core/v1/ResourceRequirements

CPU y memoria que el contenedor mongodb-search puede solicitar y tener limitados. Recomendamos utilizar este campo para personalizar las asignaciones de recursos en lugar de sobrescribirlo con spec.statefulSet.

Si no se modifica el tamaño del montón de la JVM en spec.jvmFlags, el operador de Kubernetes establece el tamaño predeterminado del montón (-Xmx) en el 50% de la memoria disponible para el pod mongot. Ajuste spec.resourceRequirements según corresponda para controlar tanto los recursos del pod como el tamaño del montón de la JVM.

Si se omite, el Operador de Kubernetes utiliza los siguientes valores por defecto:

requests:
  cpu: 2
  memory: 2G

spec.resourceRequirements.limits

Tipo: objeto

Límite máximo de recursos (CPU y memoria) que el contenedor mongodb-search puede consumir. De forma predeterminada, no hay límites definidos. Si se omite, el pod no se restringe y, por lo tanto, podría usar todos los recursos del nodo. Recomendamos establecer límites según la carga de trabajo.

spec.resourceRequirements.requests

Tipo: objeto

Cantidad de CPU y memoria solicitada para el contenedor mongodb-search. Si se omite, el operador de Kubernetes utiliza los siguientes valores predeterminados:

requests:
  cpu: 2
  memory: 2G

spec.persistence.single

Tipo: objeto

Configuración de almacenamiento para el volumen de persistencia de MongoDB Search y Vector Search, donde se almacenan los índices de MongoDB Search y Vector Search. Cada instancia de búsqueda (pod) tiene su propio almacenamiento independiente para mantener los índices, que no se comparte con la base de datos MongoDB. Solo los metadatos del índice (definiciones) se almacenan en la base de datos.

Escalar	Tipo de dato	Descripción
labelSelector	string	Etiqueta utilizada para vincular volúmenes montados a directorios.
storage	string	Tamaño mínimo del volumen persistente que debe montarse. Este valor se expresa como un entero seguido de una unidad de almacenamiento en notación JEDEC. El valor por defecto es 16 Gi. Por ejemplo, si set de réplicas requiere 60 gigabytes de espacio de almacenamiento, establece este valor en 60Gi.
storageClass	string	Tipo de almacenamiento especificado en una notificación de volumen persistente. Puede crear este tipo de almacenamiento como un objeto StorageClass antes de usarlo en esta especificación de objeto. Asegúrate de establecer el StorageClass reclaimPolicy como Retain. Esto garantiza que los datos se conserven cuando se elimine una Solicitud de Volumen Persistente.

MongoDBSearch solo admite el campo de persistencia single. Si se omite, el Kubernetes operador establece spec.persistence.single.storage a 10GB.

Configuraciones para registros

spec.logLevel

Tipo: string

Nivel de verbosidad de los registros de mongot. El valor puede ser uno de los siguientes:

• TRACE

• DEBUG

• INFO

• WARN

• ERROR

Si se omite, es por defecto INFO.

Configuración para métricas

spec.prometheus

Tipo: objeto

Esto solo está disponible en v1.6 y versiones posteriores.

Configuración para habilitar el endpoint de métricas de Prometheus. Si se omite, se desactiva el endpoint de métricas en mongot. Para habilitar el endpoint de métricas de Prometheus en el puerto por defecto (9946), especifica un objeto {} vacío en el campo spec.prometheus. Para cambiar el puerto, configúralo en el campo spec.prometheus.port.

spec.prometheus.port

Tipo: string

Puerto en el que habilitar el endpoint de métricas de Prometheus. De forma predeterminada, el endpoint de métricas de Prometheus está habilitado en el puerto 9946.

Configuración para la incrustación automatizada

spec.autoEmbedding

Tipo: Objeto

Configuración para Incrustación automátizada para datos de texto en tu colección.

spec.autoEmbedding.embeddingModelAPIKeySecret

Tipo: Objeto

Configuración para el proveedor de modelos de incrustación API keys. Para habilitar la Embedding Automatizada, debes crear dos claves, una para generar embedding en el momento del índice para los datos de tu colección y otra para generar embedding en el momento de la query para el texto de la query. Si no tienes ya las llaves, te recomendamos que crees llaves a partir de dos proyectos de Atlas. Para obtener más información sobre la creación de claves para los proyectos Atlas desde la Interfaz de Usuario de Atlas, consulte Gestionar claves API.

spec.autoEmbedding.embeddingModelAPIKeySecret.name

Tipo: string

Nombre del secreto que contiene las llaves de la API del modelo de incrustación que mongot debe utilizar para generar incrustaciones en el momento del índice y de la query.

spec.autoEmbedding.providerEndpoint

Tipo: string

URL del punto final del modelo de incrustación para generar incrustaciones. El valor varía según se creen las claves desde la interfaz de usuario de Atlas (recomendado) o directamente desde el servicio de incrustación (Voyage AI). Para claves creadas desde:

• Atlas Interfaz de Usuario, el valor es https://ai.mongodb.com/v1/embeddings (por defecto)

• Voyage AI, el valor es https://api.voyageai.com/v1/embeddings

Configuración de JVM

spec.jvmFlags

Tipo: arreglo de cadenas

Indicadores de JVM pasados ​​al proceso mongot. El operador de Kubernetes incluye los indicadores sin modificación en el comando de inicio mongot usando --jvm-flags "<all flags space-separated>".

Si no especifica -Xms o -Xmx en este campo, el operador de Kubernetes calcula automáticamente el tamaño del montón estableciendo ambos a la mitad de spec.resourceRequirements.requests.memory. Si no especifica los requisitos de recursos, el operador de Kubernetes utiliza una solicitud de memoria predeterminada de 4Gi, lo que produce aproximadamente -Xmx2048m -Xms2048m.

Si proporciona sus propios valores -Xms o -Xmx, el operador de Kubernetes los utiliza y no los sobrescribe. El operador de Kubernetes siempre agrega los indicadores que usted proporciona después de los indicadores calculados por el operador.

Para obtener más información, consulte Dimensionamiento de hardware para mongot.

Ejemplo

spec:
  jvmFlags:
    - -Xms2g
    - -Xmx2g

Otros ajustes

spec.version

Tipo: string

Versión de mongodb-search imagen docker. Si se omite, el Operador de Kubernetes elige automáticamente la versión más reciente de MongoDBSearch. Puedes establecerlo explícitamente para evitar actualizaciones automáticas cuando se actualice la versión del Operador de Kubernetes.

spec.statefulSet

Tipo: apps/v1/StatefulSet

Especificación para el StatefulSet, creado para la implementación de mongot pods que sobrescribe la configuración aplicada por el operador de Kubernetes. Las sobrescrituras siempre se aplican al final. Admite tanto los campos spec.statefulSet.spec como spec.statefulSet.metadata.

Nota

No establezcas requisitos de recursos o configuraciones de persistencia usando spec.statefulSet. En su lugar, utilice los campos spec.resourceRequirements y spec.persistence respectivamente.