Diagrama de arquitectura multiclúster: Ops Manager y la base de datos de la aplicación

El siguiente diagrama muestra la aplicación de Ops Manager, la base de datos de la aplicación, el daemon de copias de seguridad y la correspondiente Volúmenes persistentes implementados en múltiples clústeres de Kubernetes.

haga clic para ampliar

En este diagrama:

1. La Member Cluster 0 também é um "clúster de operadores" porque você instala o Operador Kubernetes nele. Também é um "clúster de nodo" e pode alojar qualquer recurso customizado multicuster.

2. El Member Cluster 0 almacena los archivos kubeconfig, que describen la configuración de Kubernetes para los clústeres miembros, usuarios y contextos. Cuando se configura el Operador de Kubernetes para implementaciones multiclúster usando el plugin kubectl mongodb, 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 el modo multiclúster, almacena los recursos necesarios, como ConfigMaps y secretos sobre los clústeres que va a administrar. Estos recursos pertenecen al mismo namespace 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 múltiples 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 ConfigMap <om_resource_name>-cluster-mapping contiene el mapeo de nombres de clústeres nodos listados en el spec.clusterSpecList a índices de clústeres, referenciados en esta documentación como cluster_index, como Cluster 0, o Cluster 1. El operador de Kubernetes asigna estos índices a cada nombre de clúster.

   • El ConfigMap <om_resource_name>-db-cluster-mapping contiene el mapeo de los nombres de nodos listados en el spec.applicationDatabase.clusterSpecList a los índices de clúster.

   • 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 del Ops Manager haciendo referencia, ya sea a:

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

   • La URL que especifiques en spec.opsManagerURL. En algunas implementaciones, como cuando el clúster donde instalaste el Kubernetes Operator no está conectado al service mesh, el servicio FQDN por defecto podría ser inaccesible. En este caso, el operador de Kubernetes informa el estado del recurso MongoDBOpsManager como Failed, indicando un error de conexión. Para tener en cuenta estos casos, proporcione la URL a Ops Manager en el spec.opsManagerURL. Este URL podría ser un nombre de host de una instancia de Ops Manager expuesta externamente. Para obtener más información, consulta Descripción general de redes.

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

   • El 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 se especifica spec.externalConnectivity, el operador de Kubernetes también crea un servicio externo de Kubernetes de tipo LoadBalancer, denominado <om_resource_name>-svc-ext, para cada clúster. En cada clúster, puedes especificar su propia configuración para este servicio externo usando spec.clusterSpecList.externalConnectivity. Por ejemplo, puedes cambiar el tipo del servicio o definir 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 mongod para la base de datos de la aplicación, y el Member Cluster 2 contiene dos procesos mongod..

   • Defines la configuración de la base de datos de la aplicación utilizando la configuración de spec.applicationDatabase. En cada clúster nodo, el Operador de Kubernetes crea un StatefulSet llamado <om_resource_name>-db-<cluster_index> con el número de clústeres nodo definidos en spec.applicationDatabase.clusterSpecList.members. En el modo multiclúster, el Operador Kubernetes ignora los valores que estableces para el campo spec.applicationDatabase.members. El Operador de Kubernetes configura un set de réplicas formado por procesos mongod implementados en todos los clústeres miembros.

   • 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.

     El mesh de servicios gestiona las consultas DNS entre clústeres y enruta el tráfico en consecuencia. La malla de servicios ayuda a resolver el FQDN <om_resource_name>-db-<cluster_index>-<pod-index>-svc.<namespace>.svc.cluster.local de cada servicio de Pod 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 listado en el spec.clusterSpecList, el Kubernetes operador crea un daemon de copias de seguridad StatefulSet, llamado <om_resource_name>-backup-daemon-<cluster_index>, con el número de instancias de daemon de copias de seguridad establecido en spec.backup.members.

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

   • Las instancias del daemon de copias de seguridad solo se conectan al set de réplicas de la base de datos de la aplicación utilizando la misma cadena de conexión que las instancias de aplicaciones de 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 de puntos que rodean el diagrama muestran la malla de servicios ú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.