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:
- Visão geral dos grupos de endpoints de rede
- Visão geral dos grupos de endpoints de rede da Internet
- Visão geral dos grupos de endpoints da rede sem servidor
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 por zona com endpoints
GCE_VM_IP_PORT: compatíveis como back-ends para os seguintes balanceadores de carga: - NEGs por zona com endpoints
GCE_VM_IP: compatíveis como back-ends para os seguintes 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_IPprecisa 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.
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:
Para saber mais sobre os requisitos de arquitetura desses balanceadores de carga, consulte:
- Visão geral do balanceador de carga de aplicativo externo
- Visão geral do balanceador de carga interno do aplicativo
- Visão geral do balanceador de carga de rede de proxy externo
- Visão geral do balanceador de carga de rede de proxy interno
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.
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_PORTque 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_IPsão compatíveis apenas com balanceadores de carga de rede de passagem interna e externos. - A propriedade
default-portnão é compatível com NEGs zonaisGCE_VM_IP.
Cotas
- 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.
A seguir
- Para informações sobre a configuração de NEGs zonais, consulte Configurar grupos de endpoints de rede zonais.
- Para informações sobre como usar NEGs zonais no Google Kubernetes Engine, consulte Balanceamento de carga nativo do contêiner por meio do Ingress.