La conciliación de MongoDBOpsManager Recurso personalizado

El siguiente diagrama describe cómo el Operador de Kubernetes reconcilia los cambios realizados en el MongoDBOpsManager CustomResourceDefinition en cada miembro del clúster de Kubernetes.

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 los MongoDBOpsManager recursos personalizados desencadenan una actualización progresiva de los Pods en <om_resource_name> StatefulSet. Habilitar TLS para la base de datos de la aplicación también activa un reinicio progresivo porque cambia la cadena de conexión a dicha base de datos. Los cambios en spec.backup no activan una actualización progresiva.

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.