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 los correspondientes Volúmenes Persistentes implementados en varios clústeres de Kubernetes.

En este diagrama:

1. El Member Cluster 0 también es un clúster central porque en él se instala el operador de Kubernetes. También es un clúster de nodo y puede host cualquier recurso personalizado de varios clústeres.

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 va a gestionar. Si tiene previsto utilizar el clúster central como clúster nodo, este secreto podría contener las credenciales para el mismo clúster donde instale el operador de Kubernetes.

   Cuando el Operador de Kubernetes se ejecuta en el modo multicluster, almacena los recursos que necesita, tales como ConfigMaps y secretos de los clústeres que va a gestionar. 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 lleva a que el operador de Kubernetes implemente los componentes de Ops Manager descritos en este diagrama. Este ejemplo omite algunas configuraciones que no son relevantes para este diagrama, como la configuración de TLS.

   1apiVersion: mongodb.com/v12kind: MongoDBOpsManager3metadata:4  name: om5  namespace: om-ns6spec:7  replicas: 1 # You can set this value and use it as a global or default8              # setting for all clusters. The spec.clusterSpecList.members9              # setting overrides this setting.10  topology: MultiCluster11  version: 8.0.012  adminCredentials: om-admin-secret13  clusterSpecList:14    - clusterName: "Member Cluster 1" # Ops Manager settings for "Member Cluster 1"15      members: 216      backup: # Backup settings for "Member Cluster 1"17        members: 2 # Overrides spec.backup.members18    - clusterName: "Member Cluster 2" # Ops Manager settings for "Member Cluster 2"19      members: 120      backup: # Backup settings for "Member Cluster 2"21        members: 2 # Overrides spec.backup.members22  applicationDatabase: # Global {+appdb+} settings23    topology: MultiCluster24    version: 8.0.025    members: 3 # In multi-cluster mode, the Operator ignores this field.26               # The Operator sets the number of members for the Application27               # Database in spec.applicationDatabase.clusterSpecList.members.28    clusterSpecList:29      - clusterName: "Member Cluster 1"30        members: 331      - clusterName: "Member Cluster 2"32        members: 233  backup: # Global settings for the Backup Daemon34    enabled: true35    members: 1 # Set this value and use it as a global or default setting.36               # To override this value, set the value for37               # spec.clusterSpecList.backup.members.38               # The Backup Daemon's configuration for each cluster isn't39               # stored here. Use the Ops Manager's spec.clusterSpecList.backup to40               # 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 por defecto del servicio que crea para el recurso de MongoDB Ops Manager, <om_resource_name>-svc.<namespace>.svc.cluster.local, o

   • La URL que especifique en spec.opsManagerURL. En algunas implementaciones, como cuando el clúster donde instaló el operador de Kubernetes no está conectado a la malla de servicios, el FQDN de servicio por defecto podría ser inaccesible. En este caso, el operador de Kubernetes reporta el estado del recurso MongoDBOpsManager como Failed, lo que indica un error de conexión. Para tener en cuenta estos casos, proporcione la URL de MongoDB Ops Manager en el spec.opsManagerURL. Esta URL podría ser un nombre de host de una instancia de Ops Manager expuesta externamente. Para aprender más, 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 denominado <om_resource_name>-db-<cluster_index>-<pod_index>, el operador de Kubernetes crea un servicio de tipo Kubernetes ClusterIPpara acceder a los procesos individuales mongod mediante su FQDN, <om_resource_name>-db-<cluster_index>-<pod_index>-svc. Cada proceso mongod en el set de réplicas debe ser direccionable de forma única.

     Los procesos en la configuración del set de réplicas deben tener sus nombres de host de proceso configurados para 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.

     La malla de servicios gestiona las query 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 MongoDB Ops Manager mediante el FQDN del servicio MongoDB Ops Manager, <om_resource_name>-svc.<namespace>.svc.cluster.local, o el valor de spec.opsManagerURL si lo especifica.

     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.