El recurso personalizado de MongoDB define las implementaciones de bases de datos que administra el Operador de Kubernetes. Las especificaciones de su recurso personalizado definen estos recursos, y el Operador de Kubernetes los supervisa. Cuando actualiza la especificación de un recurso, el Operador de Kubernetes envía los cambios a Ops Manager, que modifica la configuración de la implementación de MongoDB.
El CRD MongoDB admite tres tipos de despliegue. El siguiente diagrama ilustra la composición de cada uno:
Advertencia
El operador de Kubernetes no es compatible con nodos árbitros.
Recurso independiente
Aunque puedes implementar un recurso Standalone, te recomendamos que implementes un recurso ReplicaSet con un solo miembro, ya que un conjunto de réplicas te permite agregar miembros en el futuro. En Kubernetes, un recurso Standalone es equivalente a un recurso ReplicaSet con un solo miembro.
Para un recurso Standalone, el operador de Kubernetes implementa un conjunto de réplicas con un único miembro como StatefulSet. El operador de Kubernetes crea el StatefulSet, que contiene la especificación del Pod, y se basa en el controlador StatefulSet de Kubernetes para crear el Pod para esta única instancia mongod.
Recurso de conjunto de réplicas
Para un ReplicaSet recurso, el operador de Kubernetes implementa un conjunto de réplicas como un StatefulSet, con un número de miembros igual al valor de. El operador de Kubernetes se basa en el controlador StatefulSet de Kubernetes para crear un Pod por cada miembro. Cada Pod ejecuta una instancia del agente de MongoDB que gestiona spec.members el mongod proceso en ese Pod.
Recurso de clúster fragmentado
Un recurso ShardedCluster consta de servidores de configuración, instancias mongos y miembros de fragmento. El operador de Kubernetes implementa:
Un único StatefulSet para todos los servidores de configuración.
Un StatefulSet para todas las instancias
mongosUn StatefulSet para cada fragmento
El operador de Kubernetes se basa en el controlador de StatefulSet de Kubernetes para crear un Pod en cada StatefulSet. Para un clúster fragmentado con 2 fragmentos, esto significa 4 StatefulSets en total (1 para servidores de configuración + 1 para mongos + 2 para fragmentos).
Tipo de implementación | StatefulSets | Tamaño de StatefulSet |
|---|---|---|
Autónomo | 1 | 1 Pod |
Set de réplicas | 1 | 1 Pod por nodo |
Clúster fragmentado | <numberOfShards> + 2 | 1 Pod por |
Reconciliación de recursos de MongoDB
Cuando se aplica una especificación de recurso personalizado de MongoDB, el operador de Kubernetes implementa cada recurso como un StatefulSet. A continuación, el operador de Kubernetes entra en un bucle de reconciliación continua:
Lee la configuración del proyecto desde el ConfigMap especificado
spec.opsManager.configMapRef.nameen.Lee las credenciales de la API desde el secreto especificado en
spec.credentialso desde su herramienta de almacenamiento de secretos.Se conecta a Ops Manager y realiza lo siguiente:
Lee la organización desde el
orgIden el ConfigMap.Lee o crea el proyecto especificado en
projectName.Verifica que el elemento
<project-id>-group-secretexista o lo crea con claves API de Ops Manager.Registra al operador de Kubernetes como observador del ConfigMap y de los secretos de credenciales.
Verifica los certificados TLS y X.,509 si están habilitados:
Para conjuntos de réplicas: busca certificados en
<prefix>-<resource-name>-cert.Para clústeres fragmentados: busca certificados en
<prefix>-<resource-name>-x-cert(por fragmento),<prefix>-<resource-name>-config-cert(servidores de configuración) y<prefix>-<resource-name>-mongos-cert(mongosinstancias).
Crea o actualiza StatefulSets. El número depende del tipo de despliegue. En este punto, cada Pod ejecuta un agente de MongoDB, pero aún no contiene
mongodinstancias.Cada agente de MongoDB consulta al Administrador de Operaciones para obtener la configuración de automatización.
En contenedores no estáticos, el agente de MongoDB descarga los binarios de MongoDB con la versión especificada en
spec.version.Después de recibir la configuración, el agente de MongoDB se inicia
mongod.El operador de Kubernetes genera PersistentVolumeClaims para cada Pod (excepto los Pods
mongos), a menos quespec.persistentseafalse.
Envía las actualizaciones de configuración de automatización a Ops Manager. Cada agente de MongoDB consulta la configuración actualizada y la aplica. Si se modifica algún campo, el operador de Kubernetes realiza una actualización progresiva de los StatefulSets.
Crea o actualiza servicios de Kubernetes:
Para
ReplicaSetoStandalone: un servicioClusterIPsin cabeza llamado<resource-name>-svc.Para
ShardedCluster:mongos: utiliza el nombre enspec.serviceo<resource-name>-svc.Config servers:
<resource-name>-cs.Cada fragmento:
<resource-name>-sh.
El siguiente diagrama ilustra el flujo de reconciliación para conjuntos de réplicas:
El siguiente diagrama ilustra el flujo de reconciliación para clústeres fragmentados:
Reconciliación de recursos de usuarios de MongoDB
Si el método de autenticación de usuario es SCRAM, el MongoDBUser recurso depende de un secreto que almacena las credenciales del usuario. El operador de Kubernetes supervisa el secreto en busca de cambios y lo concilia de la siguiente manera:
Determina el recurso del usuario de MongoDB a partir de
spec.MongoDBResourceRef.name.Se conecta con Ops Manager, lee la organización y el proyecto, y verifica la clave secreta del agente.
Actualiza las credenciales del usuario en Ops Manager o crea un nuevo usuario si no existe. Si el nombre de usuario ha cambiado, el operador de Kubernetes elimina el nombre anterior y agrega uno nuevo.
El siguiente diagrama ilustra el flujo de conciliación MongoDBUser:
