Grupos de endpoints da rede nos conceitos do balanceamento de carga

Use os grupos de endpoint da rede (NEGs, na sigla em inglês) como o back-end de um serviço de back-end. O principal uso dessa configuração é a implantação de contêineres nas suas VMs para que você possa executar serviços nos contêineres. Também é possível distribuir o tráfego de maneira granular para aplicativos em execução nas VMs.

Neste documento, você verá uma discussão sobre o uso de grupos de endpoints da rede com os seguintes tipos de balanceador de carga:

Não é possível usar NEGs como back-end com os seguintes tipos de balanceador de carga:

Visão geral

Os grupos de endpoint da rede (NEGs, na sigla em inglês) são recursos zonais que representam conjuntos de combinações de endereços IP e portas para recursos do GCP em uma única sub-rede. Cada combinação de endereço IP e porta é chamado de endpoint da rede.

Os grupos de endpoint da rede podem ser usados como back-ends em serviços de back-end para balanceamento de carga HTTP(S), HTTP(S) interno, proxy TCP, e para balanceadores de carga de proxy SSL. Não é possível usar NEGs como back-end com balanceadores de carga TCP/UDP internos. Como os back-ends de NEG permitem especificar endereços IP e portas, é possível distribuir o tráfego de maneira granular entre aplicativos ou contêineres em execução em instâncias de VM.

Relacionamentos de endpoint

Ao criar um grupo de endpoints da rede, você seleciona uma zona, uma rede e uma sub-rede. Cada endereço IP de endpoint precisa estar na mesma sub-rede que o NEG.

Se a rede selecionada for uma rede de modo automático, é possível omitir a especificação da sub-rede. No entanto, uma sub-rede ainda está associada ao NEG. Se você especificar uma rede de modo automático, mas não especificar uma sub-rede ao criar um NEG, a sub-rede usada será a sub-rede criada automaticamente na região que contém a zona selecionada para o NEG.

No momento, os grupos de endpoint da rede suportam apenas o tipo GCE_VM_IP_PORT. Isso significa que os endpoints individuais precisam ter endereços IP associados às VMs do GCP. Ao adicionar endpoints a um NEG, faça o seguinte:

  • Especifique o nome de uma instância de VM. A instância de VM precisa estar na mesma zona que o NEG, e sua interface de rede na rede VPC precisa estar em uma sub-rede na mesma região que contém essa zona.

  • É possível ter até 10.000 endpoints em um NEG e todos podem estar na mesma VM. Cada endpoint é criado fazendo referência à VM ao adicionar um endpoint a um NEG atual. Os endpoints criados em diferentes NEGs podem apontar para a mesma VM.

    • É possível especificar um endereço IP ou uma combinação de porta e endereço IP, além de especificar a instância de VM. Qualquer endereço IP especificado precisa ser o endereço IP interno primário da VM ou um IP de alias para a VM na mesma sub-rede que o NEG.

    • Se você não especificar um endereço IP ao adicionar um endpoint, o endereço IP interno primário da VM na rede VPC será usado.

    • Se você não especificar uma porta ao adicionar um endpoint, é preciso ter definido uma porta padrão para o NEG. Os endpoints usam a porta padrão a menos que especifiquem uma porta própria. Isso significa que você precisa especificar uma porta padrão ao criar um NEG ou especificar uma porta para cada endpoint adicionado a ele.

    • Cada endpoint em um NEG precisa ser uma combinação exclusiva de endereço IP e porta. Se uma porta não for especificada para um endereço IP, a combinação será criada usando o IP e a porta padrão.

Endpoints, contêineres e serviços

Para criar um endpoint de rede exclusivo para um contêiner ou aplicativo em execução em uma VM, você precisa usar o endereço IP principal da VM ou um IP secundário atribuído à VM usando o recurso de endereço IP do alias. O software em execução no contêiner ou o aplicativo em execução na VM precisa ser configurado para vincular-se ao endereço IP usado pelo endpoint da rede.

Os NEGs são úteis para o GKE. Para informações sobre o uso de NEGs com o GKE, consulte Como usar o balanceamento de carga nativo do contêiner.

Os NEGs também são úteis porque permitem criar agrupamentos lógicos de endereços IP e portas que representam serviços de software em vez de VMs inteiras. Endereços IP para microsserviços (em execução nas VMs do GCP) gerenciados por outros orquestradores, como o Apache Mesos ou o Cloud Foundry (links em inglês), podem ser endpoints.

Balanceamento de carga

Serviços de back-end

Os NEGs podem ser usados como back-ends para serviços de back-end em um balanceador de carga. Quando você usa um NEG como back-end para um serviço de back-end, todos os outros back-ends nesse serviço também precisam ser NEGs. Não é possível usar grupos de instância e NEGs como back-end no mesmo serviço.

É possível adicionar o mesmo endpoint da rede (combinação de endereços IP e portas) em mais de um NEG. Use o mesmo NEG como back-end para mais de um serviço.

Os serviços de back-end que usam NEGs para back-ends só podem usar os modos de balanceamento de RATE ou CONNECTION. Não é possível usar um modo de balanceamento de UTILIZATION para serviços que usam NEGs como back-ends.

Balanceamento de carga de proxy SSL, HTTP (S), HTTP(S) interno e proxy TCP.

Use grupos de endpoint da rede em balanceadores de carga usando camadas de serviço de rede Padrão ou Premium.

As ilustrações a seguir mostram os componentes de configuração dos balanceadores de carga HTTP(S), proxy TCP/SSL e HTTP(S) interno em que os NEGs são os back-ends:

  • Cada balanceador de carga HTTP(S), proxy SSL e proxy TCP de nível Premium tem a própria regra de encaminhamento externa global para direcionar o tráfego ao objeto apropriado do proxy de destino.

  • Cada balanceador de carga HTTP(S), proxy SSL e proxy TCP de nível Padrão tem sua própria regra de encaminhamento externa regional para direcionar o tráfego para o objeto apropriado do proxy de destino.

  • Cada balanceador de carga HTTP(S) interno (Beta) tem sua própria regra de encaminhamento gerenciada interna regional para direcionar o tráfego para o objeto apropriado do proxy de destino.

  • Para proxies HTTP(S) de destino, o serviço de back-end usado é determinado pela verificação do nome do host e do caminho da solicitação no mapa de URLs. Os balanceadores de carga de HTTP(S) externo e interno podem ter vários serviços de back-end referenciados a partir do mapa de URLs.

  • Para proxies TCP de destino ou SSL de destino, apenas um serviço de back-end pode ser definido.

  • O serviço de back-end direciona o tráfego para os NEGs de back-end. Para cada solicitação, o balanceador de carga escolhe um endpoint da rede de um dos NEGs e envia o tráfego para lá.

Grupos de endpoints da rede no balanceamento de carga (clique para ampliar)
Grupos de endpoints da rede no balanceamento de carga (clique para ampliar)

Balanceamento de carga com contêineres

O exemplo a seguir demonstra como distribuir o tráfego entre microsserviços executados em contêineres nas suas VMs. As VMs são configuradas para usar intervalos de IP do alias em suas sub-redes, e esses intervalos são os endereços usados pelos contêineres. São usados balanceamento de carga HTTP(S), HTTP(S) interno, proxy TCP ou proxy SSL.

Grupos de endpoints da rede de balanceamento de carga com contêineres (clique para ampliar)
Grupos de endpoints da rede de balanceamento de carga com contêineres (clique para ampliar)

Este exemplo pode ser configurado da seguinte maneira:

  1. Configure contêineres ou serviços nas VMs. Se vários contêineres forem executados em cada VM ou se você precisar de endereços IP para os contêineres, configure endereços IP de alias nas VMs. Se você estiver configurando serviços, precisará de dois ou mais serviços em execução na mesma VM, de modo que pelo menos os números de porta sejam diferentes.
  2. Crie grupos de endpoints da rede. Se você estiver usando o Kubernetes ou o Google Kubernetes Engine, essa etapa não será necessária porque o controlador Ingress cria os NEGs.
  3. Adicione endpoints da rede aos grupos de endpoints da rede.
  4. Crie uma verificação de integridade.
  5. Crie um serviço de back-end.
  6. Para balanceamento de carga HTTP(S), crie um mapa de URLs e conecte o serviço de back-end a ele.
  7. Crie o tipo apropriado de proxy de destino, como um proxy HTTP, um proxy HTTPS, um proxy SSL ou um proxy TCP. Vincule o proxy de destino ao mapa de URLs (para balanceamento de carga HTTP(S)) ou ao serviço de back-end (para balanceamento de carga de proxy TCP e proxy SSL).
  8. Crie uma regra de encaminhamento e vincule-a ao proxy de destino.

Consulte Exemplo de grupo de endpoints da rede de balanceamento de carga para um exemplo configurado usando a ferramenta de linha de comando gcloud.

Restrições

  • Não é possível usar NEGs com redes legadas.
  • O endereço IP de um endpoint da rede precisa ser um IP principal ou de alias que pertença à instância de VM especificada.

Limites

  • Os NEGs só podem ser usados como back-ends em balanceadores de carga. Os seguintes tipos de balanceador de carga são compatíveis com NEGs: HTTP(S), HTTP(S) interno, proxy TCP e proxy SSL.
  • Somente o modo de balanceamento RATE é aceito por NEGs no balanceamento de carga HTTP(s), enquanto CONNECTION é compatível com balanceamento de carga TCP/SSL. O balanceamento de carga baseado em utilização não é compatível.
  • Cada NEG pode conter até 10.000 endpoints.
  • O número máximo de NEGs que é possível ter por projeto é de pelo menos 100. Entre em contato com a equipe de vendas do GCP se precisar aumentar esse limite.
  • Um serviço de back-end que usa NEGs como back-ends também não pode usar grupos de instância como back-ends.
  • Cada serviço de back-end pode ter até 50 NEGs. Os NEGs podem estar na mesma zona ou em zonas diferentes.
  • Somente endereços IP internos (RFC 1918) podem ser adicionados a um NEG.

Solução de problemas

O tráfego não alcança os endpoints

Depois que o serviço é configurado, novos endpoints geralmente ficam acessíveis depois de serem anexados ao NEG, desde que eles respondam a verificações de integridade.

Se o tráfego não alcançar os endpoints, resultando em um código de erro 502 para HTTP(s) ou conexões rejeitadas para balanceadores de carga TCP/SSL, verifique o seguinte:

  • Verifique se as regras de firewall permitem o tráfego TCP de entrada para seus endpoints a partir dos seguintes intervalos: 130.211.0.0/22 e 35.191.0.0/16.
  • Verifique se seus endpoints estão íntegros usando gcloud, como mostrado abaixo, ou chamando a API getHealth no recurso de serviço de back-end ou a API listEndpoints no NEG com o parâmetro showHealth definido como SHOW. O comando gcloud a seguir mostra informações de integridade por endpoint da rede:
    gcloud compute network-endpoint-groups list-network-endpoints --zone=ZONE

A seguir

Esta página foi útil? Conte sua opinião sobre:

Enviar comentários sobre…