Configurações do MongoDB Search e Vector Search

Configurações para configurar a fonte de dados

spec.source

Tipo: objeto

Configuração que descreve a origem MongoDB para mongot. A origem pode ser um conjunto de réplicas ou um cluster fragmentado. Esta configuração é necessária se:

• MongoDB é externo

• MongoDB tem um nome diferente de MongoDBSearch

O recurso MongoDBSearch deve estar sempre conectado a uma implantação do MongoDB . Se você implantou usando o Operador Kubernetes com MongoDB ou MongoDBCommunity CRD e se spec.source estiver vazio, o Operador Kubernetes usará o seguinte com base em metadata.name para procurar o banco de dados no Kubernetes:

• Encontre recursos MongoDB ou MongoDBCommunity com o mesmo nome definido para metadata.name no MongoDBSearch, no mesmo namespace.

• Encontre o segredo da senha do usuário mongot no segredo <MongoDBSearch.metadata.name>-search-sync-source-password.

spec.source.mongodbResourceRef.name

Tipo: string

Nome do MongoDB ou MongoDBCommunity recurso a ser associado a este recurso do MongoDB Search e pesquisa vetorial. O Operador Kubernetes oferece suporte a conjuntos de réplicas e clusters fragmentados. Você não pode ter mais de um recurso MongoDBSearch referenciando o mesmo recurso MongoDB ou MongoDBCommunity. Se você especificar um nome diferente, deverá ponto explicitamente para o MongoDB ou MongoDBCommunity em que deseja ativar o MongoDB Search e a pesquisa vetorial.

Se você fizer referência a um recurso de cluster MongoDB, o Kubernetes operador descobrirá automaticamente a topologia do fragmento (nomes dos fragmentos, membros do conjunto de réplicas, mongos roteadores) e criará automaticamente o mongot StatefulSets por fragmento. Você não precisa realizar nenhuma configuração externa adicional.

Use esse campo somente se o recurso MongoDB ou MongoDBCommunity estiver implantado no mesmo cluster do Kubernetes e estiver no mesmo namespace que o recurso MongoDBSearch. Se você definir este campo, o operador Kubernetes automaticamente:

• Define connection strings adequadas para o banco de dados.

• Reconfigura implantações de banco de dados MongoDB definindo os parâmetros necessários para habilitar a funcionalidade de pesquisa e configura os endereços dos pods de pesquisa.

Se o seu banco de dados for implantado fora do Kubernetes ou estiver em um namespace diferente, utilize o spec.external para configurar a conexão com o banco de dados. Este campo é mutuamente exclusivo com spec.external.

Se omitido, o Operador Kubernetes procura um recurso MongoDB ou MongoDBCommunity com o mesmo nome que este recurso MongoDBSearch.

Configuração para configurar o usuário mongot

spec.source.username

Tipo: string

Nome de usuário para autenticar mongot com mongod. O usuário especificado deve ter a função searchCoordinator. Se omitido, o Operador Kubernetes assume que o nome de usuário é search-sync-source.

spec.source.passwordSecretRef.name

Tipo: string

Nome do segredo que contém a senha que mongot deve usar para autenticar com mongod. Se omitido, o padrão é <MongoDBSearch.metadata.name>-search-sync-source-password.

spec.source.passwordSecretRef.key

Tipo: string

Chave sob a qual o valor da senha é armazenado no segredo. Se omitido, o padrão é password.

Configurações para autenticação x509

spec.source.x509

Tipo: objeto

Configura a autenticação do certificado de cliente x509 para a conexão de origem de sincronização do mongot. Se você definir esse campomongot autenticado no MongoDB usando x509 em vez de nome de usuário e senha.

Este campo é mutuamente exclusivo com spec.source.passwordSecretRef e spec.source.username. O Operador Kubernetes rejeita a configuração se você especificar x509 e autenticação de senha.

spec.source.x509.clientCertificateSecretRef

Tipo: objeto

Segredo que contém o certificado do cliente x509 e a chave para autenticar na origem de sincronização do MongoDB . O segredo deve conter as seguintes chaves:

• tls.crt — Certificado do cliente (obrigatório)

• tls.key — Chave privada (obrigatório)

• tls.keyFilePassword - Senha para a chave privada (opcional)

Você deve especificar este campo se definir spec.source.x509.

Exemplo

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

Configurações para conexão ao MongoDB externo

As configurações a seguir são necessárias apenas para configurar uma conexão com um MongoDB implantação externo.

spec.source.external

Tipo: objeto

Configurações que descrevem a fonte de dados externa . Este objeto descreve as configurações do recurso MongoDB Search e Vector Search para se conectar a um MongoDB externo. Essas configurações devem ser especificadas somente se você quiser se conectar a um MongoDB externo que não tenha sido implantado usando o Kubernetes Operator. Se especificadas, estas configurações substituem as configurações para spec.source.mongodbResourceRef.name. Se você usou o Operador Kubernetes para instalar o MongoDB no mesmo cluster, essas configurações são opcionais.

Configurações de segurança

spec.security

Tipo: objeto

Configurações de segurança para mongot servidor de escuta.

spec.security.tls

Tipo: objeto

Configurações de TLS para mongot. Se omitido, o mongot não utilizará TLS para conexões recebidas.

spec.security.tls.certificateKeySecretRef.name

Tipo: string

Descontinuado desde a versão 1.8.0: Em vez disso, use spec.security.tls.certsSecretPrefix.

Nome do segredo TLS no mesmo namespace que contém a chave privada (tls.key) e o certificado (tls.crt). O segredo pode ser do tipo kubernetes.io/tls (que é emitido pelo cert-manager) ou pode ser criado manualmente.

O Operador Kubernetes ainda suporta este campo para implantações de conjunto de réplicas para compatibilidade com versões anteriores. No entanto:

• Para sistemas de cluster fragmentado , o Operador Kubernetes rejeita este campo durante a validação. Em vez disso, use spec.security.tls.certsSecretPrefix, porque uma única referência secreta não pode cobrir certificados por fragmento.

• Se você especificar certificateKeySecretRef e certsSecretPrefix, certificateKeySecretRef terá precedência para implantações do conjunto de réplicas.

Para novas implantações, utilize o spec.security.tls.certsSecretPrefix mesmo para conjuntos de réplica.

spec.security.tls.certsSecretPrefix

Tipo: string

Prefixo que o operador Kubernetes usa para derivar nomes secretos TLS por convenção de nomenclatura. Se você definir esse campo}, o operador Kubernetes procurará segredos seguindo esses padrões em vez de exigir referências secretas explícitas para cada componente:

Componente	Padrão de nome secreto
Certificado de servidor mongot do conjunto de réplicas	{certsSecretPrefix}-{name}-search-cert
Certificado mongot fragmentado (por fragmento)	{certsSecretPrefix}-{name}-search-0-{shardName}-cert
Certificado de servidor de balanceador de carga gerenciado	{certsSecretPrefix}-{name}-search-lb-0-cert
Certificado de cliente balanceador de carga gerenciado	{certsSecretPrefix}-{name}-search-lb-0-client-cert

Onde:

• {name} é metadata.name do recurso MongoDBSearch

• {shardName} é o valor de spec.source.external.shardedCluster.shards[*].shardName

Se omitido, este campo padroniza para uma string vazia e o Operador Kubernetes utiliza spec.security.tls.certificateKeySecretRef em vez disso.

Observação

Para implantações de cluster fragmentado, você deve utilizar o certsSecretPrefix ao invés de certificateKeySecretRef. O Operador Kubernetes rejeita certificateKeySecretRef para topologias fragmentadas porque uma única referência secreta não pode cobrir certificados por fragmento.

Exemplo

spec:
  security:
    tls:
      certsSecretPrefix: my-prefix

Configurações para várias instâncias do Mongot

spec.replicas

Tipo: inteiro

Número de mongot pods a serem implementados. Para uma origem do conjunto de réplicas, este é o número total de mongot pods. Para uma origem de cluster fragmentado , este é o número de mongot pods por fragmento.

Se spec.replicas for maior que 1, você também deverá configurar spec.loadBalancer para rotear o tráfego entre mongod e as múltiplas instâncias mongot.

Se omitido, o padrão é 1.

Exemplo

spec:
  replicas: 2

Configurações para balanceamento de carga

spec.loadBalancer

Tipo: objeto

Configuração para balanceamento de carga L7 entre mongod (ou mongos) e mongot. Este campo é obrigatório se spec.replicas for maior que 1. Se spec.replicas for 1, este campo será opcional. Você pode configurar um balanceador de carga mesmo para uma única instância do mongot para preparar-se para o dimensionamento posterior.

Exatamente um entre managed ou unmanaged deve ser definido.

O balanceador de carga afeta quais certificados TLS os clientes mongod veem e quais nomes de host esses certificados devem conter:

• Sem um balanceador de carga, o mongod conecta diretamente ao mongot. O certificado TLS apresentado a mongod é o próprio certificado de mongot. Se o cluster MongoDB estiver fora do Kubernetes, o serviço mongot será exposto em um domínio externo. Você deve incluir esse domínio externo no campo SAN ( nome alternativo do assunto ) do certificado TLS mongot.

• Com um balanceador de carga gerenciado (spec.loadBalancer.managed), o proxy Envoy é o único componente que se conecta diretamente ao mongot. O Envoy atinge mongot pods usando seus FQDNs de serviço headless interno:

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

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

  Emita o certificado TLS mongot com esses domínios locais do cluster no campo SAN. Você pode usar um certificado curinga para evitar a reemissão de certificados quando o número de mongot pods for alterado. Os processos mongod externos veem o certificado TLS do proxy Envoy, portanto, inclua domínios externos nos SANs do certificado Envoy, não no certificado mongot.

Dica

Habilite um balanceador de carga gerenciado mesmo se você implantar inicialmente um único pod do mongot. Com o balanceador de carga em vigor, os domínios em seus certificados TLS permanecerão estáveis se você dimensionar spec.replicas mais tarde, pois o balanceador de carga já está presente entre mongod e mongot.

spec.loadBalancer.managed

Tipo: objeto

Configura um balanceador de carga Envoy gerenciado pelo operador. O Operador do Kubernetes implementa e gerencia o proxy Envoy com roteamento correto, mTLS e fixação de fluxo HTTP/2+gRPC. Defina este campo como um objeto vazio ({}) para usar os padrões.

Este campo é mutuamente exclusivo com spec.loadBalancer.unmanaged.

Exemplo

spec:
  loadBalancer:
    managed: {}

spec.loadBalancer.managed.externalHostname

Tipo: string

Nome de host que o proxy Envoy espera para correspondência SNI nas solicitações recebidas. O Kubernetes operador usa esse valor para configurar as regras de roteamento que correspondam ao campo TLS SNI das conexões mongod de entrada. O certificado do servidor Envoy TLS deve incluir este nome de host em seu campo SAN ( nome alternativo do assunto ).

Para clusters fragmentados, o valor deve conter um espaço reservado do {shardName} que o Operador Kubernetes expande por fragmento. Cada fragmento recebe um nome de host exclusivo, e o certificado do servidor Envoy TLS deve incluir todos os nomes de host de fragmentos expandidos em seus SANs. Você pode usar um certificado curinga para cobrir todos os fragmentos com um único certificado e evitar a reemissão quando os fragmentos forem adicionados.

Esse campo é obrigatório se o MongoDB for gerenciado externamente (não implantado pelo operador Kubernetes). Se o MongoDB for gerenciado pelo operador no mesmo cluster, omita este campo porque o Operador Kubernetes configura automaticamente o roteamento.

Exemplo

# 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 e memória que o contêiner Envoy pode solicitar e ser limitado. Se você especificar esta configuração, o Operador Kubernetes substituirá completamente os padrões.

Se omitido, o Kubernetes Operator usa os seguintes valores padrão:

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

Exemplo

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

spec.loadBalancer.managed.deployment

Tipo: objeto

Substituições que o operador Kubernetes mescla na Implantação do Envoy criada pelo operador. Segue a mesma convenção que spec.statefulSet nos recursos do MongoDB . Se omitido, o Kubernetes Operator usa padrões para a implantação Envoy.

Este objeto contém dois campos:

• metadata — contém labels e annotations campos que o Operador Kubernetes mescla nos metadados da implantação do Envoy.

• spec — um objeto apps/v1/DeploymentSpec. O Operador Kubernetes mescla essas substituições na especificação da implantação do Envoy.

Exemplo

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

spec.loadBalancer.unmanaged

Tipo: objeto

Configura um balanceador de carga L7 fornecido pelo usuário. Você é responsável por implantar e configurar o balanceador de carga externamente.

Este campo é mutuamente exclusivo com spec.loadBalancer.managed.

spec.loadBalancer.unmanaged.endpoint

Tipo: string

O ponto de extremidade do balanceador de carga BYO no formato host:port. O Operador do Kubernetes grava este valor na configuração do mongod como mongotHost e searchIndexManagementHostAndPort.

Esse campo é obrigatório somente quando o Operador Kubernetes gerencia a implantação do MongoDB (usando spec.source.mongodbResourceRef), pois o Operador Kubernetes precisa do ponto de extremidade para configurar os parâmetros mongod. Se tanto o balanceador de carga quanto o MongoDB forem externos (não gerenciados pelo Operador Kubernetes), esse campo não será necessário porque você mesmo configura os parâmetros mongod.

Para clusters fragmentados, o valor deve conter um espaço reservado do {shardName} que o Operador Kubernetes expande por fragmento.

Exemplo

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

Configurações para provisionamento de recursos

spec.resourceRequirements

Tipo: core/v1/ResourceRequirements

CPU e memória para as quais o container mongodb-search pode solicitar e ser limitado. Recomendamos usar esse campo para personalizar as alocações de recursos em vez de substituí-lo por spec.statefulSet.

Se você não substituir o tamanho de heap JVM no spec.jvmFlags, o Operador Kubernetes definirá o tamanho de heap padrão (-Xmx) para 50% da memória disponível para o pod mongot. Ajuste spec.resourceRequirements adequadamente para controlar os recursos do pod e o tamanho do heap da JVM .

Se omitido, o Kubernetes Operator usa os seguintes valores padrão:

requests:
  cpu: 2
  memory: 2G

spec.resourceRequirements.limits

Tipo: objeto

Limite superior no recurso, CPU e memória, que o contêiner do mongodb-search pode consumir. Por padrão, não há limites definidos. Se omitido, o pod não será restrito e, portanto, pode usar todos os recursos no nó. Recomendamos definir limites com base em seu volume de trabalho.

spec.resourceRequirements.requests

Tipo: objeto

Quantidade de CPU e memória solicitada para o contêiner mongodb-search. Se omitido, o Kubernetes Operator usa os seguintes valores padrão:

requests:
  cpu: 2
  memory: 2G

spec.persistence.single

Tipo: objeto

Configuração de armazenamento para o volume de persistência do MongoDB Search e Vector Search onde os índices do MongoDB Search e Vector Search são armazenados. Cada instância de pesquisa (pod) tem seu próprio armazenamento independente para manter índices, que não é compartilhado com o banco de dados MongoDB . Somente metadados de índice (definições) são armazenados no próprio banco de dados .

Escalar	Tipo de Dados	Descrição
labelSelector	string	Tag usada para vincular volumes montados a diretórios.
storage	string	Tamanho mínimo do volume persistente que deve ser montado. Esse valor é expresso como um número inteiro seguido por uma unidade de armazenamento na notação JEDEC. O valor padrão é 16Gi. Por exemplo, se o conjunto de réplicas exigir 60 gigabytes de espaço de armazenamento, defina esse valor como 60Gi.
storageClass	string	Tipo de armazenamento especificado em uma declaração de volume persistente. Você pode criar esse tipo de armazenamento como um objeto StorageClass antes de usá-lo nesta especificação de objeto. Certifique-se de definir a StorageClass reclaimPolicy como Retain. Isso garante que os dados sejam mantidos quando uma declaração de volume persistente for removida.

O MongoDBSearch oferece suporte apenas ao campo de persistência single. Se omitido, o Operador Kubernetes define spec.persistence.single.storage como 10GB.

Configurações para registro

spec.logLevel

Tipo: string

Verbosidade dos registros do mongot. O valor pode ser um dos seguintes:

• TRACE

• DEBUG

• INFO

• WARN

• ERROR

Se omitido, o padrão é INFO.

Configurações para métricas

spec.prometheus

Tipo: objeto

Disponível apenas na v1.6 e posterior.

Configuração para ativar o ponto de extremidade de métricas Prometheus. Se omitido, o ponto de extremidade de métricas em mongot será desabilitado. Para habilitar o ponto de extremidade de métricas Prometheus na porta padrão (9946), especifique um objeto {} vazio no campo spec.prometheus. Para alterar a porta, defina-a no campo spec.prometheus.port.

spec.prometheus.port

Tipo: string

Porta na qual ativar o ponto de extremidade de métricas Prometheus. Por padrão, o ponto de extremidade de métricas Prometheus está habilitado na porta 9946.

Configurações para incorporação automática

spec.autoEmbedding

Tipo: objeto

Configuração para incorporação automática de dados de texto em sua coleção.

spec.autoEmbedding.embeddingModelAPIKeySecret

Tipo: objeto

Configuração para as chaves API do fornecedor do modelo de incorporação. Para habilitar a Incorporação Automática, você deve criar duas chaves, uma para gerar incorporações no momento do índice para os dados da sua coleção e outra para gerar incorporações no momento da query para o texto da query. Se você ainda não tiver as chaves, recomendamos que crie chaves a partir de dois projetos do Atlas . Para saber mais sobre como criar chaves para os projetos do Atlas a partir da IU do Atlas, consulte Gerenciar chaves de API.

spec.autoEmbedding.embeddingModelAPIKeySecret.name

Tipo: string

Nome do segredo que contém as chaves API do modelo de incorporação que mongot deve usar para gerar incorporações no momento do índice e da query.

spec.autoEmbedding.providerEndpoint

Tipo: string

URL de ponto de extremidade do modelo de incorporação para gerar incorporações. O valor varia dependendo se você cria as chaves a partir da IU do Atlas (recomendado) ou diretamente do serviço de incorporação (Voyage IA). Para chaves criadas a partir de:

• IU do Atlas, o valor é https://ai.mongodb.com/v1/embeddings (padrão)

• Voyage IA, o valor é https://api.voyageai.com/v1/embeddings

Definições para configuração JVM

spec.jvmFlags

Tipo: array de strings

Sinalizadores JVM passados para o processo mongot. O Operador Kubernetes inclui os sinalizadores sem modificação no comando de inicialização do mongot utilizando --jvm-flags "<all flags space-separated>".

Se você não especificar -Xms ou -Xmx neste campo, o Operador Kubernetes calculará automaticamente o tamanho do heap configurando ambos para metade de spec.resourceRequirements.requests.memory. Se você não especificar os requisitos de recursos, o Kubernetes operador usará um padrão de 4Solicitação de memória Gi, gerando aproximadamente -Xmx2048m -Xms2048m.

Se você fornecer seus próprios valores -Xms ou -Xmx , o Operador Kubernetes os utilizará e não substituirá os valores. O operador Kubernetes sempre anexa os sinalizadores fornecidos após os sinalizadores calculados pelo operador.

Para saber mais, consulte Dimensionamento de hardware para mongot.

Exemplo

spec:
  jvmFlags:
    - -Xms2g
    - -Xmx2g

Outras configurações

spec.version

Tipo: string

Versão da imagem do docker do mongodb-search. Se omitido, o Operador Kubernetes escolhe automaticamente a versão mais recente do MongoDBSearch. Você pode defini-lo explicitamente para evitar upgrades automáticos quando a versão do operador Kubernetes for atualizada.

spec.statefulSet

Digite: apps/v1/StatefulSet

Especificação para o StatefulSet, criado para implantar os pods mongot, que substitui as configurações que o Operador Kubernetes aplica. As substituições são sempre aplicadas por último. Suporta os campos spec.statefulSet.spec e spec.statefulSet.metadata.

Observação

Não defina requisitos de recursos ou configurações de persistência usando spec.statefulSet. Em vez disso, utilize os campos spec.resourceRequirements e spec.persistence respectivamente.