Redes, Balanceamento de carga, Malha de serviço
Considere os seguintes requisitos adicionais ao implantar o aplicativo MongoDB Ops Manager em vários clusters Kubernetes :
Visão geral da rede
A tabela a seguir descreve:
Origens de conexões com as instâncias do aplicativo MongoDB Ops Manager
As tarefas que o aplicativo MongoDB Ops Manager executa depois de se conectar
A URL para o MongoDB Ops Manager que cada tipo de conexão usa e como configurá-lo.
Origem da conexão | Finalidade ou ação | URL para o MongoDB Ops Manager |
---|---|---|
O operador Kubernetes | Configura a instância do MongoDB Ops Manager e permite o monitoramento depois que o banco de dados do aplicativo está no estado de execução | Por meio de um MongoDB Ops Manager FQDN padrão no formato: <om_resource_name>-svc.<namespace>.svc.cluster.local ou do valor de spec.opsManagerURL |
O operador Kubernetes | Configura um recurso MongoDB específico ou um sistema de recurso MongoDBMultiCluster | Através do ConfigMap do projeto, configurado ao criar um projeto |
MongoDB Agent nos pods do banco de dados do aplicativo | Recebe a configuração de automação | Sem precisar se conectar a uma instância MongoDB Ops Manager . O MongoDB Agent está sendo executado em um modo headless. |
Agente de monitoramento nos pods do banco de dados de aplicativos | Envia dados de monitoramento | Por meio de um MongoDB Ops Manager FQDN padrão no formato: <om_resource_name>-svc.<namespace>.svc.cluster.local ou do valor de spec.opsManagerURL |
MongoDB Agent nos Pods de recursos MongoDB ou MongoDBMultiCluster | Recebe os processos de configuração, backup e restauração da automação | Através do ConfigMap do projeto, configurado ao criar um projeto |
Agente de monitoramento nos recursos Pods MongoDB ou MongoDBMultiCluster | Envia dados de monitoramento | Através do ConfigMap do projeto, configurado ao criar um projeto |
Usuário | Usa a interface do MongoDB Ops Manager usuário ou do API | Por meio de um domínio público e externo da instância MongoDB Ops Manager exposta externamente, configurada com spec.externalConnectivity |
Malha de Serviços
Adicione os nós que hospedam as instâncias do banco de dados de aplicativo e as instâncias do aplicativo MongoDB Ops Manager à mesma mescla de serviço para permitir:
Conectividade de rede entre componentes implementados.
Resolução de DNS entre clusters.
Para simplificar a configuração de rede entre as instâncias do Kubernetes Operator e do MongoDB Ops Manager , recomendamos que você adicione o cluster de operadores, que é o cluster Kubernetes onde você instala o Kubernetes Operator na mesma tela de serviço, mas isso não é um requisito rigoroso. Se você incluir o cluster de operadores na mesma tela de serviço, poderá usá-lo como host para o Aplicativo de MongoDB Ops Manager e as instâncias do Banco de Dados de Aplicativos.
Configure uma rede de serviço para os seguintes clusters Kubernetes e inclua-os na configuração de rede:
O "cluster de operadores" no qual você implementa o próprio Operador Kubernetes.
Os "clusters membros Kubernetes " que hospedarão as instâncias do aplicativo MongoDB Ops Manager .
Clusters Kubernetes de membros adicionais, ou os mesmos clusters de membros usados para o MongoDB Ops Manager, que hospedarão as instâncias do banco de dados de aplicativos.
Ter a mesma malha de serviço configurada para todos os clusters do Kubernetes garante que cada instância MongoDB Ops Manager possa estabelecer uma conexão segura com qualquer uma das instâncias do banco de dados de aplicativos implantadas em vários clusters do Kubernetes .
Depois de implantar as instâncias do banco de dados de aplicativos nos clusters dos membros do Kubernetes , o endpoint da API para cada instância MongoDB Ops Manager que você implanta nos clusters do Kubernetes dos membros deve ser capaz de se conectar diretamente a cada uma das instâncias do banco de dados de aplicativos. Isso permite que o Kubernetes Operator conclua os estágios necessários para distribuir instâncias MongoDB Ops Manager em clusters de membros, como a criação de usuários administradores e a configuração de backups.
Balanceamento de carga
Na maioria dos casos, você deve fornecer um acesso externo ao aplicativo MongoDB Ops Manager para permitir o acesso do usuário à interface do usuário do MongoDB Ops Manager .
Para sistemas de vários clusters do Aplicativo de Ops Manager, cada cluster pode expor seus Pods que hospedam o Aplicativo de Ops Manager individualmente usando um serviço do tipo LoadBalancer
.
Crie um serviço do LoadBalancer
utilizando spec.externalConnectivity
e aponte um domínio externo para o endereço IP externo deste serviço. Mesmo que você configure mais de uma instância do Aplicativo de MongoDB Ops Manager , o serviço do Kubernetes enviará tráfego de forma circular para todos os Pods disponíveis que hospedam o Aplicativo de MongoDB Ops Manager .
Como o Kubernetes Operator não oferece suporte ao balanceamento de carga do tráfego para todos os Pods em todos os clusters do Kubernetes, você deve configurar o balanceamento de carga fora da configuração do Kubernetes Operator.
Os exemplos e diagramas a seguir ilustram algumas das muitas maneiras de configurar o balanceamento de carga em vários clusters do Kubernetes.
Exemplo de Diagrama 1: Balanceador de Carga Externo
Configure um balancer de carga de rede externo (um proxy de passagem) para todos os clusters Kubernetes hospedam o Aplicativo MongoDB Ops Manager e o Banco de Dados do Aplicativo. O aplicativo MongoDB Ops Manager não tem estado. O balancer de carga pode encaminhar tráfego para o serviço LoadBalancer
de cada cluster de forma circular ou para um cluster de cada vez, se você configurar o balancer de carga de forma em que, enquanto um cluster estiver ativo, o outro cluster seja passivo. O diagrama a seguir ilustra essa abordagem.
Neste diagrama:
O Operador Kubernetes cria um serviço externo do tipo
LoadBalancer
, denominado<om_resource_name>-svc-ext
, com um endereço IP externo atribuído, em cada cluster de membros. Você pode configurar este serviço globalmente para todos os clusters de membros utilizandospec.externalConnectivity
. Ou, se esse serviço for específico para cada cluster de membros, você poderá configurá-lo usandospec.clusterSpecList.externalConnectivity
.Cada serviço que o Operador do Kubernetes cria para o Aplicativo de MongoDB Ops Manager sempre contém todos os Pods que hospedam o Aplicativo de MongoDB Ops Manager do cluster atual.
Exemplo de Diagrama 2: Balanceamento de Carga por uma Malha de Serviço, com um Proxy
Use os recursos de balanceamento de carga entre clusters fornecidos por uma camada de serviço.
Em cada Kubernetes cluster , o Kubernetes Operador cria um serviço, denominado <om_resource_name>-svc
, que você pode usar para distribuir o tráfego em todos os Pods disponíveis que hospedam as MongoDB Ops Manager instâncias do Aplicativo em todos os clusters de membros.
Você pode implantar um componente de proxy, como Nginx ou HAProxy, em um dos clusters, expô-lo externamente pela Internet por meio de seu FQDN público e configurar o proxy para encaminhar todo o tráfego de rede por meio da passagem TCP para o serviço chamado <om_resource_name>-svc.<namespace>.svc.cluster.local
.
O diagrama a seguir ilustra essa abordagem.
Neste diagrama:
Em cada cluster de membros, o Operador Kubernetes cria um serviço do tipo
ClusterIP
que você pode acessar usando<om_resource_name>-svc.<namespace>.svc.cluster.local
. É um serviço que contém em seus endpoints todos os Pods implantados nesse cluster de membros.O tráfego entre clusters do Kubernetes é tratado pela interface de serviço. Quando o Operador Kubernetes cria serviços em cada cluster de membro para o Aplicativo de MongoDB Ops Manager , o Operador Kubernetes não atribui um sufixo de índice de cluster aos nomes destes serviços. Portanto, a rede de serviços pode realizar o balanceamento de carga de tráfego para todos os Pods que hospedam o aplicativo MongoDB Ops Manager em todos os clusters.
Em cada cluster de membros, o Operador Kubernetes implementa um StatefulSet denominado
<om_resource_name>-<cluster-index>
. Por exemplo,om-0
é o nome do StatefulSet para o cluster de membros com o índice 0.Embora cada cluster tenha um serviço
<om_resource_name>-svc
ClusterIP
implantado, esse serviço não lida com o tráfego de usuários. Quando o usuário acessa o serviço noMember Cluster 1
, a malha de serviço lida com o tráfego.Cada Pod que hospeda o Aplicativo MongoDB Ops Manager recebe o mesmo nome do StatefulSet. Por exemplo,
om-1-2
é o nome do número do Pod 2 no cluster com o índice 1.