Diagrama de arquitetura de vários clusters: MongoDB Ops Manager e o banco de dados de aplicativos

O diagrama a seguir mostra o Aplicativo de Ops Manager, o Banco de Dados do Aplicativo, o Backup Daemon e os Volumes persistentes correspondentes distribuídos em vários clusters do Kubernetes.

Neste diagrama:

1. O Member Cluster 0 também é um "cluster de operadores" porque você instala o Operador Kubernetes nele. Ele também é um "cluster de membros" e pode hospedar qualquer recurso personalizado de vários clusters.

2. The Member Cluster 0 stores the kubeconfig files, which describe the Kubernetes configuration for member clusters, users, and contexts. When you configure the Kubernetes Operator for multi-cluster deployments using the kubectl mongodb plugin, it creates the following resource:

   • O segredo mongodb-enterprise-operator-multi-cluster-kubeconfig , que contém as credenciais de todos os clusters Kubernetes que o Operador Kubernetes vai gerenciar. Se você planeja usar o cluster do operador como um cluster de membros, esse segredo poderá conter as credenciais do mesmo cluster onde você instalará o Kubernetes Operator.

   Quando o Operador Kubernetes é executado no modo de vários clusters, ele armazena os recursos necessários, como ConfigMaps e segredos sobre os clusters que ele vai gerenciar. Estes recursos pertencem ao mesmo namespace que o Operador Kubernetes. O Operador do Kubernetes usa esses recursos para implantar o Aplicativo de MongoDB Ops Manager e o Banco de Dados de Aplicativos em vários clusters do Kubernetes .

3. O Operador Kubernetes também cria e mantém alguns ConfigMaps adicionais de estado de implantação de vários clusters para cada aplicativo MongoDB Ops Manager e sistema de banco de dados de aplicativos que gerencia. O Member Cluster 0 armazena esta configuração, que inclui os seguintes ConfigMaps:

   • O <om_resource_name>-cluster-mapping ConfigMap contém o mapeamento de nomes de cluster de membros listados em spec.clusterSpecList para índices de cluster, referenciados nesta documentação como cluster_index, como Cluster 0 ou Cluster 1. O Operador Kubernetes atribui estes índices a cada nome de cluster.

   • O <om_resource_name>-db-cluster-mapping ConfigMap contém o mapeamento dos nomes do cluster de membros listados em spec.applicationDatabase.clusterSpecList para índices de cluster.

   • O <om_resource_name>-db-member-spec ConfigMap contém o número de réplicas do Banco de Dados de Aplicativo configurados para cada agrupamento de membro. Ter essas informações permite que o operador do Kubernetes dimensione ou reconfigure corretamente o conjunto de réplicas como parte da recuperação de desastres, como após a perda de todo o cluster de membros.

4. A configuração do recurso MongoDBOpsManager é um arquivo que você cria e que descreve um sistema do MongoDB Ops Manager de vários clusters. O Operador Kubernetes usa este arquivo para implantar os componentes do MongoDB Ops Manager .

   O exemplo a seguir mostra a configuração que leva o Operador Kubernetes a implantar os componentes do MongoDB Ops Manager descritos neste diagrama. Este exemplo omite algumas configurações que não são relevantes para este diagrama, como a configuração 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. O operador Kubernetes se conecta às instâncias do MongoDB Ops Manager fazendo referência a:

   • The default FQDN of the service it creates for the Ops Manager resource, <om_resource_name>-svc.<namespace>.svc.cluster.local, or

   • The URL that you specify in spec.opsManagerURL. In some deployments, such as when the cluster where you installed the Kubernetes Operator isn't attached to the service mesh, the default service FQDN might be unreachable. In this case, the Kubernetes Operator reports the MongoDBOpsManager resource status as Failed indicating a connection error. To account for such cases, provide the URL to Ops Manager in the spec.opsManagerURL. This URL might be a hostname of an externally exposed Ops Manager instance. To learn more, see Networking Overview.

6. Two member clusters host the Ops Manager Application. In each cluster, the Kubernetes Operator deploys a StatefulSet named <om_resource_name>-<cluster_index>.

   • O StatefulSet implementa duas instâncias do Aplicativo MongoDB Ops Manager no Member Cluster 1 e uma instância no Member Cluster 2.

   • Você define o número de instâncias no spec.clusterSpecList.members. Você pode definir o número de instâncias como zero para que esse cluster não implante nenhuma instância do Aplicativo de MongoDB Ops Manager . Isso é útil se, por exemplo, você quiser usar esse cluster para hospedar apenas instâncias do Backup Daemon .

     Se você remover um cluster de spec.clusterSpecList, isso será equivalente a especificar zero nós em spec.clusterSpecList.members e spec.clusterSpecList[*].backup.members.

   • For each StatefulSet in each cluster, the Kubernetes Operator configures a service of type ClusterIP, named <om_resource_name>-svc, that contains all Pods on the cluster's endpoints list. This service's FQDN, <om_resource_name>-svc.<namespace>.svc.cluster.local, is a default hostname that the Kubernetes Operator uses to access the deployed endpoint for the Ops Manager Application.

   • Se você especificar spec.externalConnectivity, o Operador Kubernetes também criará um serviço externo do tipo Kubernetes LoadBalancer , chamado <om_resource_name>-svc-ext, para cada cluster. Em cada cluster, você pode especificar sua própria configuração para esse serviço externo usando spec.clusterSpecList.externalConnectivity. Por exemplo, você pode alterar o tipo do serviço ou definir anotações.

7. Banco de Dados de Aplicativos. O Operador Kubernetes implementa o Banco de Dados de Aplicativo em dois clusters.

   • The Member Cluster 1 contains three mongod processes for the Application Database, and the Member Cluster 2 contains two mongod processes..

   • You define the Application Database configuration using the spec.applicationDatabase settings. On each member cluster, the Kubernetes Operator creates a StatefulSet named <om_resource_name>-db-<cluster_index> with the number of member clusters defined in spec.applicationDatabase.clusterSpecList.members. In multi-cluster mode, the Kubernetes Operator ignores values that you set for the spec.applicationDatabase.members field. The Kubernetes Operator configures one replica set formed from mongod processes deployed across all member clusters.

   • For each Pod in <statefulset_name>-<pod_index> hosting a MongoDB process named <om_resource_name>-db-<cluster_index>-<pod_index>, the Kubernetes Operator creates a Kubernetes ClusterIP-type service for accessing the individual mongod processes by its FQDN, <om_resource_name>-db-<cluster_index>-<pod_index>-svc. Each mongod process in the replica set must be uniquely addressable.

     The processes in the replica set configuration must have their process hostnames configured to that Pod service's FQDN: <om_resource_name>-db-<cluster_index>-<pod_index>-svc.<namespace>.svc.cluster.local.

   • Cada Pod tem seu volume persistente anexado por meio de uma Declaração de Volume Persistente que o Operador Kubernetes cria.

   • To form a replica set from all mongod processes, each process must connect to each other process for replication purposes. To achieve this, include all member clusters on which you deploy the Application Database into the same service mesh configuration.

     A mesclagem de serviço lida com queries de DNS entre clusters e roteia o tráfego adequadamente. A malha de serviço ajuda a resolver o FQDN <om_resource_name>-db-<cluster_index>-<pod-index>-svc.<namespace>.svc.cluster.local de cada serviço de Pod em todos os clusters e permite a conectividade na porta mongod exposta (27017 por padrão).

     For example, when a mongod process running in the om-db-1-0 Pod in Member Cluster 1 connects to a mongod running in the om-db-2-1 Pod in Member Cluster 2, the first mongod process uses its hostname from the Automation Configuration, om-db-2-1-svc.om-ns.svc.cluster.local:27017, and the service mesh routes this request to Member Cluster 2 to the om-db-2-1-svc service. Without the service mesh, the Kubernetes Member Cluster 1 has no information about the om-db-2-1-svc service deployed in the Member Cluster 2 and the DNS resolution of om-db-2-1-svc.om-ns.svc.cluster.local would fail.

   • Quando o Banco de Dados de Aplicativo e as instâncias do Aplicativo MongoDB Ops Manager estão em um estado Running, o Operador Kubernetes adiciona um contêiner de monitoramento adicional ao Banco de Dados do Aplicativo StatefulSets. Isso resulta em uma reinicialização contínua de todos os Pods do Banco de Dados de Aplicativos em todos os clusters. O Operador Kubernetes atualiza os StatefulSets em todos os clusters sequencialmente, de modo que, durante o processo de reinicialização contínua , em cada cluster, apenas um membro do conjunto de réplicas fique temporariamente indisponível.

   • The Monitoring Agent connects to the Ops Manager Application instances using the Ops Manager service's FQDN, <om_resource_name>-svc.<namespace>.svc.cluster.local, or the value in spec.opsManagerURL if you specify it.

     O Aplicativo MongoDB Ops Manager e o Backup Daemon sempre usam a connection string para o Banco de Dados do Aplicativo que contém todos os membros do conjunto de réplicas. A string de conexão é sempre construída usando os FQDNs de serviço por pod.

8. O Operador Kubernetes implementa o Backup Daemon StatefulSets se você definir o spec.backup.enabled como true.

   • Em cada cluster de membros listado em spec.clusterSpecList, o Operador Kubernetes cria um Backup Daemon StatefulSet, chamado <om_resource_name>-backup-daemon-<cluster_index> com o número de instâncias do Backup Daemon definidos como spec.backup.members.

     Como alternativa, você pode configurar o número de instâncias do Backup Daemon para cada cluster em spec.clusterSpecList[*].backup.members.

   • As instâncias do Backup Daemon se conectam somente ao conjunto de réplicas do banco de dados do aplicativo usando a mesma connection string que as instâncias do aplicativo MongoDB Ops Manager .

Além disso, neste diagrama, é possível observar a malha de serviço e as conexões de rede entre os componentes:

• As linhas pontilhadas ao redor do diagrama mostram a única malha de serviço que inclui a configuração de rede para todos os clusters.

• As linhas pontilhadas ao redor do aplicativo MongoDB Ops Manager nos clusters de membros indicam que essas instâncias não têm estado e o tráfego pode ser distribuído uniformemente para todas as instâncias, por exemplo , usando um balanceador de carga round-robin .

• As linhas pontilhadas ao redor do banco de dados de aplicativos em clusters de membros indicam que essas instâncias se comunicam entre si e formam um único conjunto de réplicas MongoDB.