Visão geral dos grupos de endpoints de rede zonais

Um grupo de endpoints de rede (NEG) é um objeto de configuração que especifica um grupo de endpoints ou serviços de back-end. Os NEGs zonais são recursos zonais que representam conjuntos de endereços IP ou combinações de endereço IP/porta para recursos do Google Cloud em uma sub-rede.

Os NEGs 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.

Para informações sobre outros tipos de NEG, consulte:

Há dois tipos de NEGs zonais, dependendo do tipo de endpoints de rede que o compõem. Cada um dos dois tipos de NEG zonal é compatível com diferentes casos de uso e tipos de balanceador de carga.

Não é possível usar NEGs zonais como back-end em balanceamento de carga de rede.

NEGs de GCE_VM_IP

Esses NEGs zonais contêm um ou mais endpoints de rede internos que são resolvidos para o endereço IP principal de uma VM do Compute Engine. Não é possível especificar uma porta com esse tipo de NEG zonal.

Esses endpoints só podem ser usados como back-ends em serviços de back-end para balanceadores de carga TCP/UDP internos.

Com os NEGs GCE_VM_IP, só é possível anexar endpoints que pertencem ao endereço IP interno primário de uma VM na rede VPC do NEG. Os endereços IP internos primários de qualquer NIC de uma VM de várias NICs podem ser adicionados a um NEG, desde que o NEG use a mesma rede VPC que a NIC.

NEGs de GCE_VM_IP_PORT

Esses NEGs zonais contêm um ou mais endpoints de rede internos que são resolvidos para o endereço IP interno primário de uma VM ou um endereço IP em um dos intervalos de IP do alias. Por exemplo, o GKE usa NEGs desse tipo, cujos endpoints são um endereço IP do intervalo de IP do alias do nó mais uma porta – um endereço IP do pod e uma porta do contêiner. Cada endpoint de rede é especificado usando uma combinação de endereço IP e porta.

Esses NEGs podem ser usados como back-ends em serviços de back-end para balanceadores de carga HTTP(S) externos, HTTP(S) interno, proxy TCP e balanceadores de carga de proxy SSL. Não é possível usar endpoints GCE_VM_IP_PORT com balanceadores de carga TCP/UDP internos ou balanceadores de carga de rede. 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.

Para criar um endpoint de rede GCE_VM_IP_PORT 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 GCE_VM_IP_PORT 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.

Relacionamentos de endpoint

Ao criar um NEG, 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.

O tipo de NEG zonal que você cria é especificado quando você cria o NEG (GCE_VM_IP ou GCE_VM_IP_PORT). Isso determina os tipos de endpoints compatíveis com o NEG.

Para os NEG zonais GCE_VM_IP e GCE_VM_IP_PORT:

  • É necessário especificar o nome de cada endpoint da VM.

  • Cada VM de endpoint precisa estar localizada na mesma zona que o NEG.

  • Cada endpoint no NEG precisa ser uma combinação exclusiva de endereço IP e porta. Uma combinação de endereço IP e endpoint de endpoint exclusivos pode ser referenciada por mais de um NEG.

  • Cada VM de endpoint precisa ter uma interface de rede (NIC, na sigla em inglês) na mesma rede VPC que o NEG. Os endereços IP do endpoint precisam ser associados à mesma sub-rede especificada no NEG.

  • Cada NEG suporta até o número máximo de endpoints por NEG. É possível distribuir os endpoints entre muitas VMs exclusivas ou todas localizadas em uma VM.

Para NEGs GCE_VM_IP_PORT, ao adicionar um endpoint, é possível especificar um endereço IP e uma porta, apenas um endereço IP ou nenhum:

  • Se você especificar um endereço IP e uma porta, o endereço IP poderá ser o endereço IP interno principal da NIC de VM ou um IP de alias na NIC A porta é sua escolha.

  • Se você especificar apenas um endereço IP, ele poderá ser o endereço IP interno principal da NIC de VM ou um IP de alias na placa de rede. A porta usada é a porta padrão do NEG.

  • Se você omitir os dois, o Google Cloud selecionará o endereço IP interno principal da NIC e usará a porta padrão do NEG.

Balanceamento de carga com NEGs zonais

É possível usar NEGs zonais como back-ends de serviços de back-end em um balanceador de carga. Quando você usa um NEG zonal como back-end para um serviço de back-end, todos os outros back-ends nesse serviço também precisam ser NEGs zonais do mesmo tipo (todos GCE_VM_IP ou GCE_VM_IP_PORT). Não é possível usar grupos de instâncias e NEGs zonais como back-ends no mesmo serviço de back-end.

É possível incluir o mesmo endpoint da rede 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.

NEGs zonais GCE_VM_IP_PORT podem usar amodo de balanceamento RATE ou modo de balanceamento CONNECTION, dependendo do protocolo do serviço de back-end. Os balanceadores de carga compatíveis exigem a definição de uma capacidade de destino.

NEGs zonais GCE_VM_IP precisam usar o modo de balanceamento CONNECTION e não é possível definir uma capacidade de destino porque os balanceadores de carga TCP/UDP internos não são compatíveis com a configuração de capacidade de destino.

Não é possível usar um modo de balanceamento de UTILIZATION para back-ends de NEG zonal.

Balanceamento de carga TCP/UDP interno

NEGs zonais com endpoints GCE_VM_IP podem ser usados como back-ends para serviços de back-end somente para balanceadores de carga TCP/UDP internos.

Os principais casos de uso de NEGs com endpoints GCE_VM_IP são:

Gerenciamento de VM simplificado para balanceadores de carga TCP/UDP internos

Assim como os grupos de instâncias, use o mesmo NEG como back-end para vários balanceadores de carga TCP/UDP internos. Ao contrário dos grupos de instâncias, um endpoint de VM pode ser membro de vários NEGs, e cada um deles pode ser usado como back-end em um ou mais balanceadores de carga TCP/UDP internos.

Balanceadores de carga TCP/UDP internos com `GCE_VM_IP` NEGs sobrepostos
Balanceadores de carga TCP/UDP internos com NEGs zonais sobrepostos

Subconfiguração do GKE

Usos do GKEGCP_VM_IP NEGs por zona ecriação de subconjuntos para melhorar a escalonabilidade dos balanceadores de carga TCP/UDP internos da seguinte maneira:

Sem subconfiguração, o GKE cria um grupo de instâncias não gerenciadas por zona, consistindo nos nós do cluster de todos os pools de nós nessa zona. Esses grupos de instâncias zonais são usados como back-ends para um ou mais Serviços internos do LoadBalancer (e para Entradas externas que não usam os próprios NEGs).

Com a criação de subconjuntos, o GKE cria GCE_VM_IP NEGs zonais para cada Serviço LoadBalancer interno. O mesmo endpoint pode ser membro de mais de um NEG zonal. Ao contrário dos grupos de instâncias, o Google Cloud pode balancear a carga para mais NEGs zonais que contêm o mesmo endpoint.

A criação de sub-redes distribui o tráfego para os serviços LoadBalancer internos com mais eficiência em clusters com mais de 250 nós. Por exemplo, um cluster do GKE de 300 nós pode ter um serviço LoadBalancer interno com 25 nós em um NEG porque há 25 pods de exibição para esse serviço. Nem todos os 300 nós precisam ser adicionados a um back-end de grupo de instâncias para esse serviço.

Observe que as cotas de NEGs, regras de encaminhamento, serviços de back-end e outros recursos de rede do Google Cloud ainda se aplicam.

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

NEGs zonais com endpoints GCE_VM_IP_PORT podem ser usados como back-ends para serviços de back-end nos seguintes tipos de balanceadores de carga: HTTP(S) externo, HTTP(S) interno, de proxy TCP e de proxy SSL.

O principal caso de uso de GCE_VM_IP_PORT os NEGs zonais é o balanceamento de carga nativo do contêiner para que você distribua o tráfego diretamente aos contêineres em execução nas VMs. Por exemplo, para endereços IP de pod. em clusters do GKE.

No exemplo a seguir, é demonstrado como os balanceadores de carga distribuem o tráfego entre microsserviços executados em contêineres nas suas 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.

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

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)

Caso de uso: balanceamento de carga nativo de contêiner

O balanceamento de carga nativo do contêiner permite que os balanceadores de carga segmentem pods diretamente e tomem a decisão de distribuição de carga no nível do pod, e não no nível da VM. Há duas maneiras de configurar o balanceamento de carga nativo do contêiner: pelos NEGs gerenciados pela Entrada do GKE ou pelos NEGs independentes.

Entrada do Kubernetes com NEGs (recomendado)

Quando os NEGs são usados com a Entrada, o controlador da Entrada facilita a criação de todos os aspectos do balanceador de carga L7. Isso inclui a criação de endereço IP virtual, regras de encaminhamento, verificações de integridade, regras de firewall e muito mais. Para saber como configurar isso, consulte Balanceamento de carga nativo do contêiner por meio da Entrada.

A Entrada é a maneira recomendada de usar NEGs para o balanceamento de carga nativo do contêiner, porque tem muitos recursos que simplificam o gerenciamento de NEGs. Os NEGs independentes poderão ser usados se os NEGs gerenciados pela Entrada não atenderem ao caso de uso.

Para instruções sobre como configurar um balanceador de carga por meio da Entrada, consulte Balanceamento de carga nativo do contêiner por meio da Entrada.

NEGs independentes

Quando os NEGs zonais são implantados com balanceadores de carga provisionados por algo diferente da Entrada do GKE, eles são considerados independentes. Eles são implantados e gerenciados por meio do controlador do NEG, enquanto as regras de encaminhamento, as verificações de integridade e outros componentes de balanceamento de carga são implantados manualmente.

Para exemplos de como usar NEGs zonais independentes com o GKE, consulte:

Limitações

  • Não é possível usar NEGs zonais com redes legadas.
  • 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.

Limitações para NEGs zonais GCE_VM_IP:

  • As verificações de integridade não são compatíveis com serviços de back-end com NEGs zonais GCE_VM_IP.
  • A propriedade default-port não é compatível com NEGs zonais GCE_VM_IP.
  • Não é possível usar o Console do Cloud para criar ou gerenciar NEGs GCE_VM_IP. Use gcloud ou a API REST.

Cotas

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