Visão geral dos grupos de endpoints de rede zonais

Os grupos de endpoints de rede (NEGs, na sigla em inglês) zonais podem ser usados como 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, abordamos o uso de grupos de endpoints de rede zonais com os seguintes tipos de balanceador de carga:

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

Saiba mais sobre os NEGs da Internet em Visão geral dos grupos de endpoints da rede da Internet.

Saiba mais sobre NEGs sem servidor em Visão geral de grupos de endpoints de rede sem servidor.

Visão geral

Os grupos de endpoints de rede zonais (NEGs) são recursos de uma zona que representam conjuntos de combinações de endereços IP e portas para recursos do Google Cloud em uma única sub-rede. Cada combinação de endereço IP e porta é chamada de endpoint de rede.

Os NEGs zonais podem ser usados como back-ends em serviços de back-end para balanceamento de carga HTTP(S) e HTTP(S) interno, bem como balanceadores de carga de proxy TCP e de proxy SSL. Não é possível usar NEGs zonais como back-end em balanceadores de carga TCP/UDP internos. Como os back-ends de NEG zonais permitem especificar endereços IP e portas, é possível distribuir o tráfego de maneira granular entre aplicativos ou contêineres em execução dentro das 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. Todos os endereços IP dos endpoints precisam estar na mesma sub-rede do NEG zonal.

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

No momento, os grupos de endpoints de rede são compatíveis com o tipo GCE_VM_IP_PORT. Isso significa que os endpoints individuais precisam ter endereços IP associados às VMs do Google Cloud. Ao incluir endpoints a um NEG zonal, observe os seguintes pontos:

  • Especifique o nome de uma instância de VM. A instância de VM precisa estar na mesma zona do NEG zonal. Além disso, sua interface de rede na rede VPC precisa estar em uma sub-rede na mesma região em que está a zona.

  • É possível ter até 10.000 endpoints em um NEG zonal, e todos podem estar na mesma VM. Cada endpoint é criado ao referenciar a VM quando incluído em um NEG zonal existente. Os endpoints criados em NEGs zonais diferentes 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. O endereço especificado precisa ser o endereço IP interno primário ou um IP de alias da VM na mesma sub-rede do NEG zonal.

    • 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 não especificar uma porta ao incluir um endpoint, é necessário que você tenha definido uma porta padrão para o NEG zonal. Os endpoints usarão a porta padrão, a não ser que uma porta própria seja especificada. Isso significa que você precisa especificar uma porta padrão ao criar um NEG zonal ou uma porta para cada endpoint incluído nele.

    • É necessário que cada endpoint em um NEG zonal seja 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 principalmente para trabalhar com o GKE. Saiba mais sobre como usar esses dois serviços juntos em Como usar balanceamento de carga nativo de 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 de microsserviços (em execução nas VMs do Google Cloud) gerenciados por outros orquestradores, como o Apache Mesos ou o Cloud Foundry (páginas em inglês), podem ser endpoints.

Balanceamento de carga

Serviços de back-end

É possível usar NEGs zonais como back-ends de serviços de back-end em um balanceador de carga. Ao fazer isso, os demais back-ends do serviço também precisam ser NEGs zonais. Não é possível usar grupos de instâncias e NEGs zonais como back-ends no mesmo serviço de back-end.

Você pode incluir o mesmo endpoint de rede (combinação de endereço IP e porta) em mais de um NEG zonal. Também é possível usar o mesmo NEG zonal como back-end em mais de um serviço de back-end.

Os serviços de back-end que usam NEGs zonais como back-ends só podem usar os modos de balanceamento de RATE ou CONNECTION. Neste caso, não é possível usar o modo de balanceamento de UTILIZATION.

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

É possível usar NEGs zonais em balanceadores de carga com os níveis de serviço de rede Standard ou Premium.

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

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

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

  • Cada balanceador de carga HTTP(S) interno tem a própria regra de encaminhamento gerenciado interno 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 zonais de back-end. Em cada solicitação, o balanceador de carga escolhe um endpoint de rede de um dos NEGs zonais e envia o tráfego para lá.

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

Balanceamento de carga com contêineres

No exemplo a seguir, demonstramos como distribuir o tráfego entre microsserviços executados em contêineres nas VMs. As VMs são configuradas para usar intervalos de IPs de alias das respectivas sub-redes. 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.

Balanceamento de carga em grupos de endpoints de rede zonais com contêineres (clique para ampliar)
Balanceamento de carga em grupos de endpoints de rede zonais com contêineres (clique para ampliar)

Esse 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 NEGs zonais. Se você estiver usando o Kubernetes ou o Google Kubernetes Engine, esta etapa não será necessária porque o controlador de Entrada criará os NEGs zonais.
  3. Inclua endpoints de rede nos NEGs zonais.
  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.

Veja um exemplo de configuração com a ferramenta de linha de comando gcloud no exemplo de balanceamento de carga de grupo de endpoints de rede zonal

Restrições

  • Não é possível usar NEGs zonais 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 zonais podem ser usados apenas como back-ends de balanceadores de carga. Os tipos de balanceador de carga compatíveis com NEGs zonais são: HTTP(S) externo, HTTP(S) interno, de proxy TCP e de proxy SSL.
  • Somente o modo de balanceamento RATE é compatível com NEGs zonais para o balanceamento de carga HTTP(S), enquanto o modo CONNECTION é compatível com o balanceamento de carga TCP/SSL. O balanceamento de carga baseado em utilização não é compatível.
  • Um serviço de back-end que usa NEGs como back-ends também não pode usar grupos de instâncias como back-ends.
  • No momento, somente endereços IP internos (RFC 1918) podem ser incluídos em um NEG zonal.
  • Veja informações sobre cotas de NEGs, como NEGs por projeto, NEGs por serviço de back-end e endpoints por NEG na página de cotas de balanceamento de carga.

Resolver problemas

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

Depois que o serviço é configurado, os novos endpoints geralmente ficam acessíveis depois de serem anexados ao NEG zonal, desde que eles respondam às 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 autorizam o tráfego TCP de entrada nos seus endpoints proveniente dos seguintes intervalos: 130.211.0.0/22 e 35.191.0.0/16.
  • Verifique se seus endpoints estão íntegros usando gcloud, conforme mostrado abaixo, ou chamando a API getHealth no recurso do serviço de back-end ou a API listEndpoints no NEG zonal com o parâmetro showHealth definido como SHOW. O comando da gcloud a seguir mostra informações sobre a integridade por endpoint:
gcloud compute network-endpoint-groups list-network-endpoints NAME \
    --zone=ZONE

A seguir