Arquitectura de bases 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 y el número de pods que se crearán. El operador de Kubernetes se basa en el controlador StatefulSet de Kubernetes para crear un pod para esta instancia independiente de la base de datos MongoDB.

Set de réplicas

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

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 ShardedCluster tipo del recurso MongoDB consta de uno o más servidores de configuración, instancias y miembros demongos fragmentos.

Para el recurso ShardedCluster, el operador de Kubernetes implementa:

• Un conjunto con estado para todos los servidores de configuración

• Un StatefulSet para todas las mongos instancias

• 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 fragmentado.

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

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

• MongoDB especificaciones de recursos personalizados

• 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 personalizados

• 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 crea o cambia una especificación de recurso de MongoDB, o cuando realiza cambios en un ConfigMap o secreto asociado, el operador de Kubernetes realiza las siguientes acciones para conciliar los cambios:

1. Lee la configuración de proyecto y organización requerida del ConfigMap que utilizó para crear o conectarse 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

   Al configurar el operador de Kubernetes para recursos de MongoDB, se crea un ConfigMap para conectar o crear el proyecto de Cloud Manager u Ops Manager. El agente de MongoDB usa este ConfigMap para iniciar o modificar la implementación del recurso de 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 de recursos

   • 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 configura el operador de Kubernetes para los recursos de MongoDB,crea este secreto en Kubernetes o lo almacena en su 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 ConfigMap. Debe proporcionar un valor en el campo orgId.

   • Lee un nombre de proyecto especificado en el campo projectName en ConfigMap o, si no especificó un valor para este campo opcional, crea este proyecto en Cloud Manager o 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 todos los certificados TLS y X..509

   • Si TLS está habilitado para un conjunto de réplicas, el operador de Kubernetes busca certificados proporcionados en el <prefix>-<resource-name>-cert secreto o en su herramienta de almacenamiento de secretos.

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

     • <prefix>-<resource-name>-x-cert para cada miembro del fragmento.

     • <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 secreta.

   • 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. La cantidad 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 mongod instancias.

   • 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 Agente MongoDB recibe la configuración por primera vez, descarga los binarios de MongoDB con la versión especificada en spec.version desde Internet o desde Ops Manager si el Agente MongoDB 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).

   • Una vez que el agente MongoDB recibe la configuración de automatización, inicia una instancia en el pod mongod 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 de Kubernetes actualiza la configuración de automatización que recibió del agente MongoDB con los cambios de las especificaciones y la envía a Cloud Manager o 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 a que cada agente de MongoDB informe que alcanzó el estado 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 establece ClusterIP en 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 de Kubernetes utiliza estas convenciones de nomenclatura:

     • Paramongosinstancias, el operador de Kubernetes usa el nombre especificado enspec.serviceo el nombre del recurso con -svc agregado.

     • Para los servidores de configuración, el operador de Kubernetes usa el nombre del recurso con -cs agregado.

     • Para cada fragmento, el operador de Kubernetes utiliza el nombre del recurso con -sh agregado.

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