Arquitectura de la base de datos MongoDB en Kubernetes

Autónomo

Para el Standalone tipo del recurso de base de datos MongoDB, el operador de Kubernetes implementa un conjunto de réplicas con un solo miembro en el clúster de Kubernetes como un StatefulSet.

El Operador de Kubernetes crea el StatefulSet, que contiene la especificación del Pod con el número de Pods a crear. El operador de Kubernetes depende del controlador StatefulSet de Kubernetes para crear un pod para esta instancia autónomo de la base de datos de MongoDB.

Set de réplicas

Para el tipo ReplicaSet del recurso MongoDB, el operador de Kubernetes implementa un set de réplicas en el clúster de Kubernetes como un StatefulSet, con un número de miembros igual al valor de spec.members.

El operador de Kubernetes se basa en el controlador StatefulSet de Kubernetes para crear un pod en el StatefulSet para cada miembro del conjunto de réplicas.

Cada pod en el StatefulSet ejecuta una instancia del agente MongoDB.

Clúster fragmentado

El tipo ShardedCluster del recurso de MongoDB consiste en uno o más Servidores de Configuración, mongos instancias y nodos de particiones.

Para el recurso ShardedCluster, el Operador de Kubernetes implementa:

• Un StatefulSet para todos los servidores de configuración

• Un único StatefulSet para todas las instancias de mongos

• Un StatefulSet para cada nodo de partición

El Operador de Kubernetes se basa en el Controlador StatefulSet de Kubernetes para crear un Pod en cada uno de los StatefulSets creados para el clúster sharded.

Diagrama de una conciliación de un conjunto de réplicas

El siguiente diagrama describe cómo se comporta el Operador Kubernetes si realiza cambios en un set de réplicas:

• MongoDB especificaciones de recursos personalizadas

• Mapa de configuración asociado

• Secretos asociados almacenados en tu herramienta de almacenamiento de secretos

haga clic para ampliar

Diagrama de una reconciliación de clúster fragmentado

El siguiente diagrama describe cómo se comporta el operador de Kubernetes si realiza cambios en un clúster fragmentado:

• MongoDB especificaciones de recursos personalizadas

• Mapa de configuración asociado

• Secretos asociados almacenados en tu herramienta de almacenamiento de secretos

haga clic para ampliar

Flujo de trabajo de conciliación

Cuando creas o modificas una especificación de recurso de MongoDB, o cuando realizas cambios en una ConfigMap o secreto asociados, el operador de Kubernetes realiza las siguientes acciones para conciliar los cambios:

1. Lee la configuración requerida de la organización y del proyecto desde el ConfigMap que se utilizó para crear o conectar a un proyecto en el operador de Kubernetes.

   Si modificas tu especificación de recursos, el operador de Kubernetes identifica que se realizó el cambio y revisa la especificación de la ConfigMap especificada en spec.opsManager.configMapRef.name.

   Nota

   Cuando configuras el Operador de Kubernetes para recursos de MongoDB, creas un ConfigMap para conectar o crear tu proyecto de Cloud Manager u Ops Manager. El Agente de MongoDB utiliza este ConfigMap para iniciar o realizar cambios en la implementación del recurso MongoDB.

2. Lee la configuración de autenticación para Cloud Manager o Ops Manager desde el secreto especificado en:

   • spec.credentials en la especificación del recurso

   • Tu herramienta de almacenamiento secreta

   Este secreto almacena las claves de API de Cloud Manager o las claves de API de Ops Manager necesarias para que el operador de Kubernetes se autentique en Cloud Manager o Ops Manager.

   Nota

   Cuando configuras el Operador de Kubernetes para los recursos de MongoDB, ya sea crea este secreto en Kubernetes o almacenas este secreto en tu herramienta de almacenamiento de secretos.

3. El Operador de Kubernetes se conecta a Cloud Manager u Ops Manager y realiza las siguientes acciones:

   • Lee la organización del campo orgId en el ConfigMap. Debe proporcionar un valor en el campo orgId.

   • Lee un nombre de proyecto especificado en el campo projectName en el ConfigMap o, si no se especificó un valor para este campo opcional, crea este proyecto en Cloud Manager u Ops Manager si no existe.

   • Comprueba que el <project-id>-group-secret secreto creado por el operador de Kubernetes para el agente de MongoDB existe. El operador de Kubernetes lee el secreto desde la herramienta de almacenamiento de secretos o lo crea con las claves de API de Ops Manager o Cloud Manager.

   • Se registra como observador del ConfigMap y de este secreto. Esto permite que el operador de Kubernetes reaccione a los cambios que realice en el ConfigMap o en el secreto.

4. El operador de Kubernetes verifica cualquier certificado TLS y X.509.

   • Si TLS está habilitado para un set de réplicas, el operador de Kubernetes buscará los certificados proporcionados en el secreto <prefix>-<resource-name>-cert o en tu herramienta de almacenamiento secreto.

   • Si TLS está habilitado para un clúster particionado, el Operador de Kubernetes busca certificados en estos secretos:

     • <prefix>-<resource-name>-x-cert para cada nodo de la partición.

     • <prefix>-<resource-name>-config-cert para todos los servidores de configuración.

     • <prefix>-<resource-name>-mongos-cert para todas las mongos instancias.

     • Tu herramienta de almacenamiento secreto.

   • Si X.509 o la autenticación interna con X.509 y TLS están habilitadas, el operador de Kubernetes verifica que sus certificados contengan la configuración requerida.

5. El Operador de Kubernetes localiza y actualiza los StatefulSets necesarios o crea nuevos StatefulSets si no existen. El número de StatefulSets depende del tipo de recurso de MongoDB.

   • Para los recursos ReplicaSet o Standalone, el operador de Kubernetes crea un único StatefulSet.

   • Para un recurso ShardedCluster, el operador de Kubernetes crea:

     • Un StatefulSet para todos los servidores de configuración.

     • Un StatefulSet para todas las mongos instancias.

     • Un StatefulSet para cada miembro del fragmento.

     En este punto, cada Pod ejecuta al menos una instancia de MongoDB Agent, pero aún no contiene instancias de mongod.

   • Cada instancia del Agente MongoDB comienza a sondear Cloud Manager o Ops Manager para recibir la configuración de automatización de MongoDB.

     Nota

     Contenedores no estáticos: Cuando el MongoDB Agent recibe la configuración por primera vez, descarga los binarios de MongoDB con la versión especificada en spec.version de Internet, o desde Ops Manager si el MongoDB Agent está configurado en modo local.

     Contenedores estáticos: Los contenedores estáticos no descargan binarios durante la ejecución. Para obtener más información, consulta Contenedores estáticos (Vista previa pública).

   • Después de que el MongoDB Agent recibe la configuración de automatización, inicia una instancia mongod en el Pod correspondiente.

   • Para cada pod de cada StatefulSet que crea el recurso personalizado de MongoDB, excepto StatefulSets, el operador mongos de Kubernetes genera una notificación de volumen persistente. Puede anular este comportamiento configurando spec.persistent a false en la especificación del recurso.

6. El Operador Kubernetes actualiza la configuración de automatización que recibió del MongoDB Agent con los cambios de las especificaciones y la envía a Cloud Manager u Ops Manager.

   • Cada agente de MongoDB para cada pod sondea nuevamente a Cloud Manager o Ops Manager y recibe la configuración de automatización actualizada.

   • Si cambia algún campo en la especificación, el operador de Kubernetes realiza una actualización continua de los StatefulSets para iniciar nuevos Pods que coincidan con la nueva especificación.

   • El operador de Kubernetes espera que cada MongoDB Agent informe que ha alcanzado el estado de listo.

   Nota

   Si cambia la configuración de seguridad de un recurso de base de datos o reduce la escala de un StatefulSet existente, el operador de Kubernetes ejecuta el paso 6 antes de ejecutar el 5 paso.

7. El operador de Kubernetes actualiza los servicios de Kubernetes o, para un nuevo recurso de MongoDB, crea los servicios necesarios para cada nuevo StatefulSet.

   Para el ServiceType ClusterIP, el operador de Kubernetes define ClusterIP a None y realiza estas acciones:

   • Crea este servicio si no existe.

   • Para recursos de ReplicaSet o Standalone, el Operador de Kubernetes nombra el servicio con el nombre del recurso personalizado, con -svc agregado al mismo.

   • Para un recurso ShardedCluster, el Operador Kubernetes utiliza estas convenciones para los nombres:

     • Para instancias de mongos, el operador de Kubernetes utiliza el nombre especificado en spec.service o el nombre del recurso con -svc añadido.

     • Para los servidores de configuración, el Operador Kubernetes utiliza el nombre del recurso con -cs añadido al final.

     • Para cada partición, el Operador de Kubernetes utiliza el nombre del recurso con -sh añadido al final.

   • Para el puerto, el operador de Kubernetes utiliza el puerto predeterminado 27017 o el .net.port especificado spec.additionalMongodConfig en.