La conciliación de MongoDBOpsManager Recurso personalizado

El siguiente diagrama describe cómo el Kubernetes operador reconcilia cambios en la MongoDBOpsManager CustomResourceDefinition en cada clúster de Kubernetes nodo.

haga clic para ampliar

1. El operador de Kubernetes crea o actualiza el secreto <om_resource_name>-db-config. Este secreto contiene las configuraciones que el MongoDB Agent usa para iniciar el set de réplicas de la base de datos de la aplicación.

2. El Operador de Kubernetes crea o actualiza el StatefulSet de la base de datos de la aplicación <om_resource_name>-db. Este StatefulSet contiene al menos tres Pods.

   • Cada Pod ejecuta una instancia de MongoDB Agent. Cada MongoDB Agent inicia una instancia de mongod en su Pod.

   • El operador de Kubernetes monta el secreto <om_resource_name>-db-config en cada pod. El agente de MongoDB utiliza este secreto para configurar el conjunto de réplicas de la base de datos de la aplicación.

     En implementaciones de múltiples clústeres, el operador de Kubernetes asigna el sufijo de índice del clúster miembro al StatefulSet de cada base de datos de aplicaciones, en formato <om_resource_name>-db-<cluster-idx>, por ejemplo: om-db-1.

3. El Operador de Kubernetes crea o actualiza el StatefulSet <om_resource_name>. En implementaciones de varios clústeres, el Operador de Kubernetes asigna el sufijo de índice del clúster nodo a cada StatefulSet, en la forma <om_resource_name>-<cluster-idx>; por ejemplo: om-1.

   El StatefulSet contiene un pod por cada réplica de Ops Manager. Cada réplica de Ops Manager se conecta a la base de datos de la aplicación.

   La mayoría de los cambios en el MongoDBOpsManager recurso personalizado desencadenan una actualización esporádica de los Pods en el StatefulSet <om_resource_name>. Activar TLS para la Base de datos de la aplicación también provoca un reinicio en secuencia porque la cadena de conexión a la Base de datos de la aplicación cambia. Los cambios en spec.backup no activan una actualización gradual.

4. El Kubernetes operador invoca las API de Ops Manager para crear un usuario administrador. El Kubernetes operador guarda las credenciales de este usuario administrador en el secreto <om_resource_name>-admin-key. El Kubernetes operador usa estas credenciales para todas las demás invocaciones de la API de Ops Manager. Este paso de conciliación ocurre solo una vez cuando se utiliza el Kubernetes operador para implementar un nuevo recurso de Ops Manager. El Kubernetes operador omite este paso cuando actualiza el recurso.

5. El operador de Kubernetes realiza una actualización escalonada de los Pods en el StatefulSet de base de datos de la aplicación <om_resource_name>-db para permitir que el Gestor de Operaciones lo supervise. La supervisión está habilitada por defecto. Este paso de reconciliación ocurre sólo una vez, como cuando implementas un nuevo recurso de Ops Manager.

6. Si spec.backup.enabled es verdadero, el operador de Kubernetes crea el <om_resource_name>-backup-daemon StatefulSet o verifica que esté en ejecución. El daemon de copias de seguridad se conecta a la misma base de datos de la aplicación que la implementación de Ops Manager.

   En implementaciones multiclúster, el Operador de Kubernetes asigna el sufijo de índice del clúster miembro a cada StatefulSet del daemon de copias de seguridad, en la forma de <om_resource_name>-backup-daemon-<cluster-idx>, por ejemplo: om-backup-daemon-1.

7. Si spec.backup.enabled es verdadero, el operador de Kubernetes invoca las API de Ops Manager para garantizar que la configuración de respaldo de la aplicación Ops Manager coincida con la que define en la definición de recurso personalizado.