Redes, Balanceamento de carga, Malha de serviço

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.

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 hospedando 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

• Exemplo de Diagrama 2: Balanceamento de Carga por uma Malha de Serviço, com um Proxy

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.

clique para ampliar

Neste diagrama:

1. 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 utilizando spec.externalConnectivity. Ou, se esse serviço for específico para cada cluster de membros, você poderá configurá-lo usando spec.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.

clique para ampliar

Neste diagrama:

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

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

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

4. 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 no Member Cluster 1, a malha de serviço lida com o tráfego.

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