Implemente o MongoDB Search e o Vector Search

Você pode implantar o MongoDB Search e a pesquisa vetorial em seu cluster Kubernetes para criar experiências de pesquisa poderosas diretamente em seus aplicativos. Usando o MongoDB Search e a pesquisa vetorial, você pode criar recursos de pesquisa de texto tradicionais e de pesquisa vetorial com tecnologia de IA que sincronizam automaticamente com um banco de dados MongoDB no local. Essa abordagem elimina a necessidade de manter sistemas separados em sincronização, ao mesmo tempo em que fornece recursos de pesquisa avançados. Para aprender mais, consulte:

Para habilitar as funcionalidades de pesquisa, como pesquisa de texto completo e pesquisa semântica em implantações locais, você deve implantar o processo MongoDB Search e pesquisa vetorial (mongot) e conectá-lo à sua implantação de banco de dados MongoDB (mongod). A implantação do mongot é opcional e é necessária somente se você planeja utilizar os recursos de pesquisa que ela oferece.

O processo do banco de dados MongoDB (mongod) atua como proxy para todas as query de pesquisa para mongot. O mongod encaminha a query para mongot, que a processa. O mongot retorna os resultados da query para o mongod, que então encaminha os resultados para você. Você nunca interage diretamente com o mongot.

Cada processo do mongot tem seu próprio volume persistente que não é compartilhado com o banco de dados ou outros nós de pesquisa. O armazenamento é usado para manter índices que são criados a partir dos dados obtidos continuamente do banco de dados. As definições do índice (metadados) são armazenadas no próprio banco de dados .

O mongot executa as seguintes ações:

Gerencia o índice.

O mongot é responsável por atualizar as definições de índice no banco de dados.
Obtém os dados do banco de dados.

Os nós do mongot estabelecem conexões permanentes com o banco de dados em tempo real.
Processa queries de pesquisa.

When mongod receives a $search, $searchMeta, or $vectorSearch query, it directs the query to one of the mongot nodes. The mongot that receives the query processes the query, aggregates the data, and returns the results to mongod, which it forwards to the user.

Os componentes do mongot são fortemente associados a um único conjunto de réplicas MongoDB e não podem ser compartilhados entre vários bancos de dados ou conjuntos de réplicas. Para uma implantação de conjunto de réplicas, um grupo de nós de pesquisa dedicados atende ao conjunto de réplicas. Para um cluster fragmentado, cada fragmento mantém seu próprio grupo independente de mongot nós. Os fragmentos não compartilham instâncias mongot.

A conectividade de rede entre mongot e mongod vai em ambas as direções:

mongot estabelece conexão com o conjunto de réplicas para obter os dados usados para construir índices e executar query.
mongod conecta-se ao mongot para encaminhar operações relacionadas à pesquisa, como gerenciamento de índice e consulta de dados.

O campo spec.clusters[].replicas controla quantas instâncias do mongot o Operador Kubernetes implanta. Para uma origem do conjunto de réplicas, o spec.clusters[].replicas define o número total de pods do mongot. Para uma origem de cluster fragmentado, spec.clusters[].replicas define o número de mongot pods por fragmento.

Se você definir spec.clusters[].replicas como um valor maior que 1, deverá colocar um balanceador de carga L7 entre mongod e os pods mongot. O processo mongod abre uma única conexão TCP de longa duração para mongot, portanto, um balanceador de carga L4 não pode distribuir queries em várias instâncias mongot — todo o tráfego flui por essa conexão. Um balanceador de carga L7 entende HTTP/2 e gRPC, o que lhe permite distribuir fluxos gRPC individuais em pods mongot enquanto fixa cada fluxo em um único mongot durante o cursor de query.

Sistema de pesquisa Vector Search do MongoDB

A arquitetura de implantação de pesquisa difere pouco com ou sem o Kubernetes Operator. O Kubernetes operador simplifica as etapas necessárias para implantar nós de pesquisa totalmente funcionais, especialmente quando o banco de dados também é gerenciado pelo Kubernetes operador.

Para implantar, você aplica o MongoDBSearch Custom recurso (CR), que o Operador do Kubernetes pega e começa a distribuir mongot pods e solicita armazenamento persistente especificado no spec. O MongoDB Search e a pesquisa vetorial implementados por meio do Kubernetes operador podem direcionar um conjunto de réplicas do MongoDB ou um cluster implantado pelo Kubernetes operador dentro do mesmo cluster do Kubernetes, ou uma implantação externa completamente independente do MongoDB (conjunto de réplicas ou cluster). Para aprender como implantar e configurar o mongot para usar:

Um conjunto de réplicas do MongoDB no Kubernetes, consulte Instalar e usar com o MongoDB Community Edition ou Instalar e usar a pesquisa com o MongoDB Enterprise Edition
Para definir um conjunto de réplicas do MongoDB externo, consulte Instalar e usar o MongoDB Search e o Vector Search com o MongoDB Enterprise Edition.

Pré-requisitos

Para usar o MongoDB Search e a pesquisa vetorial em seu:

A implantação da MongoDB Community , você deve ter um MongoDB 8.2 totalmente funcional ou posterior conjunto de réplicas ou cluster fragmentado implantado dentro de um cluster Kubernetes usando o Operador Kubernetes.
A implantação do MongoDB Enterprise , você deve ter um conjunto de réplicas totalmente funcional do MongoDB 8.2 ou posterior ou um cluster fragmentado implantado de uma das seguintes maneiras:
- Dentro de um cluster Kubernetes usando o Operador Kubernetes
- Fora de um cluster Kubernetes
Instância do Cloud Manager ou do Ops Manager

Antes de começar, considere o seguinte:

Você deve ter um StorageClass funcional para a criação de volumes persistentes no cluster Kubernetes. Sem isso, seu PersistentVolumeClaims pode permanecer pendente e o MongoDB pode não ter armazenamento durável.
Você deve ter uma rede de cluster configurada corretamente. Serviços como ClusterIP, NodePort ou LoadBalancer devem ser capazes de rotear o tráfego. Se os clientes externos precisarem de acesso, configure um ingresso ou um balanceador de carga.
Seu banco de dados e os nós de pesquisa devem ter CPU, memória e espaço em disco suficientes alocados porque as cargas de trabalho do banco de dados MongoDB, da pesquisa MongoDB e da pesquisa vetorial fazem uso intensivo de recursos. O MongoDB recomenda usar solicitações e limites nas especificações do Pod para evitar despejo ou limitação.
Sua versão do Kubernetes deve ser suportada pelo operador MongoDB ou gráfico Helm que você deseja usar. Alguns CRDs ou APIs diferem entre versões. Para saber mais, veja Controladores MongoDB para Compatibilidade do operador Kubernetes.
Você deve criar quaisquer funções e vinculações de funções RBAC necessárias para que o Kubernetes operador e os processos em execução nos Pods possam gerenciar recursos.
Se você quiser várias instâncias mongot (spec.clusters[].replicas maiores que 1), precisará de um balanceador de carga. O Operador Kubernetes pode implantar e gerenciar um proxy Envoy automaticamente (spec.clusters[].loadBalancer.managed: {}) ou você pode fornecer seu próprio balanceador de carga L7 (spec.clusters[].loadBalancer.unmanaged).
Se você quiser um cluster com várias instâncias mongot, certifique-se de ter recursos de cluster suficientes para o número total de pods em todos os shards. Cada shard recebe seu próprio grupo independente de mongot pods. O balanceador de carga direciona o tráfego para o grupo mongot correto. Ele lê o campo TLS SNI no tráfego de entrada para identificar o shard de origem e roteia o tráfego para mongot pods que pertencem a esse shard. Portanto, você deve configurar cada shard com um nome de host de pesquisa distinto.

Tarefas de configuração

A tabela a seguir mostra as tarefas de configuração que o Kubernetes Operator executa automaticamente e as ações que você deve executar para implantar com êxito o MongoDB Search e a pesquisa vetorial no Kubernetes e conectar-se a um conjunto de réplicas do MongoDB ou cluster no Kubernetes ou a uma implantação externa do MongoDB.

Tarefa	(Dentro do Kubernetes) Executado por	(MongoDB externo) Realizado por
Deploy Ops Manager inside Kubernetes	Kubernetes Operator	Kubernetes Operator
Implemente o Cloud Manager ou o Ops Manager fora do Kubernetes	você	você
Distribua o conjunto de réplicas do MongoDB ou o cluster fragmentado	Kubernetes Operator	você
Criar recurso personalizado do MongoDBSearch	você	você
Fornecer string de conexão para a implantação do MongoDB	Kubernetes Operator	você
Criar YAMLde configuração `mongot`	Kubernetes Operator	Kubernetes Operator
Definir os parâmetros necessários do conjunto de réplicas em cada processo `mongod`	Kubernetes Operator	você
Criar usuário para `mongot` com função `searchCoordinator`	Kubernetes Operator e você aplicando o recurso MongoDBUser	você
Configurar conjunto de réplicas do MongoDB com um usuário que tenha as permissões necessárias para consultar a pesquisa	você	você
Criar índices de MongoDB Search e Vector Search	você	você
Exponha pods de pesquisa ou balanceador de carga externamente para conectar a partir de cada nó `mongod`	Não necessário	você
Exponha `mongod` pods externamente para conexão a partir de `mongot` nós	Não necessário	você
Configurar balanceador de carga gerenciado (quando `spec.clusters[].replicas` é maior que `1`)	Kubernetes Operator	Kubernetes Operator
Configurar balanceador de carga não gerenciado (quando `spec.clusters[].replicas` é maior que `1`)	você	você
Provisionar certificados TLS por fragmento (clusters fragmentados com TLS)	você	você
Expor o balanceador de carga externamente ( MongoDB externo + LS gerenciado)	Não necessário	você

O diagrama a seguir mostra a arquitetura de implementação de uma única instância do MongoDB Search e Vector Search com um conjunto de réplicas do MongoDB Enterprise em um cluster Kubernetes.

Diagrama mostrando a arquitetura de implementação do MongoDB Search e Vector Search com MongoDB Enterprise em um cluster Kubernetes.

clique para ampliar

O diagrama a seguir mostra os componentes que o Operador Kubernetes implementa em um cluster do Kubernetes para MongoDB Search e Vector Search com um conjunto de réplicas MongoDB Enterprise Edition.

Diagrama mostrando os componentes incluídos no conjunto de réplicas do MongoDB Enterprise com o sistema MongoDB Search e Vector Search usando o operador .

clique para ampliar

Quando os processos mongot e mongod são implantados dentro do cluster Kubernetes, o Operador Kubernetes executa a configuração para ambos os processos automaticamente. Especificamente, o Operador Kubernetes executa as seguintes operações:

Encontra o MongoDB CR referenciado por MongoDBSearch usando spec.source.mongodbResourceRef, ou por uma convenção de nomenclatura, procurando por MongoDB CR com o mesmo nome que MongoDBSearch. Para clusters sharded, o operador Kubernetes descobre automaticamente a topologia de shard (nomes de shard, conjunto de réplicas e roteadores mongos) do recurso MongoDB referenciado.
Gera a configuração mongot em um arquivo YAML e a salva em um mapa de configuração chamado <MongoDBSearch.metadata.name>-search-config.

O Config map é montado pelos search pods e a configuração YAML é usada pelo processo de mongot na inicialização. O YAML gerado contém todas as informações sobre como se conectar ao conjunto de réplicas, configurações TLS e assim por diante.
Implementa o conjunto stateful do MongoDB Search e pesquisa vetorial denominado <MongoDBSearch.metadata.name>-search com os requisitos de armazenamento e recursos configurados de acordo com as configurações spec.clusters[].persistence e spec.clusters[].resourceRequirements na CR. Para fontes de cluster sharded, o operador Kubernetes cria um StatefulSet por shard. Cada StatefulSet usa o padrão de nomenclatura <name>-search-0-<shardName> e contém spec.clusters[].replicas pods, cujo padrão é 1. O 0 no padrão de nomenclatura é o índice do cluster, que é 0 em implantações de cluster único. Em implantações de vários clusters, o operador Kubernetes usa o valor spec.clusters[].index de cada cluster nos nomes StatefulSet desse cluster.
Implanta uma única implantação de proxy Envoy para o cluster MongoDB se você precisar de um balanceador de carga (spec.clusters[].loadBalancer.managed). O proxy Envoy lida com o roteamento L7, o encerramento do mTLS e a fixação de fluxo gRPC entre os pods mongod e mongot.
Atualiza a configuração de cada processo mongod adicionando as opções setParameter necessárias, incluindo os nomes de host e números de porta dos hosts mongot. Ao configurar um balanceador de carga, mongotHost e searchIndexManagementHostAndPort ponto para o ponto de extremidade do balanceador de carga em vez dos pods mongot. Para clusters fragmentados, os processos mongod de cada fragmento recebem o ponto de extremidade do balanceador de carga para esse fragmento.

Você deve executar as seguintes ações:

Crie um usuário no conjunto de réplicas utilizando um recurso personalizado do MongoDBUser. O mongot utiliza as credenciais deste usuário para conectar ao conjunto de réplica para obter os dados:
- O nome de usuário é arbitrário (os exemplos usam search-sync-source-user), mas ele deve ter o conjunto de funções searchCoordinator.
- O nome de usuário e a senha deste usuário são passados em MongoDBSearch.spec.source.username e MongoDBSearch.spec.source.passwordSecretRef, respectivamente.
  
  O segredo da senha pode se referir ao mesmo segredo contendo a senha do usuário que foi usada para criar a especificação MongoDBUser (em MongoDBUser.spec.source.passwordSecretKeyRef).
Configure e aplicar o recurso personalizado MongoDBSearch.

Para saber mais sobre as configurações de CR para o processo mongot, consulte Configurações de pesquisa do MongoDB e pesquisa vetorial.

O diagrama a seguir mostra a arquitetura de implementação do MongoDB Search e do Vector Search em um cluster Kubernetes usando um conjunto de réplicas externo do MongoDB Enterprise Edition.

clique para ampliar

O diagrama a seguir mostra os componentes que o Operador Kubernetes implementa em um cluster Kubernetes para MongoDB Search e Vector Search.

Diagrama mostrando os componentes incluídos na implementação do MongoDB Enterprise Replica Set com MongoDB Search usando o operador.

clique para ampliar

Para usar o MongoDB Search e a pesquisa vetorial quando sua implantação do MongoDB estiver fora do Kubernetes, implantar o mongot usando o operador do Kubernetes e execute algumas etapas manualmente. O operador do Kubernetes lida com a configuração dos pods de pesquisa. No entanto, quando a implantação do MongoDB está fora do Kubernetes, você deve reconfigurar seus nós do MongoDB e a rede.

Você é responsável pelas seguintes configurações manuais:

Configuração externa do conjunto de réplicas

Configure o parâmetro a seguir usando setParameter em cada processo mongod em seu conjunto de réplicas externa. Ao configurar, substitua <search-service-hostname>:27028 pelo nome do host real resolvível e pela porta do serviço MongoDBSearch.

setParameter:
  mongotHost: "<search-service-hostname>:27028"
  searchIndexManagementHostAndPort: "<search-service-hostname>:27028"
  skipAuthenticationToSearchIndexManagementServer: false
  searchTLSMode: "disabled"  # or "requireTLS" for TLS deployments
  useGrpcForSearch: true

Para uma única instância mongot (sem balanceador de carga), mongotHost aponta diretamente para o nome do host de serviço mongot (<name>-search-0-svc:27028).
Para várias instâncias do mongot com um balanceador de carga, mongotHost aponta para o ponto de extremidade do balanceador de carga.
Para balanceadores de carga gerenciados, o Operador Kubernetes configura o mongotHost automaticamente utilizando spec.source.mongodbResourceRef.
Para implantações externas do MongoDB, você deve definir mongotHost como o ponto de extremidade do balanceador de carga especificado em spec.clusters[].loadBalancer.managed.externalHostname ou spec.clusters[].loadBalancer.unmanaged.endpoint.

Crie um usuário no conjunto de réplicas externa para o processo de sincronização de pesquisa. Este usuário deve ter a função searchCoordinator.
- userName: "search-sync-source" password: "<your-search-sync-password>" database: "admin" roles: - role: "searchCoordinator" db: "admin"

Configuração de cluster fragmentado externo

Importante

Em uma implantação de cluster fragmentado MongoDB padrão, os clientes se conectam somente a roteadores mongos e nunca diretamente a conjuntos de réplicas de fragmentos. No entanto, quando você implanta mongot, os processos mongot em cada grupo de fragmentos se conectam aos roteadores mongos e a todos os processos mongod nesse fragmento. Portanto, você deve expor o conjunto de réplicas de cada fragmento diretamente aos processos mongot. Certifique-se de que suas regras de rede e firewall permitam a conectividade direta do cluster Kubernetes para as instâncias mongod de cada fragmento, não apenas para os roteadores mongos.

Os valores shardName especificados em spec.source.external.shardedCluster.shards devem seguir as regras de nomenclatura do Kubernetes:

Conter apenas caracteres alfanuméricos minúsculos, - ou ..
Comece com um caractere alfabético e termine com um caractere alfanumérico.
Não contém sublinhados. Se os nomes dos fragmentos do MongoDB usarem sublinhados, substitua-os por traços.
O comprimento combinado de MongoDBSearch.metadata.name e shardName deve ter menos de 50 caracteres.

O shardName não precisa corresponder ao nome exato do fragmento no MongoDB. O Operador Kubernetes utiliza-o apenas para nomear recursos Kubernetes.

Ao conectar o MongoDBSearch a um cluster fragmentado externo, você deve:

Configurar spec.source.external.shardedCluster no MongoDBSearch CR com os hospedar do roteador mongos e hospedar do conjunto de réplicas por shard.
Defina os parâmetros mongotHost e searchIndexManagementHostAndPort nos processos mongod de cada fragmento. Aponte cada fragmento para seu próprio grupo mongot (ou para seu próprio ponto de extremidade do balanceador de carga se você usar várias instâncias mongot).
Garantir a conectividade de rede bidirecional entre:
- Os nós mongod de cada fragmento e os pods mongot correspondentes (ou balanceador de carga).
- Os pods mongot e os roteadores mongos (para roteamento de queries).
- Os mongot pods e os nós mongod de cada fragmento (para sincronização de dados).

Se você usar um balanceador de carga gerenciado com um cluster sharded externo, especifique spec.clusters[].loadBalancer.managed.externalHostname com um espaço reservado {shardName} (por exemplo, {shardName}.search-lb.example.com). Exponha o serviço Envoy externamente para que os mongod nós de cada shard possam alcançá-lo usando um nome de host exclusivo para esse shard. O balanceador de carga lê o campo TLS SNI das conexões de entrada para determinar de qual shard o tráfego se origina e o envia para os mongot pods que pertencem a esse shard. Esse roteamento baseado em SNIé o único mecanismo que o balanceador de carga usa para distinguir o tráfego entre os shards, e é por isso que cada shard deve se conectar por meio de um nome de host diferente.

Configuração do Kubernetes

Configure e aplique o MongoDBSearch CR com spec.source.external apontando para seus hosts externos do MongoDB.
Crie um segredo do Kubernetes para a senha do usuário de sincronização de pesquisa.
apiVersion: v1 kind: Secret metadata: name: search-sync-source-password stringData: password: "your-search-sync-password"
Configure a rede e o DNS para garantir conectividade bidirecional entre seu MongoDB externo e os pods de pesquisa. Seu ambiente MongoDB externo deve ser capaz de resolver o nome do host do seu serviço de pesquisa (<search-service-hostname>).

Para aprender mais sobre as configurações de CR para o processo mongot para se conectar a um processo mongod externo, consulte MongoDB Search and pesquisa vetorial Settings.

Segurança

A imagem a seguir ilustra a configuração de segurança para o processo mongot. Se a implantação do MongoDB estiver dentro do cluster Kubernetes, o operador Kubernetes configura automaticamente a autenticação de arquivo de chave para MongoDB Search e pesquisa vetorial. Se a implantação do MongoDB for externa, você deve criar um secret do Kubernetes contendo as credenciais do arquivo de chave do conjunto de réplicas e referenciá-lo no MongoDBSearch CR.

clique para ampliar

Autenticação

O processo mongot autentica as conexões mongod usando mTLS. Quando você habilita o TLS, o processo mongot usa o certificado TLS da implantação do MongoDB como o certificado do cliente para autenticação. Este certificado é verificado em relação ao certificado CA com o qual mongot está configurado. Para que a autenticação funcione corretamente, você deve configurar mongot e mongod com o TLS habilitado.

Quando configurado para indexar um recurso MongoDB no mesmo cluster do Kubernetes, o operador do Kubernetes propaga automaticamente o certificado CA do mongod para mongot e habilita o mTLS para conexões de query de pesquisa se os recursos do MongoDB e MongoDBSearch estiverem configurados para TLS. Se o conjunto de réplicas do MongoDB for implantado fora do Kubernetes, você deverá criar um segredo do Kubernetes contendo o certificado CA do conjunto de réplicas e referenciá-lo no campo MongoDBSearch.spec.source.external.tls.ca para habilitar a autenticação mTLS para solicitações de query de pesquisa.

Segurança da camada de transporte

O MongoDBSearch pode proteger dados e credenciais em trânsito usando TLS. Para comandos de gerenciamento de índice e query de pesquisa, defina o campo spec.security.tls e forneça um certificado TLS. Você pode definir este campo para um objeto vazio ({}) para habilitar TLS com as configurações padrão.

Descontinuado desde a versão 1.8.0: spec.security.tls.certificateKeySecretRef é descontinuado. Para implantações de conjunto de réplicas, o operador do Kubernetes ainda oferece suporte a certificateKeySecretRef, mas você deve migrar para spec.security.tls.certsSecretPrefix. Para implantações de cluster sharded, não é possível usar certificateKeySecretRef porque o operador Kubernetes lê um segredo de certificado de servidor mongot separado para cada shard.

spec.security.tls.certsSecretPrefix é um campo opcional. Quando você o especifica, o Kubernetes Operator acrescenta <certsSecretPrefix>- a todos os nomes secretos de certificado que lê. O Operador do Kubernetes lê os seguintes segredos de certificado:

`mongot` Certificados

Topologia de cluster	`mongot` Certificado
réplicaSet	`[<certsSecretPrefix>-]<name>-search-cert`
cluster fragmentado	`[<certsSecretPrefix>-]<name>-search-0-<shardName>-cert` (per shard)

Certificados de balanceador de carga

Se você definir spec.clusters[].loadBalancer.managed, o certificado do cliente do balanceador de carga será [<certsSecretPrefix>-]<name>-search-lb-0-client-cert. A tabela a seguir mostra os certificados de servidor do balanceador de carga:

Topologia de cluster	Certificado
réplicaSet	`[<certsSecretPrefix>-]<name>-search-lb-0-cert`
cluster fragmentado	`[<certsSecretPrefix>-]<name>-search-lb-0-<shardName>-cert`

O certificado TLS deve ser emitido e assinado pela mesma CA que emitiu o certificado CA que o conjunto de réplicas MongoDB utiliza.

Quando MongoDBSearch e MongoDB são implantados pelo Operador Kubernetes, a configuração subjacente do mongot e mongod é em grande parte manipulada pelo próprio Operador Kubernetes. Se você implantar o conjunto de réplicas do MongoDB fora do cluster do Kubernetes:

.spec.source.external.tls o campo deve ser preenchido com um secret do Kubernetes contendo o mesmo certificado CA que você usou para configurar o mongod.
searchTLSMode O parâmetro deve ser definido como requireTLS na configuração mongod.

Balanceador de carga mTLS

Sem um balanceador de carga, o mongod conecta diretamente ao mongot utilizando mTLS. O mongod apresenta seu próprio certificado de cliente e o mongot o valida em relação a uma CA confiável.

Se você configurar um balanceador de carga gerenciado (spec.clusters[].loadBalancer.managed), o proxy Envoy encerra a conexão mTLS do mongod e estabelece uma nova conexão mTLS para o mongot. Como o balanceador de carga encerra e restabelece a conexão, ele usa seu próprio certificado de cliente ao se conectar ao mongot, não ao certificado mongod original. A CA mongot deve confiar na autoridade de certificação que emitiu o certificado de cliente do balanceador de carga. O Kubernetes Operator gerencia a configuração do Envoy TLS automaticamente. Exige os seguintes certificados:

Certificado de servidor para o proxy Envoy, ao qual o mongod se conecta. O balanceador de carga usa esse certificado para encerrar a conexão mTLS de entrada.
Certificado do cliente para o proxy Envoy, que o balanceador de carga apresenta ao mongot ao estabelecer a conexão mTLS upstream.

Provisione estes certificados como Segredos Kubernetes seguindo a convenção de nomenclatura que o spec.security.tls.certsSecretPrefix define. Consulte Configurações de pesquisa do MongoDB e pesquisa vetorial para obter o padrão de nomenclatura completo.

Dados de diagnóstico

Cada pod mongot grava continuamente arquivos FTDC em /mongot/data/diagnostic.data/ dentro do pod. FTDC é um fluxo de diagnóstico binário que captura o estado interno detalhado do mongot e é o artefato primário que o Suporte do MongoDB usa para diagnosticar problemas de pesquisa. O FTDC está habilitado por padrão. Para aprender a copiar arquivos FTDC para um caso de suporte, consulte Solucionar problemas de implantação mongot.

O operador Kubernetes monta um PersistentVolumeClaim em cada pod mongot em /mongot/data usando um volumeClaimTemplate no StatefulSet de pesquisa, e mongot grava seus arquivos FTDC em /mongot/data/diagnostic.data/ nesse volume. Como os dados residem em um PersistentVolumeClaim, eles sobrevivem a reinicializações e reagendamentos de pods: quando o StatefulSet substitui um pod, ele anexa o mesmo PersistentVolumeClaim. Você configura este volume com a especificação.clusters[].persistence configuração no recurso MongoDBSearch.

Implemente o MongoDB Search e o Vector Search

Sistema de pesquisa Vector Search do MongoDB

Pré-requisitos

ConsideraçõesDescreve os requisitos de armazenamento, rede, recursos, versão e compatibilidade do Kubernetes, namespace e RBAC, e DNS do cluster.

LimitaçõesDescreve as limitações ao implantar o MongoDB Search e a pesquisa vetorial.

Tarefas de configuração

Tanto mongod quanto mongot implantados no KubernetesArquitetura dos processos mongod e mongot em execução em um cluster Kubernetes.

mongot implantado no Kubernetes com mongod em execução fora do KubernetesArquitetura de processos mongot implantados em um cluster Kubernetes para usar processos mongod em execução fora do cluster Kubernetes.

Segurança

Autenticação

Segurança da camada de transporte

mongot Certificados

Certificados de balanceador de carga

Balanceador de carga mTLS

Dados de diagnóstico

`mongot` Certificados