Visão geral dos grupos de endpoints de rede zonais

Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

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. Os dois tipos de NEGs zonais são compatíveis com diferentes casos de uso e tipos de balanceadores de carga.

NEGs com endpoints 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.

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.

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

NEGs com endpoints 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.

Como esses 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 o modo de balanceamento RATE ou o 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 o modo de balanceamento UTILIZATION com back-ends de NEG zonais.

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.

Para mais detalhes, consulte Como usar a subconfiguração do balanceador de carga TCP/UDP interno.

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

As ilustrações a seguir mostram componentes de configuração para balanceadores de carga em que os NEGs zonais com endpoints GCE_VM_IP_PORT são os back-ends:

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)

Para saber mais sobre os requisitos de arquitetura desses balanceadores de carga, consulte: *Visão geral do balanceador de carga HTTP(S) externo *Visão geral do balanceador de carga HTTP(S) interno *Visão geral do balanceador de carga do proxy TCP externo *Visão geral do balanceador de carga do proxy TCP regional interno *Visão geral do balanceador de carga do proxy SSL externo

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.

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.

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)

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 do recurso de Entrada facilita a criação de todos os aspectos de um balanceador de carga HTTP(S). 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 pela 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. Como alternativa, é possível criar um balanceador de carga de proxy manualmente, mas manter o GKE gerenciando a associação ao endpoint do NEG, conforme descrito no próximo ponto (NEGs independentes).

    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

    Os NEGs independentes oferecem uma maneira para o cluster do GKE criar NEGs zonais com endpoints GCE_VM_IP_PORT que representam endereços IP do pod e portas de contêiner, oferecendo flexibilidade para configurar os componentes do balanceador de carga fora do GKE.

    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.
  • Não é possível usar NEGs zonais como back-end para Balanceamento de carga de rede TCP/UDP externo.

Limitações para NEGs zonais GCE_VM_IP:

  • NEGs zonais com endpoints GCE_VM_IP são compatíveis apenas com balanceadores de carga TCP/UDP internos.
  • A propriedade default-port não é compatível com NEGs zonais GCE_VM_IP.
  • Não é possível usar o console do Google Cloud para criar ou gerenciar os NEGs GCE_VM_IP. Use gcloud ou a API REST.

Cotas

A seguir