El recurso personalizado de MongoDB define las implementaciones de la base de datos que gestiona 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 transmite los cambios a MongoDB Ops Manager, que modifica la configuración de la implementación de MongoDB.
El CRD MongoDB admite tres tipos de implementación. El siguiente diagrama ilustra la composición de cada uno:
Advertencia
El operador de Kubernetes no es compatible con nodos árbitros.
Recurso autónomo
Aunque puedes implementar un recurso Standalone, te recomendamos que implementes un recurso ReplicaSet con un solo nodo, ya que un set de réplicas te permite agregar nodos en el futuro. En Kubernetes, un recurso Standalone es equivalente a un recurso ReplicaSet con un solo nodo.
Para un recurso Standalone, el operador de Kubernetes implementa un set de réplicas con un solo nodo como un StatefulSet. El operador de Kubernetes crea el StatefulSet, que contiene la especificación del Pod, y depende del controlador StatefulSet de Kubernetes para crear el Pod para esta única instancia mongod.
Recurso de set de réplicas
Para un recurso ReplicaSet, el operador de Kubernetes implementa un set de réplicas como un StatefulSet, con un número de nodos igual al valor de spec.members. El operador de Kubernetes depende del controlador StatefulSet de Kubernetes para crear un Pod por nodo. Cada Pod ejecuta una instancia de MongoDB Agent que gestiona el proceso mongod en ese Pod.
Recurso de clúster particionado
Un recurso ShardedCluster consta de servidores de configuración, instancias mongos y nodos de particiones. El operador de Kubernetes implementa:
Un StatefulSet para todos los servidores de configuración
Un StatefulSet para todas las instancias de
mongosUn StatefulSet para cada partición
El operador de Kubernetes se basa en el controlador StatefulSet de Kubernetes para crear un Pod en cada StatefulSet. Para un clúster particionado con 2 particiones, esto significa 4 StatefulSets en total (1 para servidores de configuración + 1 para mongos + 2 para particiones).
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 aplica una especificación de recurso personalizado de MongoDB, el operador de Kubernetes implementa cada recurso como un StatefulSet. El operador de Kubernetes entra entonces en un bucle de reconciliación continuo:
Lee la configuración del proyecto del ConfigMap especificado en
spec.opsManager.configMapRef.name.Lee las credenciales de la API del secreto especificado en
spec.credentialso de su herramienta de almacenamiento de secretos.Se conecta a MongoDB 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
<project-id>-group-secretexista o lo crea con las claves de API de MongoDB Ops Manager.Registra el operador de Kubernetes como observador de ConfigMap y Secrets de credenciales.
Verifica los certificados TLS y X.509 , si están habilitados:
Para set de réplicas: busca certificados en
<prefix>-<resource-name>-cert.Para clústeres particionados: busca certificados en
<prefix>-<resource-name>-x-cert(por partición),<prefix>-<resource-name>-config-cert(servidores de configuración) y<prefix>-<resource-name>-mongos-cert(instancias demongos).
Crea o actualiza StatefulSets. El número depende del tipo de implementación. En este punto, cada Pod ejecuta un MongoDB Agent, pero aún no contiene instancias de
mongod.Cada MongoDB Agent sondea Ops Manager para obtener la configuración de automatización.
En los contenedores no estáticos, el MongoDB Agent descarga los binarios de MongoDB con la versión especificada en
spec.version.Después de recibir la configuración, el MongoDB Agent inicia
mongod.El operador de Kubernetes genera PersistentVolumeClaims para cada Pod (excepto los Pods
mongos), a menos quespec.persistentseafalse.
Envía actualizaciones de configuración de automatización a Ops Manager. Cada MongoDB Agent sondea la configuración actualizada y la aplica. Si cambia algún campo, el operador de Kubernetes realiza una actualización gradual de los StatefulSets.
Crea o actualiza servicios de Kubernetes:
Para
ReplicaSetoStandalone: un servicioClusterIPsin interfaz gráfica denominado<resource-name>-svc.Para
ShardedCluster:mongosutiliza el nombre enspec.serviceo<resource-name>-svc.Config servers:
<resource-name>-cs.Cada partición:
<resource-name>-sh.
El siguiente diagrama ilustra el flujo de reconciliación para los sets de réplicas:
El siguiente diagrama ilustra el flujo de conciliación para clústeres particionados:
Reconciliación de recursos de MongoDBUser
Si el método de autenticación de usuario es SCRAM, el recurso MongoDBUser depende de un secreto que almacena las credenciales del usuario. El operador de Kubernetes supervisa el secreto en busca de cambios y se concilia de la siguiente manera:
Determina el recurso del usuario de MongoDB a partir de
spec.MongoDBResourceRef.name.Se conecta a MongoDB Ops Manager, lee la organización y el Proyecto, y verifica el secreto 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 remueve el nombre anterior y agrega uno nuevo.
El siguiente diagrama ilustra el flujo de reconciliación MongoDBUser:
