Para agentes de IA: hay un índice de documentación disponible en https://www.mongodb.com/es/docs/llms.txt — versiones en markdown de todas las páginas están disponibles agregando .md a cualquier ruta URL.
Docs Menu
Docs Home
/ /
Implementar recursos de la base de datos
Docs Home
/
Gestión
/
Controladores para el Operador de Kubernetes
/
Implementar recursos de la base de datos
Docs Home
/
Gestión
/
Controladores para el Operador de Kubernetes
/
Implementar recursos de la base de datos

Configura el recurso personalizado de MongoDB

El recurso personalizado de MongoDB es la principal forma de definir y gestionar las implementaciones de MongoDB mediante el operador de Kubernetes. En lugar de configurar las instancias de MongoDB directamente, se declara el estado deseado en un manifiesto YAML, y el operador ajusta el estado real del clúster para que coincida. Esta guía explica los componentes conceptuales de dicho manifiesto, ayudándole a comprender no solo la función de cada área de configuración, sino también por qué y cuándo podría necesitarla al planificar una implementación que se ajuste a las necesidades de su equipo.

Ya sea que esté configurando un conjunto de réplicas de desarrollo por primera vez o iterando en un clúster fragmentado de producción, las decisiones que se describen aquí constituyen la base de una implementación de MongoDB estable, segura y de alto rendimiento en Kubernetes.

Para consultar la especificación completa campo por campo, véase la Especificación de recursos de la base de datos MongoDB.

Selección de un tipo de despliegue

La primera decisión que debes tomar es qué tipo de implementación de MongoDB crear. El campo spec.type acepta tres valores, cada uno orientado a un conjunto diferente de cargas de trabajo y requisitos operativos. Es fundamental comprender las ventajas y desventajas de cada uno antes de escribir una sola línea de YAML.

Las instancias independientes ejecutan un único mongod proceso. Son ideales para el desarrollo local, la prueba de escenarios o la evaluación de funcionalidades donde la redundancia no es un factor crítico. Dado que una implementación independiente no cuenta con replicación, no admite la conmutación por error automática y no se recomienda para datos de producción.

Los conjuntos deréplicas son la topología de producción predeterminada para MongoDB. Un conjunto de réplicas consta de varios mongod miembros (normalmente tres o más) que mantienen copias idénticas de los datos. Si el miembro principal falla, los miembros restantes eligen uno nuevo automáticamente. Elegir un conjunto de réplicas proporciona alta disponibilidad, escalabilidad de lectura mediante lecturas secundarias y la capacidad de realizar mantenimiento progresivo. Para la mayoría de los equipos, este es el punto de partida.

apiVersion: mongodb.com/v1
kind: MongoDB
metadata:
  name: my-replica-set
spec:
  type: ReplicaSet
  members: 3
  version: "8.0.0"
  opsManager:
    configMapRef:
      name: my-project-configmap
  credentials: my-credentials
  persistent: true

Los clústeres fragmentados distribuyen los datos entre múltiples fragmentos, cada uno de los cuales es a su vez un conjunto de réplicas. Delante de los fragmentos se encuentran mongos enrutadores que dirigen el tráfico de los clientes y un conjunto de réplicas de servidor de configuración dedicado que almacena los metadatos del clúster. Si su conjunto de datos crece más allá de lo que un único conjunto de réplicas puede gestionar eficientemente, o si necesita escalar las escrituras horizontalmente, un clúster fragmentado es la opción adecuada. La configuración es más compleja porque debe especificar la cantidad de fragmentos, mongod instancias por fragmento, mongos enrutadores y servidores de configuración.

apiVersion: mongodb.com/v1
kind: MongoDB
metadata:
  name: my-sharded-cluster
spec:
  type: ShardedCluster
  shardCount: 2
  mongodsPerShardCount: 3
  mongosCount: 2
  configServerCount: 3
  version: "8.0.0"
  opsManager:
    configMapRef:
      name: my-project-configmap
  credentials: my-credentials
  persistent: true

Para obtener información detallada sobre cada campo específico de cada tipo de implementación, consulte las secciones "Independiente", "Conjunto deréplicas" y "Clúster fragmentado" de la documentación de referencia de la especificación.

Conectarse con Ops Manager

Cada recurso personalizado de MongoDB debe estar vinculado a un proyecto de Ops Manager. Esta conexión permite que el operador de Kubernetes registre tu despliegue para su monitorización, automatización y copia de seguridad. Dos elementos de configuración hacen posible esta conexión: un ConfigMap que identifica tu proyecto y un Secret que almacena tus credenciales de API.

El ConfigMap le indica al operador de Kubernetes en qué proyecto de Ops Manager debe ubicar el despliegue. Como mínimo, debe contener un projectName y un baseUrl que apunten a su instancia de Ops Manager. Opcionalmente, puede fijar el despliegue a una organización específica con orgId:

apiVersion: v1
kind: ConfigMap
metadata:
  name: my-project-configmap
data:
  projectName: "MyKubernetesProject"
  baseUrl: "https://ops-manager.example.com"
  orgId: "5e8f8b8b8b8b8b8b8b8b8b8b"

El secreto contiene el par de claves API programáticas que el operador de Kubernetes utiliza para autenticarse en la API de Ops Manager en su nombre:

kubectl create secret generic my-credentials \
  --from-literal="publicKey=<public-api-key>" \
  --from-literal="privateKey=<private-api-key>"

Luego, haces referencia a ambos en tu CR de MongoDB:

spec:
  opsManager:
    configMapRef:
      name: my-project-configmap
  credentials: my-credentials

Para obtener más información sobre cómo crear estos requisitos previos, consulte Crear credenciales para el operador de Kubernetes y Crear un proyecto por implementación de MongoDB mediante un ConfigMap.

Compatibilidad de versiones y características de MongoDB

El campo spec.version establece la versión del servidor MongoDB que implementa el operador de Kubernetes (por ejemplo, "8.0.0"). Elegir la versión correcta no se trata solo de obtener las últimas funciones. También debe considerar la matriz de compatibilidad de versiones con sus bibliotecas de controladores, la versión de Ops Manager que está utilizando y el ritmo de actualización de su equipo.

Al actualizar entre versiones principales, el campo featureCompatibilityVersion (FCV) ofrece una red de seguridad. FCV controla qué funciones de replicación y del motor de almacenamiento están activas, y puede configurarse con un valor inferior a la versión binaria. Esto permite actualizar primero los binarios, verificar la estabilidad y, posteriormente, aumentar el FCV para desbloquear nuevas funciones en un paso independiente y planificado. Si necesita revertir la actualización, un FCV inferior garantiza que los archivos de datos sigan siendo compatibles con la versión binaria anterior.

spec:
  version: "8.0.0"
  featureCompatibilityVersion: "7.0"

Para referencia,spec.version consulte y en la especificación.spec.featureCompatibilityVersion

Cómo garantizar la seguridad de su implementación

La seguridad en una implementación de MongoDB en Kubernetes tiene dos dimensiones: el cifrado del tráfico de red con TLS y la autenticación de clientes y miembros del clúster. Ambas se configuran en el bloque spec.security, y comprender cómo interactúan es fundamental para lograr una implementación segura y funcional.

Cifrado de conexiones con TLS

El cifrado TLS protege los datos en tránsito entre los clientes y los servidores MongoDB, así como entre los propios miembros del conjunto de réplicas. Al habilitar TLS, el operador de Kubernetes espera un secreto que contenga el certificado del servidor y la clave privada, y opcionalmente un ConfigMap con el certificado de la CA que lo firmó.

El campo certsSecretPrefix indica al operador de Kubernetes cómo obtener el nombre del secreto del certificado. Si se establece el prefijo en mdb y el despliegue se llama my-replica-set, el operador de Kubernetes buscará un secreto llamado mdb-my-replica-set-cert. Esta convención de nomenclatura evita conflictos cuando varios despliegues comparten un espacio de nombres, como se muestra en el siguiente ejemplo:

spec:
  security:
    certsSecretPrefix: "mdb"
    tls:
      enabled: true
      ca: "custom-ca-configmap"

Si utiliza la CA predeterminada de MongoDB, puede omitir el ca campo. De lo contrario, cargue su certificado CA en un ConfigMap y haga referencia a él aquí. Para obtener más información sobre cómo generar y administrar certificados TLS para MongoDB en Kubernetes, incluida la cert-manager integración de, consulte Configurar el cifrado y Configurar una integración de cert-manager.

Cómo elegir un mecanismo de autenticación

Además del cifrado, debes decidir cómo los clientes demuestran su identidad. El operador admite cuatro modos de autenticación, y puedes habilitar más de uno simultáneamente:

  • SCRAM (Mecanismo de Autenticación de Respuesta a Desafío con Sal) es el más sencillo de configurar. Los usuarios se autentican con un nombre de usuario y una contraseña. Funciona bien para aplicaciones que gestionan credenciales mediante inyección de variables de entorno o secretos de Kubernetes, y no requiere una infraestructura PKI.

  • X.509 utiliza certificados de cliente TLS como prueba de identidad. Esta es una buena opción si ya dispone de una infraestructura de certificados y desea evitar por completo las credenciales basadas en contraseñas. Requiere que TLS esté habilitado.

  • LDAP delega la autenticación a un servicio de directorio externo, lo que lo convierte en una opción ideal para organizaciones que gestionan las identidades de los usuarios de forma centralizada. Este modo requiere un servidor LDAP accesible a través de la red y una credencial de enlace.

  • OIDC (OpenID Connect) se integra con proveedores de identidad como Azure AD, Okta o Google para la autenticación basada en tokens. Este es el enfoque más moderno y funciona bien con los patrones de identidad de carga de trabajo en entornos de nube.

Usted configura la autenticación en spec.security.authentication:

spec:
  security:
    tls:
      enabled: true
    authentication:
      enabled: true
      modes: ["SCRAM", "X509"]
      internalCluster: "X509"

El campo internalCluster controla cómo se autentican entre sí los miembros del conjunto de réplicas. Si se establece en "X509", el tráfico entre miembros utiliza certificados X.509, incluso si los clientes se autentican con SCRAM.

Para obtener información detallada sobre los procedimientos de configuración de la autenticación, consulte la sección Habilitar autenticación.

Almacenamiento y persistencia

MongoDB es una carga de trabajo con estado, y la configuración del almacenamiento influye directamente en el rendimiento, la durabilidad y la capacidad de recuperación ante fallos. El campo spec.persistent debe establecerse en true para cualquier entorno donde la pérdida de datos sea inaceptable (prácticamente todos los entornos, excepto las pruebas desechables). Cuando la persistencia está habilitada, el operador de Kubernetes crea PersistentVolumeClaims (PVC) que sobreviven a los reinicios y reprogramaciones de los pods.

Volúmenes únicos frente a volúmenes múltiples

Por defecto, MongoDB utiliza un único volumen para todos los datos. Esto es suficiente para el desarrollo y muchas cargas de trabajo de producción, pero algunos equipos se benefician al colocar los datos, el registro y los logs en volúmenes separados. Separarlos permite asignar clases de almacenamiento más rápidas a las rutas críticas para el rendimiento, como el registro de escritura anticipada, mientras que se utiliza un almacenamiento más económico para los logs, como se muestra en el siguiente ejemplo:

spec:
  podSpec:
    persistence:
      multiple:
        data:
          storage: "200Gi"
          storageClass: "fast-ssd"
        journal:
          storage: "50Gi"
          storageClass: "fast-ssd"
        logs:
          storage: "20Gi"
          storageClass: "standard"

Si basta con un solo volumen, la configuración es más sencilla:

spec:
  podSpec:
    persistence:
      single:
        storage: "100Gi"
        storageClass: "standard"

Elegir cuidadosamente las clases de almacenamiento es especialmente importante para los clústeres fragmentados, donde cada fragmento, cada servidor de configuración y los enrutadores mongos tienen sus propias especificaciones de pod (shardPodSpec, configSrvPodSpec, mongosPodSpec). Esto permite dimensionar y estratificar el almacenamiento de forma independiente para cada componente.

Para ver el conjunto completo de campos de persistencia, consulte la sección Configuración independiente en la referencia de la especificación, que cubre spec.podSpec.persistence.single losspec.podSpec.persistence.multiple.data campos, y campos relacionados.

Asignación de recursos y plantillas de pods

Dimensionar correctamente la CPU y la memoria para los pods de MongoDB es una de las decisiones más importantes que se toman durante el despliegue, y una que probablemente se revisará a medida que evolucionen las cargas de trabajo. El operador de Kubernetes expone los controles de recursos a través de podSpec (para conjuntos de réplicas y nodos independientes) y a través de shardPodSpec, configSrvPodSpec y mongosPodSpec (para clústeres fragmentados).

Configurar tanto requests como limits para la CPU y la memoria garantiza que Kubernetes programe sus Pods en nodos con capacidad suficiente y evita que los procesos descontrolados afecten a otras cargas de trabajo en el mismo nodo. El siguiente ejemplo ilustra una configuración que puede usar como punto de partida. En esta configuración, se crean miembros del conjunto de réplicas de producción con al menos 2 núcleos de CPU y 4 GiB de memoria como solicitudes, con límites establecidos para que coincidan o superen esos valores:

spec:
  podSpec:
    podTemplate:
      spec:
        containers:
          - name: mongodb-enterprise-database
            resources:
              requests:
                cpu: "2"
                memory: "4Gi"
              limits:
                cpu: "4"
                memory: "8Gi"

Las plantillas de pods también permiten configurar etiquetas, anotaciones, tolerancias y reglas de afinidad. Las reglas de afinidad son especialmente importantes en producción, ya que controlan cómo se distribuyen los miembros del conjunto de réplicas entre los nodos de Kubernetes y los dominios de fallo.

Por ejemplo, la siguiente regla de afinidad distribuye a los miembros entre las zonas de disponibilidad para protegerlos contra interrupciones a nivel de zona:

spec:
  podSpec:
    podTemplate:
      spec:
        affinity:
          podAntiAffinity:
            requiredDuringSchedulingIgnoredDuringExecution:
              - labelSelector:
                  matchLabels:
                    app.kubernetes.io/name: my-replica-set
                topologyKey: "topology.kubernetes.io/zone"

Para obtener una lista completa de los campos de podTemplate, consulte la referencia de la especificación, en spec.podSpec.podTemplate.spec.affinity particular.

Configuración de copias de seguridad

Las copias de seguridad en Kubernetes Operator utilizan la función de copia de seguridad continua integrada en Ops Manager. Cuando está habilitada, Ops Manager captura el oplog en tiempo real y toma instantáneas periódicas, lo que permite la recuperación a un punto específico en el tiempo. Esto significa que puede restaurar a cualquier segundo dentro del período de retención configurado, no solo a la marca de tiempo de la última instantánea.

Para habilitar la copia de seguridad en un recurso de MongoDB, establezca spec.backup.mode en enabled. También puede configurar una programación de instantáneas que controle con qué frecuencia se toman las instantáneas y cuánto tiempo se conservan, como se muestra en el siguiente ejemplo:

spec:
  backup:
    mode: enabled
    snapshotSchedule:
      snapshotIntervalHours: 6
      snapshotRetentionDays: 7
      dailySnapshotRetentionDays: 30
      pointInTimeWindowHours: 24

Si su organización requiere el cifrado de los datos de respaldo en reposo, puede integrarse con un servidor de administración de claves compatible con KMIP, como se muestra en el siguiente ejemplo:

spec:
  backup:
    mode: enabled
    encryption:
      kmip:
        client:
          clientCertificatePrefix: "backup-kmip"

El indicador autoTerminateOnDeletion controla si se eliminan los datos de copia de seguridad cuando se borra el recurso de MongoDB. Establézcalo en true en entornos que no sean de producción para evitar estados de copia de seguridad huérfanos; déjelo en false en producción para que los datos de copia de seguridad sobrevivan a la eliminación accidental del recurso:

spec:
  backup:
    mode: enabled
    autoTerminateOnDeletion: false

Las etiquetas de asignación permiten controlar qué infraestructura de copia de seguridad (almacenes de oplog, almacenes de instantáneas) utiliza una implementación en particular, lo cual resulta útil cuando varias implementaciones comparten una única instancia de Ops Manager.

Para consultar la configuración completa de las copias de seguridad, vea la sección "Configuración del conjunto de réplicas" en la documentación de referencia. Para aprender a implementar la infraestructura de copias de seguridad,consulte "Configurar las copias de seguridad de la base de datos MongoDB".

Exponiendo su implementación externamente

Por defecto, las implementaciones de MongoDB en Kubernetes solo son accesibles dentro del clúster. Muchos equipos necesitan acceder a sus bases de datos desde aplicaciones que se ejecutan fuera de Kubernetes, desde herramientas cliente durante el desarrollo o desde un clúster de Kubernetes diferente en una arquitectura multirregión.

El bloque spec.externalAccess indica al operador de Kubernetes que cree servicios de Kubernetes que enruten el tráfico externo a sus pods de MongoDB. Puede elegir entre los servicios LoadBalancer, que aprovisionan balanceadores de carga del proveedor de la nube, y los servicios NodePort, que exponen puertos estáticos en cada nodo del clúster, como se muestra en el siguiente ejemplo:

spec:
  externalAccess:
    externalService:
      spec:
        type: LoadBalancer
      annotations:
        service.beta.kubernetes.io/aws-load-balancer-type: "nlb"

Para los conjuntos de réplicas, puede configurar adicionalmente externalDomain para asignar nombres de host DNS predecibles a cada miembro, lo que simplifica la construcción de la cadena de conexión en el lado del cliente:

spec:
  externalAccess:
    externalDomain: "mongodb.example.com"
    externalService:
      spec:
        type: LoadBalancer

Para obtener más información, consulte Conectarse a un recurso de base de datos MongoDB desde fuera de Kubernetes.

Ajuste de parámetros del servidor MongoDB

No todos los ajustes de optimización de MongoDB tienen un campo de primera clase en el recurso personalizado. Para aquellos ajustes que no estén incluidos en el esquema explícito del operador de Kubernetes, el bloque spec.additionalMongodConfig permite pasar opciones de configuración mongod arbitrarias. Estas se traducen directamente a la configuración del servidor que aplica Ops Manager.

Los usos comunes de additionalMongodConfig incluyen ajustar el tamaño de la caché de WiredTiger, restringir las versiones del protocolo TLS o cambiar el puerto de escucha, como se muestra en el siguiente ejemplo:

spec:
  additionalMongodConfig:
    net:
      tls:
        disabledProtocols: "TLS1_0,TLS1_1"
    storage:
      wiredTiger:
        engineConfig:
          cacheSizeGB: 4

En un clúster fragmentado, cada componente (fragmento, servidor de configuración, mongos) tiene su propio additionalMongodConfig campo, lo que permite ajustarlos de forma independiente. Para consultar la lista completa de opciones compatibles, vea Parámetros del servidor MongoDB en el Manual de MongoDB.

Configuración del agente de MongoDB

Cada Pod de MongoDB ejecuta un Agente de MongoDB que gestiona el proceso mongod, se encarga de las tareas de automatización e informa sobre su estado al Administrador de Operaciones. Puede ajustar el comportamiento del Agente de MongoDB mediante spec.agent, incluidas opciones de inicio como límites de rotación de registros y tiempos de espera de conexión, como se muestra en el siguiente ejemplo:

spec:
  agent:
    startupOptions:
      maxLogFiles: "10"
      maxLogFileSize: "100"
      dialTimeout: "20"

El campo spec.logLevel establece el nivel de detalle del registro del agente de MongoDB. Durante la configuración inicial o la resolución de problemas, DEBUG puede ser invaluable; en producción estable, INFO o WARN evitan un volumen de registro excesivo:

spec:
  logLevel: "DEBUG"

Para obtener información completa sobre la configuración relacionada con el agente de MongoDB, consulte la referencia de la especificación.

Implementaciones multi-clúster

Para los equipos que necesitan distribuir una única implementación de MongoDB en varios clústeres de Kubernetes, ya sea por redundancia geográfica, recuperación ante desastres o soberanía de datos, el Operador de Kubernetes admite una topología de clústeres múltiples. Al establecer spec.topology en MultiCluster, se le indica al Operador de Kubernetes que los miembros del conjunto de réplicas definidos en spec.clusterSpecList residen en diferentes clústeres de Kubernetes, como se muestra en el siguiente ejemplo:

spec:
  topology: MultiCluster
  clusterSpecList:
    - clusterName: "cluster-us-east"
      members: 2
    - clusterName: "cluster-us-west"
      members: 2
    - clusterName: "cluster-eu-west"
      members: 1

Las implementaciones en clústeres múltiples requieren requisitos adicionales, como la interconexión entre clústeres y la configuración de una malla de servicios o un servidor DNS externo. Antes de continuar, revise los requisitos y la arquitectura para clústeres múltiples.

Para obtener información sobre los campos de especificación de clústeres múltiples, consulte la Especificación de clústeres múltiples de Kubernetes.

Cómo mantener la configuración personalizada de sus recursos de MongoDB a lo largo del tiempo.

Un recurso personalizado de MongoDB no es un artefacto de un solo uso. A medida que evolucionen los requisitos de su equipo, deberá aumentar el número de miembros, agregar particiones, habilitar copias de seguridad, rotar certificados TLS, actualizar versiones de MongoDB o ajustar los límites de recursos. El operador de Kubernetes está diseñado para esto: usted actualiza el manifiesto YAML, lo aplica con kubectl apply y el operador de Kubernetes concilia los cambios de forma incremental.

Algunas pautas para una iteración segura:

  • Aumente el número de miembros gradualmente. Agregar o eliminar miembros del conjunto de réplicas uno por uno reduce el riesgo de interrupción de las elecciones.

  • Actualiza las versiones en dos pasos. Primero, incrementa la versión binaria manteniendo featureCompatibilityVersion en el nivel anterior, luego aumenta FCV después de verificar la estabilidad.

  • Rote los certificados antes de su vencimiento. Los certificados TLS tienen una vida útil limitada. Planifique un proceso de rotación, idealmente automatizado cert-manager con, y pruébelo primero en un entorno que no sea de producción.

  • Pruebe cuidadosamente los cambios de almacenamiento. Algunos cambios (como el cambio de clases de almacenamiento) pueden requerir la migración manual de volúmenes. Valide siempre en un clúster de prueba.

  • Supervise el estado del recurso. Después de cualquier cambio, valide que el Operador de Kubernetes haya conciliado correctamente los cambios comprobando el estado del recurso con kubectl get mdb y revisando los registros del Operador de Kubernetes en busca de errores de conciliación.

Para obtener instrucciones prácticas sobre cómo modificar una implementación,consulte Editar un recurso de base de datos.

Ponerlo todo junto

El siguiente ejemplo combina los conceptos tratados en esta página en una configuración de conjunto de réplicas lista para producción. Incluye TLS, autenticación SCRAM, copia de seguridad, programación anti-afinidad, división de volúmenes de datos/registro/registro y ajuste de WiredTiger:

apiVersion: mongodb.com/v1
kind: MongoDB
metadata:
  name: prod-replica-set
  namespace: mongodb-production
spec:
  type: ReplicaSet
  members: 3
  version: "8.0.0"
  featureCompatibilityVersion: "8.0"
  opsManager:
    configMapRef:
      name: prod-project-configmap
  credentials: prod-credentials
  persistent: true
  security:
    certsSecretPrefix: "prod-mdb"
    tls:
      enabled: true
      ca: "prod-ca-configmap"
    authentication:
      enabled: true
      modes: ["SCRAM"]
      internalCluster: "X509"
  backup:
    mode: enabled
    autoTerminateOnDeletion: false
    snapshotSchedule:
      snapshotIntervalHours: 6
      snapshotRetentionDays: 7
      dailySnapshotRetentionDays: 30
      pointInTimeWindowHours: 48
  podSpec:
    persistence:
      multiple:
        data:
          storage: "500Gi"
          storageClass: "fast-ssd"
        journal:
          storage: "100Gi"
          storageClass: "fast-ssd"
        logs:
          storage: "50Gi"
          storageClass: "standard"
    podTemplate:
      spec:
        containers:
          - name: mongodb-enterprise-database
            resources:
              requests:
                cpu: "2"
                memory: "8Gi"
              limits:
                cpu: "4"
                memory: "16Gi"
        affinity:
          podAntiAffinity:
            requiredDuringSchedulingIgnoredDuringExecution:
              - labelSelector:
                  matchLabels:
                    app.kubernetes.io/name: prod-replica-set
                topologyKey: "topology.kubernetes.io/zone"
  additionalMongodConfig:
    net:
      tls:
        disabledProtocols: "TLS1_0,TLS1_1"
    storage:
      wiredTiger:
        engineConfig:
          cacheSizeGB: 8

Tip

En esta página