El recurso personalizado de MongoDB es la forma principal de definir y gestionar las implementaciones de MongoDB a través del operador de Kubernetes. En lugar de configurar las instancias de MongoDB directamente, declare el estado deseado en un manifiesto YAML y el operador conciliará el estado real de su clúster para que coincida. Esta guía le guiará a través de los bloques de creación conceptuales de ese manifiesto, lo que le ayudará a comprender no solo lo que hace cada área de configuración, sino también por qué y cuándo podría necesitarla al planificar una implementación que se adapte a los requisitos de su equipo.
Ya sea que esté configurando un set de réplicas de desarrollo por primera vez o iterando en un clúster particionado de producción, las decisiones descritas aquí forman la base de una implementación de MongoDB estable, segura y de buen rendimiento en Kubernetes.
Para obtener la especificación completa campo por campo, consulte la Especificación de recursos de base de datos de MongoDB.
Elección de un tipo de implementación
La primera decisión que debe tomar es qué tipo de implementación de MongoDB crear. El campo spec.type acepta tres valores, cada uno dirigido a un conjunto diferente de cargas de trabajo y requisitos operativos. Comprender las compensaciones entre ellos es esencial antes de guardar una sola línea de YAML.
Las instancias autónomas ejecutan un único proceso de mongod. Son más adecuadas para el desarrollo local, los escenarios de prueba o la evaluación de funcionalidades en las que la redundancia no es un problema. Dado que una implementación autónoma no tiene replicación, no admite la conmutación por error automática y no se recomienda para los datos de producción.
Los sets de réplicas son la topología de producción por defecto para MongoDB. Un set de réplicas consta de varios nodos mongod (normalmente tres o más) que mantienen copias idénticas de sus datos. Si el primario/a falla, los nodos restantes eligen un nuevo primario/a sin intervención manual. La elección de un set de réplicas le brinda alta disponibilidad, escalabilidad de lectura a través de lecturas secundarias y la capacidad de realizar mantenimiento continuo. Para la mayoría de los equipos, aquí es donde comienza:
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úster particionado distribuyen los datos entre varias particiones, cada una de las cuales es un set de réplicas. Delante de las particiones se encuentran los enrutadores mongos que dirigen el tráfico del cliente y un set de réplicas de servidor de configuración dedicado que almacena los metadatos del clúster. Si su conjunto de datos está creciendo más allá de lo que un solo set de réplicas puede servir de manera eficiente, o necesita escalar los guardados horizontalmente, un clúster es la opción correcta. La configuración es más compleja porque debe especificar los recuentos de particiones, mongod instancias por partición, 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 todos los detalles sobre cada campo específico de cada tipo de implementación, consulta las secciones autónomo, set de réplicas y clúster particionado de la referencia de especificaciones.
Conexión a Ops Manager
Cada recurso personalizado de MongoDB debe estar vinculado a un proyecto de MongoDB Ops Manager. Esta conexión es la forma en que el operador de Kubernetes registra su implementación para la supervisión, la automatización y la copia de seguridad. Dos elementos de configuración hacen que la conexión funcione: un ConfigMap que identifica su proyecto y un Secret que almacena sus credenciales de API.
El ConfigMap le indica al operador de Kubernetes en qué proyecto de MongoDB Ops Manager debe colocar la implementación. Como mínimo, debe contener un projectName y un baseUrl que apunten a su instancia de MongoDB Ops Manager. Opcionalmente, puede anclar la implementación 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 de 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, haga referencia a ambos en su MongoDB CR:
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.
Versión de MongoDB y compatibilidad de funcionalidades
El campo spec.version establece la versión del servidor de 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 funcionalidades. También debe considerar la matriz de compatibilidad de versiones con sus librerías de driver, la versión de Ops Manager que está ejecutando y la cadencia de actualización de su equipo.
Al actualizar entre versiones principales, el campo featureCompatibilityVersion (compatibilidad de características entre versiones) le proporciona una red de seguridad. La compatibilidad de características entre versiones controla qué funcionalidades de replicación y motor de almacenamiento están activas, y se puede establecer en un valor inferior a la propia versión binaria. Esto le permite actualizar primero los binarios, verificar la estabilidad y, a continuación, aumentar la compatibilidad de características entre versiones para desbloquear nuevas funcionalidades en un paso independiente y deliberado. Si necesita revertir, una compatibilidad de características entre versiones más baja 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, consulte spec.version y spec.featureCompatibilityVersion en la especificación.
Protección de la implementación
La seguridad en una implementación de MongoDB en Kubernetes tiene dos dimensiones: cifrar el tráfico de red con TLS y autenticar clientes y nodos del clúster. Ambos se configuran en el bloque spec.security, y comprender cómo interactúan es fundamental para obtener una implementación que sea segura y funcional.
Cifrado de conexiones con TLS
El cifrado TLS protege los datos en tránsito entre los clientes y los servidores de MongoDB, y entre los propios set de réplicas. Cuando habilitas TLS, el operador de Kubernetes espera un secreto que contenga el certificado del servidor y la llave privada, y opcionalmente un ConfigMap con el certificado de CA que lo firmó.
El campo certsSecretPrefix le indica al operador de Kubernetes cómo derivar el nombre del secreto del certificado. Si establece el prefijo en mdb y su implementación se denomina my-replica-set, el operador de Kubernetes busca un secreto denominado mdb-my-replica-set-cert. Esta convención de nomenclatura evita colisiones cuando varias implementaciones comparten un namespace, como se muestra en el siguiente ejemplo:
spec: security: certsSecretPrefix: "mdb" tls: enabled: true ca: "custom-ca-configmap"
Si utiliza el CA de MongoDB por defecto, puede omitir el campo ca. De lo contrario, cargue su certificado CA en un ConfigMap y haga referencia a él aquí. Para obtener más información sobre la generación y administración de certificados TLS para MongoDB en Kubernetes, incluida la integración de cert-manager, consulte Configurar cifrado y Configurar una integración de cert-manager.
Elección de un mecanismo de autenticación
Más allá del cifrado, debe decidir cómo los clientes prueban su identidad. El operador admite cuatro modos de autenticación y puede habilitar más de uno simultáneamente:
SCRAM (Mecanismo de autenticación de respuesta a desafío salado) es el más fácil de configurar. Los usuarios se autentican con un nombre de usuario y una contraseña. Funciona bien para aplicaciones que gestionan credenciales mediante la inyección de variables de entorno o los 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 cuando ya tienes una infraestructura de certificados y quieres evitar por completo las credenciales basadas en contraseñas. Requiere que TLS esté habilitado.
LDAP delega la autenticación en un servicio de directorio externo, lo que lo convierte en una opción natural para las 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 patrones de identidad de carga de trabajo en entornos de nube.
Configure 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 los nodos del set de réplicas se autentican entre sí. Si se establece en "X509", el tráfico de nodo a nodo utiliza certificados X.509, incluso si los clientes se autentican con SCRAM.
Para obtener procedimientos detallados de configuración de autenticación, consulte Habilitar autenticación.
Almacenamiento y persistencia
MongoDB es una carga de trabajo con estado, y la forma en que configuras el almacenamiento afecta directamente al rendimiento, la durabilidad y la capacidad de recuperación ante fallos. El campo spec.persistent debe establecerse en true para cualquier entorno en el que la pérdida de datos sea inaceptable (que es esencialmente cualquier entorno más allá de las pruebas desechables). Cuando la persistencia está habilitada, el operador de Kubernetes crea PersistentVolumeClaims (PVC) que sobreviven a los reinicios y la reprogramación de Pod.
Volúmenes únicos frente a múltiples
Por defecto, MongoDB utiliza un solo volumen para todos los datos. Esto es adecuado para el desarrollo y muchas cargas de trabajo de producción, pero algunos equipos se benefician de colocar datos, la bitácora y los registros en volúmenes separados. Separarlos le permite asignar clases de almacenamiento más rápidas a rutas críticas para el rendimiento, como la bitácora de escritura anticipada, mientras utiliza un almacenamiento más económico para los registros, 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 un solo volumen es suficiente, la configuración es más sencilla:
spec: podSpec: persistence: single: storage: "100Gi" storageClass: "standard"
La elección cuidadosa de las clases de almacenamiento es especialmente importante para los clústeres particionados, donde cada partición, cada servidor de configuración y los enrutadores mongos tienen su propia especificación de pod (shardPodSpec, configSrvPodSpec, mongosPodSpec). Esto le permite dimensionar y organizar por niveles el almacenamiento de forma independiente para cada componente.
Para ver el conjunto completo de campos de persistencia, consulta la sección Configuración autónoma en la referencia de especificaciones, que cubre spec.podSpec.persistence.single, spec.podSpec.persistence.multiple.data y los campos relacionados.
Asignación de recursos y plantillas de pods
El dimensionamiento correcto de la CPU y la memoria para los pods de MongoDB es una de las decisiones más importantes que se toman en el momento de la implementación, 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 set de réplicas y autónomos) y a través de shardPodSpec, configSrvPodSpec y mongosPodSpec (para clústeres particionados).
La configuración de requests y limits para la CPU y la memoria garantiza que Kubernetes programe sus pods en nodos con la capacidad adecuada y evita que los procesos descontrolados afecten otras cargas de trabajo en el mismo nodo. El siguiente ejemplo ilustra una configuración que puede utilizar como punto de partida. En esta configuración, crea set 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 Pod también le permiten establecer etiquetas, anotaciones, tolerancias y reglas de afinidad. Las reglas de afinidad son particularmente importantes en la producción, ya que controlan cómo se distribuyen los nodos del set de réplicas en los nodos de Kubernetes y los dominios de error.
Por ejemplo, la siguiente regla de afinidad distribuye los nodos en las zonas de disponibilidad para protegerlos contra las interrupciones del servicio 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 especificaciones, en particular spec.podSpec.podTemplate.spec.affinity.
Configuración de copias de seguridad
Las copias de seguridad en Kubernetes Operator utilizan la capacidad de copia de seguridad continua integrada en Ops Manager. Cuando está habilitado, Ops Manager captura el oplog en tiempo real y toma snapshots periódicos, lo que en conjunto le brinda una recuperación a un momento dado. Esto significa que puede restaurar a cualquier segundo dentro de la ventana de retención configurada, no solo a la marca de tiempo del último snapshot.
Para habilitar la copia de seguridad en un recurso de MongoDB, establezca spec.backup.mode en enabled. También puede configurar un cronograma de snapshot que controle la frecuencia con la que se toman los snapshot y cuánto tiempo se retienen, 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 copia de seguridad en reposo, puede integrarse con un servidor de gestió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 los datos de copia de seguridad se limpian cuando se elimina el recurso de MongoDB. Establézcalo en true en entornos que no sean de producción para evitar el estado de copia de seguridad huérfano; déjelo en false en producción para que los datos de copia de seguridad sobrevivan a la eliminación accidental de recursos:
spec: backup: mode: enabled autoTerminateOnDeletion: false
Las etiquetas de asignación le permiten controlar qué infraestructura de copia de seguridad (almacenamiento de oplog, almacenamiento de snapshot) utiliza una implementación en particular, lo que resulta útil cuando varias implementaciones comparten una única instancia de Ops Manager.
Para ver el conjunto completo de configuraciones de copia de seguridad, consulte la sección Configuraciones del set de réplicas en la referencia de especificaciones. Para obtener información sobre cómo implementar la infraestructura de copia de seguridad, consulte Configurar copias de seguridad de la base de datos de MongoDB.
Exponer 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 de cliente durante el desarrollo o desde un clúster de Kubernetes diferente en una arquitectura multiregional.
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 servicios LoadBalancer, que aprovisionan balanceadores de carga de proveedores de nube, y 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 set de réplicas, también puede configurar externalDomain para asignar nombres de host DNS predecibles a cada nodo, lo que simplifica la construcción de cadenas 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 Conéctese a un recurso de base de datos MongoDB desde fuera de Kubernetes.
Ajuste de los parámetros de MongoDB Server
No todas las configuraciones de ajuste de MongoDB tienen un campo de primera clase en el recurso personalizado. Para cualquier configuración que no esté incluida en el esquema explícito del operador de Kubernetes, el bloque spec.additionalMongodConfig le permite pasar opciones de configuración de mongod arbitrarias. Estas se traducen directamente a la configuración del servidor que aplica MongoDB 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 particionado, cada componente (partición, servidor de configuración, mongos) tiene su propio campo additionalMongodConfig, por lo que puede ajustarlos de forma independiente. Para obtener la lista completa de opciones admitidas, consulte MongoDB Server Parameters en el manual de MongoDB.
Configuración de MongoDB Agent
Cada pod de MongoDB ejecuta un MongoDB Agent que gestiona el proceso de mongod, gestiona las tareas de automatización e informa del estado a MongoDB Ops Manager. Puede ajustar el comportamiento de MongoDB Agent a través de spec.agent, incluidas las opciones de inicio como los límites de rotación de registros y los 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 verbosidad del registro de MongoDB Agent. Durante la configuración inicial o la resolución de problemas, DEBUG puede ser invaluable; en la producción en estado estable, INFO o WARN evita un volumen excesivo de registros:
spec: logLevel: "DEBUG"
Para obtener una configuración completa relacionada con el agente de MongoDB, consulte la referencia de especificaciones.
Implementaciones multi-clúster
Para los equipos que necesitan distribuir una única implementación de MongoDB en varios clústeres de Kubernetes, quizás para redundancia geográfica, recuperación ante desastres o soberanía de datos, el operador de Kubernetes admite una topología de varios clústeres. Establecer spec.topology en MultiCluster indica al operador de Kubernetes que los set de réplicas definidos en spec.clusterSpecList viven 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 de clústeres múltiple introducen requisitos previos adicionales, como redes entre clústeres y configuración de malla de servicios o DNS externo. Antes de continuar, revise los requisitos previos de clústeres múltiple y la arquitectura de clústeres múltiple.
Para los campos de especificación de clúster múltiple, consulte la especificación de clúster de Kubernetes múltiple.
Mantenimiento de la configuración de recursos personalizados de MongoDB a lo largo del tiempo
Un recurso personalizado de MongoDB no es un artefacto único. A medida que evolucionen los requisitos de su equipo, escalará los nodos, agregará particiones, habilitará la copia de seguridad, rotará los certificados TLS, actualizará las versiones de MongoDB o ajustará los límites de recursos. El operador de Kubernetes está diseñado para esto: 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:
Escale los nodos gradualmente. Agregar o remover miembros del set de réplicas uno a la vez reduce el riesgo de interrupción de la elección.
Actualice las versiones en dos pasos. Aumente primero la versión binaria mientras mantiene
featureCompatibilityVersionen el nivel anterior, luego aumente la compatibilidad de características entre versiones después de verificar la estabilidad.Rote los certificados antes de que caduquen. Los certificados TLS tienen una vida útil finita. Planifique un proceso de rotación, idealmente automatizado con
cert-manager, y pruébelo primero en un entorno que no sea de producción.Pruebe los cambios de almacenamiento con cuidado. Algunos cambios de almacenamiento (como el cambio de clases de almacenamiento) pueden requerir una migración manual del volumen. Valide siempre en un clúster de preproducción.
Supervise el estado del recurso. Después de cualquier cambio, valide que el operador de Kubernetes haya conciliado sus cambios correctamente comprobando el estado del recurso con
kubectl get mdby revisando los registros del operador de Kubernetes para ver si hay errores de conciliación.
Para conocer los procedimientos prácticos para modificar una implementación, consulte Editar un recurso de base de datos.
Poniéndolo todo junto
El siguiente ejemplo combina los conceptos tratados en esta página en una configuración de set de réplicas lista para producción. Incluye TLS, autenticación SCRAM, copia de seguridad, programación antiafinidad, volúmenes de datos/bitácora/registro divididos 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
Especificación de recursos de la base de datos de MongoDB — Referencia completa del campo CR de MongoDB
Implementar un set de réplicas — Implementación de set de réplicas paso a paso
Implementar un clúster particionado — Implementación paso a paso de un clúster particionado
Configure el cifrado — Detalles de configuración de TLS
Habilitar autenticación — Mecanismos de autenticación
Configurar copias de seguridad de bases de datos de MongoDB — Procedimientos de copia de seguridad
Conéctese a un recurso de base de datos MongoDB desde fuera de Kubernetes — Configuración de acceso externo
Especificación de recursos de clústeres múltiple de Kubernetes — Referencia de campo de clústeres múltiple