Puedes implementar MongoDB Search y Vector Search en tu clúster de Kubernetes para crear potentes experiencias de búsqueda directamente en tus aplicaciones. Con MongoDB Search y Vector Search, puedes crear tanto búsquedas de texto tradicionales como búsquedas vectoriales con IA que se sincronizan automáticamente con una base de datos MongoDB local. Este enfoque elimina la necesidad de mantener sistemas separados sincronizados, a la vez que proporciona funciones de búsqueda avanzadas. Para obtener más información, consulta:
Para activar las capacidades de búsqueda como la búsqueda de texto completo y la búsqueda semántica en implementaciones locales, debes implementar el proceso de MongoDB Search y búsqueda vectorial (mongot) y conectarlo con la implementación de tu base de datos MongoDB (mongod). La implementación de mongot es opcional y solo se necesita si planeas utilizar las funcionalidades de búsqueda que ofrece.
El proceso de la base de datos MongoDB (mongod) actúa como proxy para todas las consultas de búsqueda de mongot. mongod reenvía la consulta a mongot, que la procesa. mongot devuelve los resultados de la consulta a mongod, que luego te los reenvía a ti. Nunca interactúas directamente con mongot.
Cada proceso mongot tiene su propio volumen persistente que no se comparte ni con la base de datos ni con otros nodos de búsqueda. El almacenamiento se utiliza para mantener índices que se compilan a partir de los datos obtenidos continuamente de la base de datos. Las definiciones del índice (metadatos) se almacenan en la propia base de datos.
El mongot realiza las siguientes acciones:
Gestiona el índice.
El
mongotes responsable de actualizar las definiciones de índices en la base de datos.Obtiene los datos de la base de datos.
Los nodos
mongotestablecen conexiones permanentes con la base de datos en tiempo real.Procesa consultas de búsqueda.
Cuando
mongodrecibe una consulta$search,$searchMeta, o$vectorSearch, dirige la consulta a uno de los nodosmongot. Elmongotque recibe la query la procesa, agrega los datos y envía los resultados amongod, que los reenvía al usuario.
Los componentes mongot están estrechamente acoplados a un único set de réplicas de MongoDB y no pueden compartirse entre varias bases de datos o sets de réplicas. Para una implementación de set de réplicas, un grupo de nodos de búsqueda dedicados sirve al set de réplicas. Para un clúster, cada partición mantiene su propio grupo independiente de mongot nodos. Las particiones no comparten las instancias de mongot.
La conectividad de red entre mongot y mongod va en ambas direcciones:
mongotestablece la conexión con el set de réplicas para obtener los datos que se utilizarán en la creación de índices y la ejecución de queries.mongodSe conecta amongotpara reenviar operaciones relacionadas con la búsqueda, como la gestión de índices y la consulta de datos.
El campo spec.clusters[].replicas controla cuántas instancias de mongot implementa el operador de Kubernetes. Para una fuente de set de réplicas, spec.clusters[].replicas establece el número total de pods mongot. Para una fuente de clúster, spec.clusters[].replicas establece el número de pods mongot por partición.
Si configuras spec.clusters[].replicas a un valor mayor que 1, debes colocar un balanceador de carga L7 entre mongod y los pods mongot. El proceso de mongod abre una sola conexión TCP de larga duración a mongot, por lo que un balanceador de carga L4 no puede distribuir consultas entre múltiples instancias de mongot; todo el tráfico fluye a través de esa única conexión. Un balanceador de carga L7 comprende HTTP/2 y gRPC, lo que le permite distribuir flujos individuales de gRPC a través de mongot pods mientras fija cada flujo a un único mongot durante la duración del cursor de la query.
MongoDB Search and búsqueda vectorial implementación
La arquitectura de implementación de búsqueda varía poco con o sin el operador de Kubernetes. El operador de Kubernetes simplifica los pasos necesarios para implementar nodos de búsqueda completamente funcionales, especialmente cuando la base de datos también es administrada por el operador de Kubernetes.
Para implementar, aplicas el recurso personalizado (CR) MongoDBSearch, que el operador de Kubernetes recoge y comienza a implementar mongot pods y solicita el almacenamiento persistente especificado en el spec. MongoDB Search y la búsqueda de vectores desplegadas a través del Operador Kubernetes pueden dirigirse a un set de réplicas de MongoDB o un clúster fragmentado desplegado por el Operador Kubernetes dentro del mismo clúster de Kubernetes, o a una implementación externa de MongoDB completamente independiente (set de réplicas o clúster fragmentado). Para aprender cómo implementar y configurar mongot para usar:
Un set de réplicas de MongoDB en Kubernetes, consulta Instalar y usar MongoDB Community Edition o Instalar y usar búsqueda With MongoDB Enterprise Edition
Un set de réplicas de MongoDB externo, consulta Instala y usa MongoDB Search y búsqueda vectorial con MongoDB Enterprise Edition.
Requisitos previos
Para utilizar la búsqueda de MongoDB y la búsqueda vectorial en tu:
Para una implementación de MongoDB Community, debe tener un set de réplicas MongoDB 8.2 completamente funcional o posterior, o un clúster implementado dentro de un clúster de Kubernetes utilizando el Operador de Kubernetes.
Implementación de MongoDB Enterprise, debe tener un set de réplicas funcional de MongoDB 8.2 o posterior, o un clúster, implementado de una de las siguientes maneras:
Dentro de un clúster de Kubernetes utilizando el Operador de Kubernetes
Fuera de un clúster de Kubernetes
Instancia de Cloud Manager u Ops Manager
Antes de comenzar, tenga en cuenta lo siguiente:
Debes tener un
StorageClassfuncional para la creación de volúmenes persistentes en el clúster de Kubernetes. Sin esto, suPersistentVolumeClaimspodría permanecer pendiente y MongoDB podría no tener almacenamiento duradero.Debe tener una red de clúster correctamente configurada. Servicios como ClusterIP, NodePort o LoadBalancer deben poder enrutar el tráfico. Si los clientes externos necesitan acceso, configura un Ingress o un balanceador de carga.
Los nodos de base de datos y búsqueda deben contar con suficiente CPU, memoria y espacio en disco, ya que las cargas de trabajo de la base de datos MongoDB, así como las de búsqueda y búsqueda vectorial, consumen muchos recursos. MongoDB recomienda usar solicitudes y límites en las especificaciones de su Pod para evitar la expulsión o la limitación de recursos.
Su versión de Kubernetes debe ser compatible con el operador de MongoDB o el Helm gráfica que desee utilizar. Algunos CRD o API difieren según la versión. Para obtener más información, consulta Controladores de MongoDB para compatibilidad con operadores de Kubernetes.
Debe crear los roles y vinculaciones de roles RBAC necesarios para que el Operador de Kubernetes y los procesos que se ejecutan dentro de los Pods puedan gestionar los recursos.
Si deseas varias instancias de
mongot(spec.clusters[].replicasmayor que1), necesitas un balanceador de carga. El operador de Kubernetes puede implementar y gestionar un proxy Envoy automáticamente (spec.clusters[].loadBalancer.managed: {}) o puedes proporcionar tu propio balanceador de carga L7 (spec.clusters[].loadBalancer.unmanaged).Si deseas un clúster sharded con múltiples instancias de
mongot, asegúrate de contar con suficientes recursos en el clúster para el número total de pods en todas las particiones. Cada partición obtiene su propio grupo independiente demongotpods. El equilibrador de carga envía el tráfico al grupomongotcorrecto. Lee el campo TLS SNI en el tráfico entrante para identificar la partición de origen y enruta el tráfico amongotpods que pertenecen a esa partición. Por lo tanto, debe configurar cada partición con un nombre de host de búsqueda distinto.
Tareas de configuración
La siguiente tabla muestra las tareas de configuración que el Operador de Kubernetes realiza automáticamente y las acciones que debe realizar para implementar exitosamente MongoDB Search y búsqueda vectorial en Kubernetes y conectarse a un conjunto de réplicas de MongoDB o a un clúster en Kubernetes o a una implementación externa de MongoDB.
Tarea | (Dentro de Kubernetes) Realizado por | (MongoDB externo) Realizado por |
|---|---|---|
Implementa Ops Manager dentro de Kubernetes | Operador de Kubernetes | Operador de Kubernetes |
Implementa Cloud Manager u Ops Manager fuera de Kubernetes | Tú | Tú |
Implementar un set de réplicas o un clúster de MongoDB | Operador de Kubernetes | Tú |
Crea un recurso personalizado MongoDBSearch | Tú | Tú |
Proporciona una cadena de conexión a la implementación de MongoDB | Operador de Kubernetes | Tú |
Crea configuración de | Operador de Kubernetes | Operador de Kubernetes |
Configura los parámetros necesarios del set de réplicas en cada proceso | Operador de Kubernetes | Tú |
Crea un usuario para | Kubernetes operador y usted aplicando el recurso MongoDBUser | Tú |
Configura el set de réplicas de MongoDB con un usuario que tenga los permisos necesarios para consultar query | Tú | Tú |
Crea índices de búsqueda de MongoDB y Vector Search | Tú | Tú |
Exponga los pods de búsqueda o equilibrador de carga externamente para conectarse desde cada nodo | No es necesario | Tú |
Exponga los pods | No es necesario | Tú |
Configure el balanceador de carga gestionado (cuando | Operador de Kubernetes | Operador de Kubernetes |
Configurar balanceador de carga no gestionado (cuando | Tú | Tú |
Aprovisionar certificados TLS por fragmento (clúster con TLS) | Tú | Tú |
Exponer el balanceador de carga externamente (MongoDB externo + LB gestionado) | No es necesario | Tú |
El siguiente diagrama muestra la arquitectura de implementación de una instancia única de MongoDB Search y búsqueda vectorial con un set de réplicas de MongoDB Enterprise en un clúster de Kubernetes.
El siguiente diagrama muestra los componentes que el Operador de Kubernetes implementa en un clúster de Kubernetes para MongoDB Search y Búsqueda Vectorial con un set de réplicas de MongoDB Enterprise Edition.
Cuando tanto los procesos mongot como mongod se implementan dentro del clúster de Kubernetes, el operador de Kubernetes realiza la configuración de ambos procesos automáticamente. Concretamente, Kubernetes Operador realiza las siguientes operaciones:
Encuentra el MongoDB CR referenciado por MongoDBSearch usando
spec.source.mongodbResourceRef, o mediante una convención de nomenclatura buscando MongoDB CR con el mismo nombre que MongoDBSearch. Para los clústeres, el operador de Kubernetes detecta automáticamente la topología de particiones (nombres de particiones, set de réplicas y routers mongos) a partir del recursoMongoDBde referencia.Genera la configuración
mongoten un archivo YAML y la guarda en un config map llamado<MongoDBSearch.metadata.name>-search-config.El mapa de configuración lo montan los pods de búsqueda y la configuración YAML es utilizada por el proceso de
mongotal iniciar. El YAML generado contiene toda la información sobre cómo conectarse al set de réplicas, configuraciones de TLS y así sucesivamente.Implementa un conjunto con estado de MongoDB Search y Vector Search denominado
<MongoDBSearch.metadata.name>-searchcon requisitos de almacenamiento y recursos configurados según las configuracionesspec.clusters[].persistenceyspec.clusters[].resourceRequirementsdel CR. Para fuentes de clúster fragmentadas, el operador de Kubernetes crea un StatefulSet por cada fragmento. Cada StatefulSet utiliza el patrón de nomenclatura<name>-search-0-<shardName>y contienespec.clusters[].replicaspods, cuyo valor predeterminado1es. El del0patrón de nomenclatura es un índice de clúster reservado.Implementa un solo proxy Envoy Implementación para el clúster de MongoDB si necesita un balanceador de carga (
spec.clusters[].loadBalancer.managed). El proxy de Envoy gestiona el enrutamiento L7, la terminación de mTLS y la fijación de transmisión gRPC entre los pods demongodymongot.Actualiza la configuración de cada proceso
mongodañadiendo las opciones necesariassetParameter, incluyendo los nombres de host y números de puerto de los hostsmongot. Cuando configura un balanceador de carga,mongotHostysearchIndexManagementHostAndPortapuntan al punto de enlace del balanceador de carga en lugar de los podsmongot. Para clústeres segmentados, cada uno de los procesosmongodde la partición recibe el endpoint del balanceador de carga para esa partición.
Debes realizar las siguientes acciones:
Crea un usuario en el set de réplicas utilizando un recurso personalizado
MongoDBUser. Elmongotutiliza las credenciales de este usuario para conectarse al set de réplicas y obtener los datos:El nombre de usuario es arbitrario (los ejemplos usan
search-sync-source-user), pero debe tener el rolsearchCoordinatorestablecido.El nombre de usuario y la contraseña de este usuario se pasan en
MongoDBSearch.spec.source.usernameyMongoDBSearch.spec.source.passwordSecretRefrespectivamente.El secreto de la password puede referirse al mismo secreto que contiene la password del usuario que se utilizó para crear la especificación
MongoDBUser(enMongoDBUser.spec.source.passwordSecretKeyRef).
Configura y aplica el recurso personalizado MongoDBSearch.
Para obtener más información sobre la configuración de CR para el proceso mongot, consulta Configuraciones de MongoDB Search y búsqueda vectorial.
El siguiente diagrama muestra la arquitectura de implementación de MongoDB Search y búsqueda vectorial en un clúster de Kubernetes utilizando un set de réplicas externo de la Edición Empresarial de MongoDB.
El siguiente diagrama muestra los componentes que el operador de Kubernetes implementa en un clúster de Kubernetes para MongoDB Search y búsqueda vectorial.
Para usar MongoDB Search y Vector Search cuando su implementación de MongoDB se encuentra fuera de Kubernetes, implemente mongot usando el Operador de Kubernetes y realice algunos pasos manualmente. El Operador de Kubernetes se encarga de la configuración de los pods de búsqueda. Sin embargo, cuando la implementación de MongoDB está fuera de Kubernetes, debe reconfigurar sus nodos de MongoDB y la red.
Eres responsable de las siguientes configuraciones manuales:
Configuración de set de réplicas externas
Configura el siguiente parámetro mediante
setParameteren cada procesomongoddel set de réplicas externo. Al configurar, reemplaza<search-service-hostname>:27028con el nombre de dominio resolvible y el puerto reales de tu servicio MongoDBSearch.setParameter: mongotHost: "<search-service-hostname>:27028" searchIndexManagementHostAndPort: "<search-service-hostname>:27028" skipAuthenticationToSearchIndexManagementServer: false searchTLSMode: "disabled" # or "requireTLS" for TLS deployments useGrpcForSearch: true Para una única instancia
mongot(sin equilibrador de carga),mongotHostapunta directamente al nombre de host del serviciomongot(<name>-search-0-svc:27028).Para múltiples instancias de
mongotcon un balanceador de carga,mongotHostapunta al endpoint del balanceador de carga en su lugar.Para balanceadores de carga gestionados, el operador de Kubernetes configura el
mongotHostautomáticamente usandospec.source.mongodbResourceRef.Para implementaciones externas de MongoDB, tienes que establecer
mongotHosten el endpoint del balanceador de carga que especificaste enspec.clusters[].loadBalancer.managed.externalHostnameospec.clusters[].loadBalancer.unmanaged.endpoint.
Crea un usuario en el set de réplicas externo para el proceso de sincronización de búsqueda. Este usuario debe tener el rol
searchCoordinator.- userName: "search-sync-source" password: "<your-search-sync-password>" database: "admin" roles: - role: "searchCoordinator" db: "admin"
Configuración externa de clúster fragmentado
Importante
En una implementación estándar de clúster fragmentado de MongoDB, los clientes se conectan únicamente a los mongos enrutadores y nunca directamente a los sets de réplicas de la partición. Sin embargo, cuando implementa mongot, los procesos mongot en cada grupo de particiones se conectan tanto a los enrutadores mongos como a todos los procesos mongod en esa partición. Por lo tanto, se debe exponer directamente el set de réplicas de cada partición a mongot procesos. Asegúrese de que su red y las reglas del firewall permitan la conectividad directa desde la clúster de Kubernetes a cada instancia de mongod de la partición, no solo a los routers mongos.
Los valores de shardName que especifiques en spec.source.external.shardedCluster.shards deben seguir las reglas de nomenclatura de Kubernetes:
Contenga solo caracteres alfanuméricos en minúsculas,
-o..Empieza con un carácter alfabético y termina con un carácter alfanumérico.
No contengan guiones bajos. Si los nombres de las particiones de MongoDB utilizan guiones bajos, sustitúyelos por guiones.
La longitud combinada de
MongoDBSearch.metadata.nameyshardNamedebe ser inferior a 50 caracteres.
El shardName no tiene que coincidir con el nombre exacto de la partición en MongoDB. El Operador de Kubernetes lo utiliza solo para nombrar recursos de Kubernetes.
Cuando conectes MongoDBSearch a un clúster fragmentado externo, debes:
Configura
spec.source.external.shardedClusteren el MongoDBSearch CR con los hosts de routermongosy los hosts de conjuntos de réplicas por partición.Establezca los parámetros
mongotHostysearchIndexManagementHostAndPorten los procesosmongodde cada partición. Apunta cada partición a su propio grupo demongot(o a su propio endpoint de balanceador de carga si se usan varias instancias demongot).Asegura la conectividad de red bidireccional entre:
Cada uno de los
mongodnodos de la partición y los correspondientesmongotpods (o balanceador de carga).Los pods de
mongoty los routers demongos(para enrutamiento de query).Los pods
mongoty los nodosmongodde cada partición (para la sincronización de datos).
Si utilizas un balanceador de carga gestionado con un clúster particionado externo, especifica spec.clusters[].loadBalancer.managed.externalHostname con un marcador {shardName} (por ejemplo, {shardName}.search-lb.example.com). Expón el servicio Envoy externamente para que los mongod nodos de cada partición puedan acceder a él utilizando un nombre de host único para esa partición. El balanceador de carga lee el campo TLS SNI de las conexiones entrantes para determinar de qué partición se origina el tráfico y lo envía a los pods mongot que pertenecen a esa partición. Este enrutamiento basado en SNIes el único mecanismo que el balanceador de carga utiliza para distinguir el tráfico entre particiones, por lo cual cada partición debe conectarse a través de un nombre de host diferente.
Configuración de Kubernetes
Configura y aplica el CR de MongoDBSearch con
spec.source.externalapuntando a tus hosts externos de MongoDB.Crea un secreto de Kubernetes para la contraseña del usuario de sincronización de búsqueda.
apiVersion: v1 kind: Secret metadata: name: search-sync-source-password stringData: password: "your-search-sync-password" Configura la red y DNS para asegurar la conectividad bidireccional entre tu MongoDB externo y los pods de búsqueda. Tu entorno externo de MongoDB debe poder resolver el nombre de host de tu servicio de búsqueda (
<search-service-hostname>).
Para obtener más información sobre los ajustes de CR del proceso mongot para conectarse a un proceso mongod externo, consulte Configuración de MongoDB Search and búsqueda vectorial.
Seguridad
La siguiente imagen ilustra la configuración de seguridad para el mongot proceso. Si la implementación de MongoDB se encuentra dentro del clúster de Kubernetes, el operador de Kubernetes configura automáticamente la autenticación mediante archivo de clave para MongoDB Search y Vector Search. Si la implementación de MongoDB es externa, debe crear un secreto de Kubernetes que contenga la credencial del archivo de clave del conjunto de réplicas y referenciarlo en el CR de MongoDBSearch.
Autenticación
El proceso mongot autentica las conexiones mongod mediante mTLS. Al habilitar TLS, el proceso mongot utiliza el certificado TLS de la implementación de MongoDB como certificado de cliente para la autenticación. Este certificado se verifica con el certificado de CA configurado en mongot. Para que la autenticación funcione correctamente, debe configurar tanto mongot como mongod con TLS habilitado.
Cuando se configura para indexar un recurso de MongoDB dentro del mismo clúster de Kubernetes, el operador de Kubernetes propaga automáticamente el certificado mongod CA a mongot y habilita mTLS para las conexiones de consulta de búsqueda si ambos recursos MongoDB y MongoDBSearch están configurados para TLS. Si el conjunto de réplicas de MongoDB se implementa fuera de Kubernetes, debes crear un secreto de Kubernetes que contenga el certificado de la CA del conjunto de réplicas y referenciarlo en el campo MongoDBSearch.spec.source.external.tls.ca para habilitar la autenticación mTLS para las solicitudes de búsqueda.
Seguridad de capa de transporte (TLS)
MongoDBSearch puede proteger los datos y las credenciales en tránsito usando TLS. Para los comandos de gestión de índices y consultas de búsqueda, establece el campo spec.security.tls y proporciona un certificado TLS. Puedes establecer este campo como un objeto vacío ({}) para activar TLS con la configuración por defecto.
Obsoleto desde la versión 1.8.0. spec.security.tls.certificateKeySecretRef está obsoleto. Para implementaciones de conjuntos de réplicas, el operador de Kubernetes aún admite certificateKeySecretRef, pero se recomienda migrar a spec.security.tls.certsSecretPrefix. En implementaciones de clúster compartido, no se puede utilizar certificateKeySecretRef porque el Operador de Kubernetes lee un secreto de certificado de servidor mongot distinto para cada partición.
spec.security.tls.certsSecretPrefix es un campo opcional. Cuando lo especificas, el Operador de Kubernetes antepone <certsSecretPrefix>- a todos los nombres de certificados secretos que lee. El operador de Kubernetes lee los siguientes secretos de certificados:
mongot Certificados
Topología de clústeres | mongot Certificado |
|---|---|
Set de réplicas |
|
Clúster fragmentado |
|
Certificados de Balanceador de Carga
Si configuras spec.clusters[].loadBalancer.managed, el certificado de cliente de balanceador de carga es [<certsSecretPrefix>-]<name>-search-lb-0-client-cert. La siguiente tabla muestra los certificados del servidor del balanceador de carga:
Topología de clústeres | Certificado |
|---|---|
Set de réplicas |
|
Clúster fragmentado |
|
El certificado TLS debe ser emitido y firmado por la misma CA que emitió el certificado CA que utiliza el set de réplicas de MongoDB.
Cuando tanto MongoDBSearch como MongoDB son implementados por el Operador de Kubernetes, la configuración subyacente de mongot y mongod es gestionada en gran medida por el propio Operador de Kubernetes. Si implementa el set de réplicas de MongoDB fuera del clúster de Kubernetes:
.spec.source.external.tlsel campo debe completarse con un Secret de Kubernetes que contenga el mismo certificado CA que usaste para configurar elmongod.searchTLSModeEl parámetro debe configurarse enrequireTLSen la configuración demongod.
Load balanceador mTLS
Sin un balanceador de carga, mongod se conecta directamente a mongot usando mTLS. El mongod presenta su propio certificado de cliente, y mongot lo valida contra una CA confiable.
Si configura un balanceador de carga gestionado (spec.clusters[].loadBalancer.managed), el proxy de Envoy finaliza la conexión mTLS de mongod y establece una nueva conexión mTLS con mongot. Como el balanceador de carga termina y restablece la conexión, utiliza su propio certificado de cliente al conectarse a mongot, y no el certificado original de mongod. La mongot CA debe confiar en la autoridad certificadora que emitió el certificado de cliente del balanceador de carga. El Kubernetes operador gestiona automáticamente la configuración de TLS de Envoy. Requiere los siguientes certificados:
Certificado de servidor para el proxy Envoy, al que se conecta
mongod. El balanceador de carga utiliza este certificado para terminar la conexión entrante de mTLS.Certificado cliente para el proxy Envoy, que el balanceador de carga presenta a
mongotal establecer la conexión mTLS upstream.
Proporcione estos certificados como secretos de Kubernetes siguiendo la convención de nombres que define spec.security.tls.certsSecretPrefix. Consulta Configuraciones de MongoDB Search y búsqueda vectorial para el patrón completo de nomenclatura.
Datos de diagnóstico
Cada mongot pod escribe continuamente archivos FTDC en /mongot/data/diagnostic.data/ dentro del pod. FTDC es un flujo de diagnóstico binario que captura mongot el estado interno detallado de y es el artefacto principal que usa el soporte de MongoDB para diagnosticar problemas de búsqueda. FTDC está habilitado de forma predeterminada. Para saber cómo copiar archivos FTDC para un caso de soporte, consulte Solución de problemas de implementación de.mongot
El operador de Kubernetes monta un PersistentVolumeClaim en cada mongot pod en /mongot/data usando un volumeClaimTemplate en el StatefulSet de búsqueda, y mongot escribe sus archivos FTDC en /mongot/data/diagnostic.data/ en ese volumen. Debido a que los datos residen en PersistentVolumeClaim un, sobreviven a los reinicios y reprogramaciones de pods: cuando el StatefulSet reemplaza un pod, vuelve a adjuntar el PersistentVolumeClaim mismo. Este volumen se configura con el ajuste spec.clusters[].persistence en el recurso MongoDBSearch.