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 mongodb-enterprise-operator-multi-cluster-kubeconfig secreto, que contiene las credenciales de todos los clústeres de Kubernetes que el Operador de Kubernetes gestionará. Si planeas utilizar el clúster operador como un clúster nodo, este secreto puede guardar las credenciales del mismo clúster donde se instala el Kubernetes Operator.

   Cuando el Operador de Kubernetes se ejecuta en 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 algunos ConfigMaps adicionales de estado de implementación multiclúster para cada implementación de la aplicación y la base de datos de la aplicación de Ops Manager que administra. El Member Cluster 0 almacena esta configuración, que incluye los siguientes ConfigMaps:

   • 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 multinúcleo. El operador de Kubernetes utiliza este archivo para implementar los componentes de Ops Manager.

   El siguiente ejemplo muestra la configuración que permite que el operador de Kubernetes despliegue los componentes de Ops Manager descritos en este diagrama. Este ejemplo omite algunos ajustes que no son relevantes para este diagrama, tales 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.

   • Se define el número de instancias en spec.clusterSpecList.members. Puedes establecer el número de instancias en cero para que este clúster no implemente ninguna instancia de Ops Manager aplicación. Esto es útil, si, por ejemplo, deseas utilizar este clúster solo para alojar instancias de daemon de copias de seguridad.

     Si se remueve un clúster de spec.clusterSpecList, esto equivale a especificar cero nodos en spec.clusterSpecList.members y spec.clusterSpecList[*].backup.members.

   • Para cada StatefulSet en cada clúster, el Kubernetes Operator configura un servicio de tipo ClusterIP, llamado <om_resource_name>-svc, que contiene todos los Pods en la lista de endpoints del clúster. El FQDN de este servicio, <om_resource_name>-svc.<namespace>.svc.cluster.local, es un nombre de host por defecto que el Operador de Kubernetes utiliza para acceder al endpoint desplegado de 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 llamado <om_resource_name>-db-<cluster_index>-<pod_index>, el Operador de Kubernetes crea un servicio de tipo ClusterIPde Kubernetes para acceder a los procesos individuales mongod por su FQDN, <om_resource_name>-db-<cluster_index>-<pod_index>-svc. Cada proceso mongod en el set de réplicas debe ser direccionable de manera ú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 set de réplicas a partir de todos los procesos mongod, cada proceso debe conectarse con todos los demás para fines de replicación. Para lograr esto, incluya todos los clústeres nodo en los que se 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 mongod que se ejecuta en el pod om-db-1-0 en Member Cluster 1 se conecta a un proceso mongod que se ejecuta en el pod om-db-2-1 en Member Cluster 2, el primer proceso mongod utiliza su nombre de host de la configuración de automatización, om-db-2-1-svc.om-ns.svc.cluster.local:27017, y el malla de servicios enruta esta solicitud a Member Cluster 2 hacia el servicio om-db-2-1-svc. Sin la malla de servicios, Kubernetes Member Cluster 1 no tiene información sobre el servicio om-db-2-1-svc implementado en el Member Cluster 2 y la resolución DNS de om-db-2-1-svc.om-ns.svc.cluster.local fallaría.

   • Cuando la base de datos de la aplicación y las instancias de la aplicación de Ops Manager están en un estado Running, el operador de Kubernetes añade un contenedor de supervisión adicional a los StatefulSets de la base de datos de la aplicación. Esto da como resultado un reinicio en secuencia de todos los pods de la base de datos de la aplicación en todos los clústeres. El operador de Kubernetes actualiza los StatefulSets en todos los clústeres de manera secuencial, para que durante el proceso de reinicio en secuencia, en cada clúster, solo un nodo del set de réplicas quede temporalmente no disponible.

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

     La Aplicación Ops Manager y el daemon de copias 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 usando los FQDN por servicio por pod.

8. El Operador de Kubernetes implementa los StatefulSets del daemon de copias de seguridad si se configura el spec.backup.enabled como true.

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

     De manera alternativa, puedes configurar el número de instancias de daemon de copias de seguridad para cada clúster en spec.clusterSpecList[*].backup.members.

   • 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, puedes observar el service mesh 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 a través de los clústeres de nodos indican que estas instancias son sin estado y el tráfico puede distribuirse por igual a todas las instancias, por ejemplo, utilizando un balanceador de carga round-robin.

• Las líneas de puntos que rodean la base de datos de la aplicación a través de los clústeres de nodos indican que estas instancias se comunican entre sí y forman un único set de réplicas de MongoDB.