Diagrama de arquitectura multiclúster: Ops Manager y la base de datos de aplicaciones

El siguiente diagrama muestra la aplicación Ops Manager, la base de datos de la aplicación, el demonio de respaldo y los volúmenes persistentes correspondientes implementados en múltiples clústeres de Kubernetes.

haga clic para ampliar

En este diagrama:

1. El Member Cluster 0 También es un "clúster de operadores" porque se instala el operador de Kubernetes. También es un "clúster miembro" y puede alojar cualquier recurso personalizado multiclúster.

2. El archivo Member Cluster 0 almacena los archivos kubeconfig, que describen la configuración de Kubernetes para los clústeres miembros, los usuarios y los contextos. Al configurar el operador de Kubernetes para implementaciones multiclúster mediante el kubectl mongodb complemento, se crea el siguiente recurso:

   • El secreto mongodb-enterprise-operator-multi-cluster-kubeconfig, que contiene las credenciales de todos los clústeres de Kubernetes que el operador de Kubernetes administrará. Si planea usar el clúster del operador como clúster miembro, este secreto podría contener las credenciales del mismo clúster donde instala el operador de Kubernetes.

   Cuando el operador de Kubernetes se ejecuta en modo multiclúster, almacena los recursos necesarios, como los mapas de configuración y los secretos de los clústeres que va a administrar. Estos recursos pertenecen al mismo espacio de nombres que el operador de Kubernetes. El operador de Kubernetes utiliza estos recursos para implementar la aplicación Ops Manager y la base de datos de la aplicación en varios clústeres de Kubernetes.

3. El operador de Kubernetes también crea y mantiene mapas de configuración adicionales del estado de implementación multiclúster para cada implementación de la aplicación Ops Manager y la base de datos de aplicaciones que administra. El Member Cluster 0 almacena esta configuración, que incluye los siguientes mapas de configuración:

   • El <om_resource_name>-cluster-mapping ConfigMap contiene la asignación de los nombres de los clústeres miembros enumerados en a los spec.clusterSpecList índices de clúster, referenciados en esta documentación cluster_index como,Cluster 0 como Cluster 1 o. El operador de Kubernetes asigna estos índices a cada nombre de clúster.

   • El <om_resource_name>-db-cluster-mapping ConfigMap contiene la asignación de los nombres de los clústeres miembros enumerados en a los índices de clúster.spec.applicationDatabase.clusterSpecList

   • El ConfigMap <om_resource_name>-db-member-spec contiene el número de réplicas de bases de datos de la aplicación configuradas para cada clúster miembro. Tener esta información permite al operador de Kubernetes escalar correctamente o reconfigurar el set de réplicas como parte de la recuperación ante desastres, por ejemplo, tras perder todo el clúster nodo.

4. La configuración del recurso MongoDBOpsManager es un archivo que usted crea y que describe una implementación de Ops Manager en varios clústeres. El operador de Kubernetes utiliza este archivo para implementar los componentes de Ops Manager.

   El siguiente ejemplo muestra la configuración que permite al operador de Kubernetes implementar los componentes de Ops Manager descritos en este diagrama. Este ejemplo omite algunas configuraciones que no son relevantes para este diagrama, como Configuración de TLS.

   1
   apiVersion: mongodb.com/v1
   2
   kind: MongoDBOpsManager
   3
   metadata:
   4
     name: om
   5
     namespace: om-ns
   6
   spec:
   7
     replicas: 1 # You can set this value and use it as a global or default
   8
                 # setting for all clusters. The spec.clusterSpecList.members
   9
                 # setting overrides this setting.
   10
     topology: MultiCluster
   11
     version: 8.0.0
   12
     adminCredentials: om-admin-secret
   13
     clusterSpecList:
   14
       - clusterName: "Member Cluster 1" # Ops Manager settings for "Member Cluster 1"
   15
         members: 2
   16
         backup: # Backup settings for "Member Cluster 1"
   17
           members: 2 # Overrides spec.backup.members
   18
       - clusterName: "Member Cluster 2" # Ops Manager settings for "Member Cluster 2"
   19
         members: 1
   20
         backup: # Backup settings for "Member Cluster 2"
   21
           members: 2 # Overrides spec.backup.members
   22
     applicationDatabase: # Global {+appdb+} settings
   23
       topology: MultiCluster
   24
       version: 8.0.0
   25
       members: 3 # In multi-cluster mode, the Operator ignores this field.
   26
                  # The Operator sets the number of members for the Application
   27
                  # Database in spec.applicationDatabase.clusterSpecList.members.
   28
       clusterSpecList:
   29
         - clusterName: "Member Cluster 1"
   30
           members: 3
   31
         - clusterName: "Member Cluster 2"
   32
           members: 2
   33
     backup: # Global settings for the Backup Daemon
   34
       enabled: true
   35
       members: 1 # Set this value and use it as a global or default setting.
   36
                  # To override this value, set the value for
   37
                  # spec.clusterSpecList.backup.members.
   38
                  # The Backup Daemon's configuration for each cluster isn't
   39
                  # stored here. Use the Ops Manager's spec.clusterSpecList.backup to
   40
                  # specify the Backup Daemon configuration for each member cluster.

5. El operador de Kubernetes se conecta a las instancias de Ops Manager haciendo referencia a:

   • El FQDN predeterminado del servicio que crea para el recurso Ops<om_resource_name>-svc.<namespace>.svc.cluster.local Manager,, o

   • La URL que especifique en. En algunas implementaciones, como cuando el clúster donde instaló el spec.opsManagerURL operador de Kubernetes no está conectado a la malla de servicios, el FQDN del servicio predeterminado podría ser inaccesible. En este caso, el operador de Kubernetes informa que el MongoDBOpsManager estado del recurso es,Failed lo que indica un error de conexión. Para tener en cuenta estos casos, proporcione la URL a Ops Manager en. Esta URL podría ser el nombre de host de una instancia de Ops Manager expuesta externamente. Para obtener más información,spec.opsManagerURL consulte Descripción general de redes.

6. Dos clústeres miembros alojan la aplicación Ops Manager. En cada clúster, el operador de Kubernetes implementa un StatefulSet <om_resource_name>-<cluster_index> llamado.

   • StatefulSet implementa dos instancias de la aplicación Ops Manager en Member Cluster 1 y una instancia en Member Cluster 2.

   • Define el número de instancias spec.clusterSpecList.members en. Puedes establecer el número de instancias en cero para que este clúster no implemente ninguna instancia de la aplicación Ops Manager. Esto es útil si, por ejemplo, quieres usar este clúster para alojar únicamente instancias del demonio de copia de seguridad.

     Si elimina un clúster de, esto equivale a especificar cero miembros spec.clusterSpecList en spec.clusterSpecList.members spec.clusterSpecList[*].backup.membersy.

   • Para cada StatefulSet de cada clúster, el operador de Kubernetes configura un servicio de tipo,ClusterIP <om_resource_name>-svcllamado, que contiene todos los pods de la lista de endpoints del clúster. El FQDN de este<om_resource_name>-svc.<namespace>.svc.cluster.local servicio,, es un nombre de host predeterminado que el operador de Kubernetes utiliza para acceder al endpoint implementado para la aplicación Ops Manager.

   • Si especifica, el operador de Kubernetes también crea spec.externalConnectivity un LoadBalancerservicio externo de Kubernetes de tipo,<om_resource_name>-svc-ext llamado, para cada clúster. En cada clúster, puede especificar su propia configuración para este servicio externo mediante. Por ejemplo, puede cambiar el tipo del servicio o definir spec.clusterSpecList.externalConnectivity anotaciones.

7. Base de datos de la aplicación. El operador de Kubernetes implementa la base de datos de la aplicación en dos clústeres.

   • El Member Cluster 1 contiene tres procesos para la base de datos de la aplicación, y mongod el Member Cluster 2 contiene dos mongod procesos.

   • La configuración de la base de datos de la aplicación se define mediante la spec.applicationDatabase configuración. En cada clúster miembro, el operador de Kubernetes crea un conjunto con estado <om_resource_name>-db-<cluster_index> con la cantidad de clústeres miembro definida spec.applicationDatabase.clusterSpecList.members en. En el modo multiclúster, el operador de Kubernetes ignora los valores que se configuran para el spec.applicationDatabase.members campo. El operador de Kubernetes configura un conjunto de réplicas mongod formado por procesos implementados en todos los clústeres miembro.

   • Para cada pod en <statefulset_name>-<pod_index> que aloja un proceso de MongoDB <om_resource_name>-db-<cluster_index>-<pod_index> llamado, el operador de Kubernetes crea un ClusterIPservicio de tipo de Kubernetes para acceder a los mongod procesos individuales mediante su<om_resource_name>-db-<cluster_index>-<pod_index>-svc FQDN,. Cada mongod proceso del conjunto de réplicas debe tener una dirección única.

     Los procesos en la configuración del set de réplicas deben tener sus nombres de host configurados en el FQDN de ese servicio de Pod: <om_resource_name>-db-<cluster_index>-<pod_index>-svc.<namespace>.svc.cluster.local.

   • Cada pod tiene su volumen persistente adjunto a través de un reclamo de volumen persistente que crea el operador de Kubernetes.

   • Para formar un conjunto de réplicas a partir de los mongod procesos, cada proceso debe conectarse con los demás para la replicación. Para ello, incluya todos los clústeres miembros donde implemente la base de datos de la aplicación en la misma configuración de malla de servicios.

     La malla de servicios gestiona las consultas DNS entre clústeres y enruta el tráfico en consecuencia. Ayuda a resolver el FQDN de cada servicio de pod <om_resource_name>-db-<cluster_index>-<pod-index>-svc.<namespace>.svc.cluster.local en todos los clústeres y permite la conectividad en el puerto expuesto mongod (27017 por defecto).

     Por ejemplo, cuando un proceso que se ejecuta en mongod el om-db-1-0 pod de Member Cluster 1 se conecta a un mongod proceso que se ejecuta en el om-db-2-1 pod Member Cluster 2 de, el primer proceso usa su nombre de host de la configuración de mongod automatización,, om-db-2-1-svc.om-ns.svc.cluster.local:27017 y la malla de servicios enruta esta solicitud a Member Cluster 2 hacia el om-db-2-1-svc servicio. Sin la malla de servicios, Kubernetes Member Cluster 1 no tiene información sobre el om-db-2-1-svc servicio implementado en Member Cluster 2 y la resolución DNS de om-db-2-1-svc.om-ns.svc.cluster.local fallaría.

   • Cuando las instancias de la base de datos de la aplicación y de la aplicación Ops Manager se encuentran en estado Running, el operador de Kubernetes añade un contenedor de monitorización adicional a los conjuntos de estado de la base de datos de la aplicación. Esto genera un reinicio gradual de todos los pods de la base de datos de la aplicación en todos los clústeres. El operador de Kubernetes actualiza los conjuntos de estado en todos los clústeres secuencialmente, de modo que, durante el reinicio gradual, en cada clúster, solo un miembro del conjunto de réplicas deja de estar disponible temporalmente.

   • El agente de monitoreo se conecta a las instancias de la aplicación Ops Manager mediante el FQDN del servicio Ops<om_resource_name>-svc.<namespace>.svc.cluster.local Manager,, o el valor en si lo spec.opsManagerURL especifica.

     La aplicación Ops Manager y el demonio de copia de seguridad siempre utilizan la cadena de conexión a la base de datos de la aplicación que contiene todos los miembros del conjunto de réplicas. La cadena de conexión siempre se construye utilizando los FQDN de servicio por pod.

8. El operador de Kubernetes implementa los conjuntos de estados del demonio de respaldo si configura spec.backup.enabled true en.

   • En cada clúster miembro enumerado en, el operador de Kubernetes crea spec.clusterSpecList un <om_resource_name>-backup-daemon-<cluster_index> conjunto de estado de Backup Daemon, denominado, con la cantidad de instancias de Backup Daemon establecida spec.backup.members en.

     Como alternativa, puede configurar la cantidad de instancias de Backup Daemon para cada clúster spec.clusterSpecList[*].backup.members en.

   • Las instancias de Backup Daemon se conectan únicamente al conjunto de réplicas de la base de datos de la aplicación mediante la misma cadena de conexión que las instancias de la aplicación Ops Manager.

Además, en este diagrama se puede observar la malla de servicios y las conexiones de red entre los componentes:

• Las líneas punteadas que rodean el diagrama muestran la malla de servicio única que incluye la configuración de red para todos los clústeres.

• Las líneas de puntos que rodean la aplicación Ops Manager en los clústeres miembros indican que estas instancias no tienen estado y que el tráfico se puede distribuir equitativamente entre todas las instancias, por ejemplo, mediante el uso de un balanceador de carga round-robin.

• Las líneas punteadas que rodean la base de datos de la aplicación en los clústeres miembros indican que estas instancias se comunican entre sí y forman un único conjunto de réplicas de MongoDB.