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

Os balanceadores de carga de rede de passagem são compatíveis com NEGs zonais com endpoints GCE_VM_IP. Esses NEGs zonais contêm um ou mais endpoints representados pelo endereço IPv4 interno primário da interface de rede de uma VM do Compute Engine.

Mesmo que o Google Cloud use um endereço IP para representar o endpoint, a finalidade de um endpoint GCE_VM_IP é identificar a própria interface de rede. A interface de rede precisa estar na sub-rede do NEG.

Como um endpoint GCE_VM_IP identifica uma interface de rede, não é possível especificar uma porta com um endpoint GCE_VM_IP.

Esses tipos de endpoints só podem ser usados como back-ends em serviços de back-end para balanceadores de carga de rede de passagem interna e de passagem externa.

NEGs com endpoints GCE_VM_IP_PORT

Esses NEGs zonais contêm uma ou mais das seguintes combinações de endereço IP ou endereço IP e porta de destino:

  • O endereço IPv4 interno principal de uma interface de rede da VM
  • O endereço IPv4 interno principal de uma interface de rede de VM mais um número de porta de destino
  • Um endereço IPv4 interno do intervalo de endereços IP do alias atribuído a uma interface de rede da VM
  • Um endereço IPv4 interno do intervalo de endereços IP do alias atribuído a uma interface de rede da VM, além de um número de porta de destino.

A interface de rede que contém o endpoint GCE_VM_IP_PORT precisa estar na sub-rede do NEG. Quando você omite um número de porta de um endpoint GCE_VM_IP_PORT, o Google Cloud usa o número de porta padrão do NEG para o endpoint.

Como esses back-ends de NEG por zona 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 (balanceamento de carga nativo de contêiner). O GKE usa endpoints GCE_VM_IP_PORT para:

É possível criar balanceadores de carga autogerenciados que usam NEGs zonais com endpoints GCE_VM_IP_PORT gerenciados pelo GKE. Para detalhes, consulte Balanceamento de carga nativo de contêiner por meio de NEGs zonais independentes.

Os balanceadores de carga de aplicativo e de rede de proxy oferecem suporte a NEGs zonais com endpoints GCE_VM_IP_PORT.

Especificação do 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.

GCE_VM_IP_PORT NEGs por zona

As seguintes condições precisam ser verdadeiras para os NEGs zonais 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 primário da VM na interface de rede ou um IP de alias na interface de rede. A porta é sua escolha.

  • Se você especificar apenas um endereço IP, ele poderá ser o endereço IP interno primário da VM na interface de rede ou um endereço IP do alias na interface 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.

GCE_VM_IPNEGs por zona

As seguintes condições precisam ser verdadeiras para os NEGs zonais GCE_VM_IP:

  • É 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 em um NEG GCE_VM_IP precisa ser um endereço IP exclusivo. Um endereço IP de endpoint exclusivo pode ser referenciado por mais de um NEG.

  • Cada NEG GCE_VM_IP é sempre associado a uma rede e sub-rede. Ao adicionar um endpoint, você pode especificar um endereço IP ou não. Se um endereço IP for especificado, ele precisará ser definido como o endereço IP interno principal da instância de VM anexada que corresponde à sub-rede do NEG. O endereço IP interno principal de qualquer interface de rede de uma instância de VM com várias NICs pode ser adicionado a um NEG, desde que ele corresponda à sub-rede do NEG.

  • Cada NEG suporta até o número máximo de endpoints por NEG. Os endpoints precisam ser distribuídos entre todas as VMs exclusivas. Não é possível localizar vários endpoints em uma única VM, porque uma VM não pode ter mais de uma interface de rede associada à mesma sub-rede.

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.

Os NEGs zonais GCE_VM_IP precisam usar o modo de balanceamento CONNECTION. Além disso, os balanceadores de carga de rede de passagem interna e os balanceadores de carga de rede de passagem externa não são compatíveis com a configuração de capacidade desejada.

Balanceadores de carga de rede de passagem

NEGs zonais com endpoints GCE_VM_IP podem ser usados como back-ends para serviços de back-end somente para balanceadores de carga de rede de passagem interna e balanceadores de carga de rede de passagem externa.

Consulte as seções a seguir para os principais casos de uso de NEGs com endpoints GCE_VM_IP.

Agrupamento flexível de endpoints

Assim como em grupos de instâncias, é possível usar o mesmo NEG como back-end para vários balanceadores de carga de rede de passagem interna. 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 de rede de passagem internos. Em comparação com os grupos de instâncias, você não se limita ao fato de que uma instância de VM só pode fazer parte de um único grupo.

A figura a seguir mostra um exemplo de arquitetura do balanceador de carga de rede de passagem interna com uma VM compartilhada.

Balanceadores de carga de rede de passagem interna com NEGs zonais "GCE_VM_IP" sobrepostos.
Balanceadores de carga de rede de passagem interna com NEGs zonais sobrepostos (clique para ampliar).

Interfaces que não são nic0 como endpoints de back-end

NEGs zonais com endpoints GCE_VM_IP permitem o balanceamento de carga para interfaces de rede que não são nic0. Isso pode ser útil na integração com VMs de dispositivos de terceiros que normalmente reservam nic0 para operações de gerenciamento. Com NEGs GCE_VM_IP, qualquer interface de rede diferente de nic0 da mesma VM pode ser anexada a um back-end de NEG de um balanceador de carga de rede de passagem.

Subconfiguração do GKE

Usos do GKE GCE_VM_IP NEGs por zona ecriação de subconjuntos para melhorar a escalonabilidade dos balanceadores de carga de rede de passagem 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 de rede de passagem interna.

Balanceadores de carga de aplicativo e de rede proxy

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

O principal caso de uso de NEGs zonais GCE_VM_IP_PORT é 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.

Balanceamento de carga de grupos de endpoints de rede zonais com contêineres.
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.

Limitações para NEGs zonais GCE_VM_IP:

  • Os NEGs zonais com endpoints GCE_VM_IP são compatíveis apenas com balanceadores de carga de rede de passagem interna e externos.
  • A propriedade default-port não é compatível com NEGs zonais GCE_VM_IP.

Cotas

A seguir