Configuraciones de MongoDB Search y búsqueda vectorial

Configuración para conectar a un set de réplicas externo

spec.source.external.hostAndPorts

Tipo: arreglo de cadenas

Lista de nombres de host y puertos del set de réplicas externas. Esta es una lista de nodos iniciales de host para el set de réplicas de MongoDB. El mongot se conecta a la base de datos en modo de set de réplicas y obtiene la lista de todos los demás nodos utilizando db.hello().

Este campo es mutuamente excluyente con spec.source.external.shardedCluster. Use hostAndPorts para fuentes de sets de réplicas y shardedCluster para fuentes de clústeres.

Ejemplo

hostAndPorts:
  - mdbc-rs-0.my-external-domain.example.com:27017
  - mdbc-rs-1.my-external-domain.example.com:27017
  - mdbc-rs-2.my-external-domain.example.com:27017

spec.source.external.tls

Tipo: Objeto

Configuraciones de TLS que mongot debe usar al conectarse a la base de datos externa MongoDB.

spec.source.external.tls.ca.name

Tipo: string

Nombre del ConfigMap que contiene la cadena de confianza de las autoridades de certificación que emitieron el certificado TLS utilizado por los nodos mongod.

Ejemplo

spec:
  source:
    external:
      tls:
        ca:
          name: trusted-ca

Debe especificar el certificado (o la cadena de certificados) bajo la clave ca.crt en este ConfigMap.

Ejemplo

kind: ConfigMap
apiVersion: v1
metadata:
  name: trusted-ca
data:
  ca.crt: |
    -----BEGIN CERTIFICATE-----
    MIIDBTCCAe2gAwIBAgIIH3EOUAGAsx0wDQYJKoZIhvcNAQELBQAwFTETMBEGA1UE
    [...]
    U/4rN8Ias/FONYFRtGfs9uXHmo2MP04BF+9ED2dlbNDUbat+6XCozLJj98nI4VEi
    qaV3JrVFHTgN
    -----END CERTIFICATE-----

Configuraciones para conectar a un clúster fragmentado externo

Los siguientes ajustes son necesarios solo para configurar una conexión con un clúster segmentado externo de MongoDB. Extienden la configuración existente de spec.source.external.

spec.source.external.shardedCluster

Tipo: Objeto

Declara un clúster MongoDB particionado externo como fuente de datos para mongot. Contiene la configuración para los routers mongos y los miembros del conjunto de réplicas por partición.

Utilízalo sólo si el clúster compartido de MongoDB está implementado fuera de Kubernetes y no es gestionado por el Operador de Kubernetes. Para los clústeres fragmentados gestionados por operadores implementados con el MongoDB CRD, utiliza spec.source.mongodbResourceRef en su lugar. El operador de Kubernetes detecta automáticamente la topología de partición.

Ejemplo

spec:
  source:
    external:
      shardedCluster:
        router:
          hosts:
            - "mongos1.external:27017"
            - "mongos2.external:27017"
        shards:
          - shardName: "shard-0"
            hosts:
              - "shard0-node1.external:27018"
              - "shard0-node2.external:27018"
          - shardName: "shard-1"
            hosts:
              - "shard1-node1.external:27018"
              - "shard1-node2.external:27018"

spec.source.external.shardedCluster.router

Tipo: Objeto

Configuración para las instancias mongos (router) del clúster externo.

spec.source.external.shardedCluster.router.hosts

Tipo: arreglo de cadenas

Lista de extremos para las instancias de router mongos en formato host:port. Todas las mongot instancias se conectan a estos routers. Especifique al menos una entrada.

Ejemplo

router:
  hosts:
    - "mongos1.external:27017"
    - "mongos2.external:27017"

spec.source.external.shardedCluster.shards

Tipo: arreglo de objetos

Lista de todas las particiones del clúster externo de MongoDB. Cada entrada describe el conjunto de réplicas de una partición. El Kubernetes Operator crea un mongot StatefulSet para cada partición, donde cada StatefulSet contiene el número de pods especificado en spec.clusters[].replicas. Especifica al menos una entrada de partición.

spec.source.external.shardedCluster.shards[*].shardName

Tipo: string

El nombre lógico de la partición. El Operador de Kubernetes utiliza este nombre para la nomenclatura de recursos de Kubernetes (StatefulSets, Servicios, Secretos). El valor puede ser diferente del nombre de la partición de MongoDB.

Restricciones de denominación:

• Debe ser único en todas las particiones.

• Debe ajustarse a las reglas de nombres de etiquetas DNS 1123de Kubernetes (RFC), que permiten caracteres alfanuméricos en minúscula y guiones- (), y requieren que el nombre comience y termine con un carácter alfanumérico. No se permiten puntos. () ni guiones bajos ()._ La longitud máxima es de 63 caracteres.

• El operador de Kubernetes combina metadata.name, el índice del clúster, y shardName en los nombres de los recursos de Kubernetes que crea (por ejemplo, {name}-search-{clusterIndex}-{shardName}), y valida que cada nombre generado se ajuste a los límites de DNS de Kubernetes de 63 caracteres para etiquetas y 253 caracteres para nombres de subdominios. Mantenga shardName lo suficientemente corto para cumplir con estos límites.

Ejemplo

shards:
  - shardName: "shard-0"
    hosts:
      - "shard0-node1.external:27018"

spec.source.external.shardedCluster.shards[*].hosts

Tipo: arreglo de cadenas

Lista de endpoints de los miembros del conjunto de réplicas mongod para esta partición en el formato host:port. Las instancias mongot replican los datos desde estos hosts. Especifique al menos una entrada.

Cada set de réplicas (partición) tiene su propio grupo de instancias mongot, que obtiene los datos solo de ese set de réplicas. Las diferentes particiones nunca comparten las mismas instancias de mongot.

Ejemplo

shards:
  - shardName: "shard-0"
    hosts:
      - "shard0-node1.external:27018"
      - "shard0-node2.external:27018"
      - "shard0-node3.external:27018"

Dimensionamiento y almacenamiento

spec.clusters[].replicas

Tipo: entero

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

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

Si se establece spec.clusters[].replicas en 0, el operador de Kubernetes desactiva el despliegue mongot en este clúster. El operador de Kubernetes escala el StatefulSet a cero pods y mantiene el recurso MongoDBSearch y sus demás recursos de Kubernetes en su lugar.

Si se omite, es por defecto 1.

Ejemplo

spec:
  clusters:
    - replicas: 2

spec.clusters[].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.clusters[].statefulSet.

Si no se modifica el tamaño del montón de la JVM en spec.clusters[].jvmFlags, el operador de Kubernetes establece el tamaño predeterminado del montón (-Xmx) en el 50% de la solicitud de memoria del contenedor mongot. Ajuste spec.clusters[].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: 4Gi

spec.clusters[].resourceRequirements.limits

Tipo: Objeto

Límite máximo de recursos (CPU y memoria) que puede consumir el contenedor mongodb-search. Por defecto, no se establecen límites. Si se omite, el pod no tiene restricciones y, por lo tanto, podría usar todos los recursos del nodo. Recomendamos establecer límites en función de la carga de trabajo.

spec.clusters[].resourceRequirements.requests

Tipo: Objeto

Cantidad de CPU y memoria solicitada para el contenedor mongodb-search. Si especifica solo uno de cpu o memory, el operador de Kubernetes aplica el valor predeterminado para el otro. Si se omite, el operador de Kubernetes utiliza los siguientes valores predeterminados:

requests:
  cpu: 2
  memory: 4Gi

spec.clusters[].persistence.single

Tipo: Objeto

Configuración de almacenamiento para el volumen persistente de MongoDB Search y búsqueda vectorial donde se almacenan los índices de MongoDB Search y búsqueda vectorial. Cada instancia de búsqueda (pod) tiene su propio almacenamiento independiente para mantener índices, que no se comparte con la base de datos MongoDB. Solo los metadatos del índice (definiciones) se almacenan en la propia 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 a montar. Este valor se expresa como un número entero seguido de una unidad de almacenamiento en notación JEDEC. El valor por defecto es 16G. Por ejemplo, si un conjunto de 60 réplicas requiere gigabytes de espacio de almacenamiento, establezca este valor 60G en.
storageClass	string	Tipo de almacenamiento especificado en una solicitud 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 single modo de persistencia, que utiliza un único volumen para todos los datos. Aunque el esquema CRD también contiene un spec.clusters[].persistence.multiple campo, el operador de Kubernetes no lo aplica. Si se omite,persistence el operador de Kubernetes spec.clusters[].persistence.single.storage establece 16G en.

Equilibrio de carga

spec.clusters[].loadBalancer

Tipo: Objeto

Configuración para el balanceo de carga L7 entre mongod (u mongos) y mongot. Este campo es obligatorio si spec.clusters[].replicas es mayor que 1. Si spec.clusters[].replicas es 1, este campo es opcional. Puedes configurar un balanceador de carga incluso para una sola instancia mongot para prepararte para un escalado posterior.

Se debe establecer exactamente solo uno de managed o unmanaged.

Todas las entradas en spec.clusters deben coincidir en el modo de balanceador de carga: o bien todas las entradas establecen loadBalancer.managed, todas establecen loadBalancer.unmanaged, o ninguna establece loadBalancer. El operador de Kubernetes rechaza los modos mixtos. Las implementaciones de clústeres múltiples solo admiten el modo administrado.

El equilibrador de carga afecta el tipo de certificados TLS que ven los clientes de mongod y los nombres de host que deben contener esos certificados:

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

• Con un balanceador de carga administrado spec.clusters[].loadBalancer.managed(), el proxy Envoy es el único componente que se conecta directamente mongot a. El proxy Envoy llega a mongot a través de los FQDN de servicio internos:

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

  • clúster particionado: <name>-search-<clusterIndex>-<shard>-svc.<ns>.svc.cluster.local

  Recomendamos incluir estos FQDN de servicio en el mongot campo SAN del certificado TLS. El proxy Envoy administrado por el operador actualmente valida el mongot certificado solo con la autoridad de certificación y no compara los nombres de host SAN. Los mongod procesos externos ven el certificado TLS del proxy Envoy, por lo que debe incluir los dominios externos en el campo SAN del certificado Envoy, no en el mongot certificado.

Tip

Permite un balanceador de carga administrado incluso si inicialmente implementas un solo pod mongot. Con el balanceador de carga en funcionamiento, los dominios en tus certificados TLS se mantienen estables si más adelante escalas spec.clusters[].replicas porque el balanceador de carga ya está presente entre mongod y mongot.

spec.clusters[].loadBalancer.managed

Tipo: Objeto

Configura un Envoy balanceador de carga gestionado por el operador. El Operador Kubernetes despliega y gestiona el proxy Envoy con un enrutamiento correcto, mTLS y fijación de flujos HTTP/2+ gRPC. Configura este campo a un objeto vacío ({}) para usar los valores por defecto.

Este campo es excluyente con spec.clusters[].loadBalancer.unmanaged.

Para fuentes de clúster fragmentadas, también debe configurar spec.security.tls si utiliza un balanceador de carga administrado. El proxy Envoy enruta el tráfico al fragmento correcto mediante SNI, que requiere TLS.

Ejemplo

spec:
  clusters:
    - loadBalancer:
        managed: {}

spec.clusters[].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 TLS SNI de las conexiones entrantes mongod. El certificado de servidor Envoy TLS debe incluir este nombre de host en su campo SAN (Nombre Alternativo del Sujeto).

Para fuentes de clúster fragmentadas, el valor debe contener un marcador de posición {shardName}, que el operador de Kubernetes expande para cada fragmento. Cada fragmento obtiene su propio nombre de host, 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 volver a emitirlo cuando se agreguen fragmentos. Para fuentes de conjunto de réplicas, no use el marcador de posición {shardName}.

Este campo es obligatorio si MongoDB se gestiona externamente (no implementado por el Operador de Kubernetes). Si MongoDB está gestionado por el operador en el mismo clúster, omita este campo porque el Operador de Kubernetes configura automáticamente el enrutamiento.

En implementaciones con varios clústeres, cada entrada de clúster suele usar un nombre de host distinto. Sin embargo, el operador de Kubernetes permite compartir un mismo nombre de host entre clústeres, por ejemplo, si un proxy de conmutación por error que abarca varias zonas de disponibilidad actúa como proxy para los proxies Envoy de varios clústeres.

Ejemplo

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

spec.clusters[].loadBalancer.managed.routerHostname

Tipo: string

Punto final que los enrutadores mongos utilizan para llegar a las instancias mongot de este clúster a través del balanceador de carga Envoy administrado, en el formato host:port. El operador de Kubernetes utiliza el nombre de host para la coincidencia SNI en la cadena de enrutamiento a nivel de clúster, por lo que el certificado del servidor TLS de Envoy debe incluir este nombre de host en sus SAN.

Este campo es obligatorio si utiliza un balanceador de carga administrado con una fuente MongoDB fragmentada externa (spec.source.external.shardedCluster). El operador de Kubernetes ignora este campo para las fuentes de conjuntos de réplicas y para MongoDB administrado por el operador.

A diferencia de externalHostname, el operador de Kubernetes utiliza este valor tal cual, por lo que no debe contener un marcador de posición {shardName}. Este punto final es el punto de entrada independiente del fragmento para mongos.

En implementaciones con múltiples clústeres, cada entrada de clúster suele usar un valor distinto. Sin embargo, el operador de Kubernetes permite compartir un mismo valor entre clústeres, por ejemplo, si un proxy de conmutación por error que abarca varias zonas de disponibilidad actúa como proxy de Envoy para varios clústeres.

Ejemplo

spec:
  clusters:
    - loadBalancer:
        managed:
          externalHostname: "{shardName}.search.example.com"
          routerHostname: "search-router.example.com:27028"

spec.clusters[].loadBalancer.managed.replicas

Tipo: entero

Número de pods proxy de Envoy que se implementarán en este clúster de Kubernetes. El valor debe ser 1 o mayor. Si se omite, se utiliza 1 por defecto.

spec.clusters[].loadBalancer.managed.resourceRequirements

Tipo: core/v1/ResourceRequirements

CPU y memoria que el contenedor Envoy puede solicitar y limitar. Si especifica esta configuración, el operador de Kubernetes reemplaza por completo los valores por defecto.

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:
  clusters:
    - loadBalancer:
        managed:
          resourceRequirements:
            requests:
              cpu: "200m"
              memory: "256Mi"
            limits:
              cpu: "1"
              memory: "1Gi"

spec.clusters[].loadBalancer.managed.deployment

Tipo: Objeto

Anulaciones que el Operador de Kubernetes fusiona en la Implementación de Envoy creada por el operador. Sigue la misma convención que spec.statefulSet en recursos de MongoDB. Si se omite, el Operador de Kubernetes utiliza los valores por defecto para el Despliegue de Envoy.

Este objeto contiene dos campos:

• metadata — contiene los 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 estos valores anulados en la especificación de implementación de Envoy.

Ejemplo

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

spec.clusters[].loadBalancer.managed.retryPolicy

Tipo: Objeto

Comportamiento de reintento que el proxy Envoy aplica a flujos gRPC individuales a las instancias mongot ascendentes. El proxy Envoy envía cada intento de reintento a un host mongot diferente al del intento fallido.

Si omite este campo, el proxy Envoy reintenta con los valores predeterminados: 2 reintenta con un tiempo de espera por intento de 60s.

Ejemplo

spec:
  clusters:
    - loadBalancer:
        managed:
          retryPolicy:
            numRetries: 2
            perTryTimeout: "60s"

spec.clusters[].loadBalancer.managed.retryPolicy.numRetries

Tipo: entero

Número máximo de reintentos por solicitud. El valor debe ser 1 o mayor. Si se omite, se utiliza por defecto 2, lo que permite un total de tres intentos por solicitud.

spec.clusters[].loadBalancer.managed.retryPolicy.perTryTimeout

Tipo: string

Tiempo de espera para cada intento individual, incluida la solicitud original, expresado como una cadena de duración (por ejemplo, "30s"). Si se omite, el valor predeterminado es "60s".

spec.clusters[].loadBalancer.managed.minMongotReadyReplicas

Tipo: entero

Número mínimo de réplicas mongot listas que un grupo mongot (por ejemplo, las mongot instancias de un fragmento) debe tener antes de que el proxy Envoy dirija el tráfico hacia él. Mientras un grupo esté por debajo de este umbral, el proxy Envoy reenvía el tráfico destinado a ese grupo a un grupo mongot en buen estado y marca las solicitudes con el encabezado routed_from_another_shard. Estas solicitudes devuelven resultados vacíos en lugar de errores.

El valor debe ser 1 o mayor. Si se omite, se toma por defecto 1.

spec.clusters[].loadBalancer.unmanaged

Tipo: Objeto

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

Este campo es mutuamente excluyente con spec.clusters[].loadBalancer.managed. Las implementaciones de clústeres múltiples no admiten balanceadores de carga no administrados.

spec.clusters[].loadBalancer.unmanaged.endpoint

Tipo: string

El punto final del balanceador de carga BYO en formato host:port. Debe especificar este campo si configura spec.clusters[].loadBalancer.unmanaged.

Si el operador de Kubernetes gestiona el despliegue de MongoDB (usando spec.source.mongodbResourceRef), el operador de Kubernetes escribe este valor en la configuración mongod como mongotHost y searchIndexManagementHostAndPort. Si MongoDB es externo, configure usted mismo los parámetros mongod usando el mismo valor.

Para fuentes de clústeres fragmentados externos, el valor debe contener un marcador de posición {shardName} que el operador de Kubernetes expande por cada fragmento, y debe contener más que solo dicho marcador. Para fuentes de conjuntos de réplicas externos, el valor no debe contener un marcador de posición {shardName}.

Ejemplo

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

Anulaciones por fragmento

spec.clusters[].shardOverrides

Tipo: arreglo de objetos

Anula la configuración que dimensiona fragmentos específicos dentro de esta entrada de clúster de manera diferente a la configuración predeterminada del clúster. Utilice este campo para asignar a fragmentos individuales más o menos réplicas mongot, recursos o almacenamiento que al resto del clúster.

Este campo solo se puede usar con una fuente de clúster fragmentada externa (spec.source.external.shardedCluster). Cada nombre de fragmento al que haga referencia debe existir en spec.source.external.shardedCluster.shards[*].shardName, y puede sobrescribir cada fragmento como máximo una vez por entrada de clúster.

Si se establecen replicas, resourceRequirements, persistence o jvmFlags en una anulación, estos reemplazan el valor del clúster para los fragmentos con nombre. El operador de Kubernetes fusiona profundamente statefulSet con el valor del clúster. Los campos que no se establecen heredan el valor del clúster.

Ejemplo

spec:
  clusters:
    - replicas: 2
      shardOverrides:
        - shardNames:
            - shard-0
          replicas: 3
          resourceRequirements:
            requests:
              cpu: "4"
              memory: 8Gi

spec.clusters[].shardOverrides[*].shardNames

Tipo: arreglo de cadenas

Nombres de los fragmentos dentro de esta entrada de clúster a los que se aplica la anulación. Este campo es obligatorio y debe contener al menos una entrada.

spec.clusters[].shardOverrides[*].replicas

Tipo: entero

Reemplaza el recuento de réplicas mongot del clúster para los fragmentos nombrados. Un valor de 0 pone fuera de línea las mongot instancias para estos fragmentos.

spec.clusters[].shardOverrides[*].resourceRequirements

Tipo: core/v1/ResourceRequirements

Sustituye las solicitudes y los límites de CPU y memoria del clúster para los fragmentos con nombre.

spec.clusters[].shardOverrides[*].persistence

Tipo: Objeto

Reemplaza la configuración de volumen persistente del clúster para los fragmentos con nombre. Utiliza el mismo esquema que spec.clusters[].persistence.

spec.clusters[].shardOverrides[*].statefulSet

Tipo: Objeto

Anulaciones de StatefulSet para los fragmentos con nombre. A diferencia de los otros campos de anulación, el operador de Kubernetes fusiona profundamente este valor en el valor spec.clusters[].statefulSet del clúster en lugar de reemplazarlo.

spec.clusters[].shardOverrides[*].jvmFlags

Tipo: arreglo de cadenas

Reemplaza el spec.clusters[].jvmFlags del clúster para los fragmentos con nombre si lo configuras con una lista no vacía. Las reglas de formato para spec.clusters[].jvmFlags también se aplican a este campo.

Sincronizar selección de fuente

spec.clusters[].syncSourceSelector

Tipo: Objeto

Selecciona de qué mongod nodos las mongot instancias en esta entrada de clúster sincronizan los datos.

spec.clusters[].syncSourceSelector.matchTagSets

Tipo: arreglo de objetos

Lista ordenada de conjuntos de etiquetas de conjuntos de réplicas que selecciona los nodos de origen de sincronización mongod según sus etiquetas de conjunto de réplicas. El operador de Kubernetes pasa la lista a la configuración mongot. mongot sincroniza desde los nodos que selecciona el primer conjunto de etiquetas coincidente y da preferencia a los nodos secundarios.

Cada entrada es un mapa de nombres de etiquetas a valores de etiquetas. Un documento vacío ({}) coincide con cualquier nodo, por lo que puede agregar una entrada {} al final como alternativa si ningún conjunto de etiquetas anterior coincide. Puede especificar como máximo 50 entradas.

Ejemplo

spec:
  clusters:
    - syncSourceSelector:
        matchTagSets:
          - region: us-east-1
            workload: search
          - {}

JVM Flags

spec.clusters[].jvmFlags

Tipo: arreglo de cadenas

Señales de JVM pasadas al proceso mongot. El operador de Kubernetes incluye las banderas sin modificaciones en el comando de inicio mongot usando --jvm-flags "<all flags space-separated>".

Cada bandera debe comenzar con -X, -XX: o -D, no debe contener espacios y solo puede contener caracteres alfanuméricos y los caracteres ., _, +, :, - y =. El operador de Kubernetes rechaza las banderas que no cumplen con estas reglas.

Si no especifica -Xms o -Xmx en este campo, el Operador de Kubernetes calcula automáticamente el tamaño del heap configurando ambos en la mitad de spec.clusters[].resourceRequirements.requests.memory. Si no se especifican los requisitos de recursos, el Operador de Kubernetes utiliza un valor predeterminado de 4Gi de solicitud de memoria, lo que genera aproximadamente -Xmx2048m -Xms2048m.

Si proporciona sus propios valores de -Xms o -Xmx, el operador de Kubernetes los utiliza y no los anula. El Operador de Kubernetes siempre añade los parámetros que usted proporciona después de los parámetros calculados por el operador.

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

Ejemplo

spec:
  clusters:
    - jvmFlags:
        - -Xms2g
        - -Xmx2g

Anulaciones de StatefulSet

spec.clusters[].statefulSet

Tipo: Objeto

Anulaciones para el StatefulSet que el Operador de Kubernetes crea para desplegar mongot pods. El Operador de Kubernetes siempre aplica las anulaciones al final, por lo que sobrescriben la configuración que calcula el Operador de Kubernetes.

Este objeto contiene dos campos:

• metadata — contiene campos labels y annotations que el operador de Kubernetes fusiona en los metadatos de StatefulSet.

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

Nota

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

mongot Configuración avanzada

spec.clusters[].advancedMongotConfigs

Tipo: Objeto

Configuración avanzada mongot para esta entrada de clúster. El operador de Kubernetes reproduce el valor tal cual bajo la clave advancedConfigs del archivo de configuración mongot, sin leerlo ni modificarlo. Este campo no afecta la configuración que el operador de Kubernetes genera en otras partes de la configuración mongot.

Utilice este campo únicamente para configuraciones mongot que el recurso MongoDBSearch no expone como campos de primera clase.