Vista geral dos grupos de pontos finais de rede zonais

Um grupo de pontos finais da rede (NEG) é um objeto de configuração que especifica um grupo de pontos finais ou serviços de back-end. Os NEGs zonais são recursos zonais que representam coleções de endereços IP ou combinações de endereços IP e portas para recursos Google Cloud numa única 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. Os endereços IP para microsserviços (executados em VMs) geridos por outros orquestradores, como o Apache Mesos ou o Cloud Foundry, podem ser pontos finais. Google Cloud

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

Existem dois tipos de NEGs zonais, consoante o tipo de pontos finais de rede que compõem o NEG. Os dois tipos de NEGs zonais suportam diferentes exemplos de utilização e tipos de equilibradores de carga.

NEGs com pontos finais GCE_VM_IP

Os balanceadores de carga de rede de passagem suportam NEGs zonais com pontos finais GCE_VM_IP. Estes NEGs zonais contêm um ou mais pontos finais representados através do endereço IPv4 interno principal da interface de rede de uma VM do Compute Engine.

Embora Google Cloud use um endereço IP para representar o ponto final, o objetivo de um ponto final GCE_VM_IP é identificar a própria interface de rede. A interface de rede tem de estar na sub-rede do NEG.

Uma vez que um ponto final GCE_VM_IP identifica uma interface de rede, não pode especificar uma porta com um ponto final GCE_VM_IP.

Estes tipos de pontos finais só podem ser usados como back-ends em serviços de back-end para equilibradores de carga de rede de passagem interna e equilibradores de carga de rede de passagem externa.

NEGs com pontos finais GCE_VM_IP_PORT

Estes 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 de 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 de alias atribuído a uma interface de rede de uma VM
  • Um endereço IPv4 interno do intervalo de endereços IP de alias atribuído a uma interface de rede de VM mais um número de porta de destino

A interface de rede que contém o ponto final GCE_VM_IP_PORT tem de estar na sub-rede do NEG. Quando omite um número de porta de um ponto final GCE_VM_IP_PORT, Google Cloud usa o número de porta predefinido do NEG para o ponto final.

Como estes back-ends NEG zonais permitem especificar endereços IP e portas, pode distribuir o tráfego de forma detalhada entre aplicações ou contentores em execução nas instâncias de VMs, ou seja, o balanceamento de carga nativo de contentores. O GKE usa pontos finais GCE_VM_IP_PORT para:

Pode criar equilibradores de carga autogeridos que usam NEGs zonais cujos GCE_VM_IP_PORT pontos finais são geridos pelo GKE. Para mais detalhes, consulte o artigo Balanceamento de carga nativa do contentor através de NEGs zonais autónomos.

Os balanceadores de carga de aplicações e os balanceadores de carga de rede de proxy suportam NEGs zonais com pontos finais GCE_VM_IP_PORT.

Especificação do ponto final

Quando cria um NEG, seleciona uma zona, uma rede e uma sub-rede. Cada endereço IP do ponto final tem de estar na mesma sub-rede que o NEG zonal.

Se a rede que selecionar for uma rede de VPC no modo automático, pode omitir a especificação da sub-rede. No entanto, uma sub-rede continua associada ao GEP zonal. Se especificar uma rede VPC de modo automático, mas não especificar uma sub-rede quando criar um NEG zonal, a sub-rede que usa é a sub-rede criada automaticamente na região que contém a zona que selecionou para o NEG zonal.

O tipo de NEG zonal que cria é especificado quando cria o NEG (GCE_VM_IP ou GCE_VM_IP_PORT). Isto determina que tipos de pontos finais o NEG suporta.

GCE_VM_IP_PORT NEGs zonais

O seguinte tem de ser verdadeiro para os GCE_VM_IP_PORT NEGs zonais:

  • Tem de especificar o nome de cada ponto final da VM.

  • Cada VM de ponto final tem de estar localizada na mesma zona que o NEG.

  • Cada ponto final no NEG tem de ser uma combinação única de endereço IP e porta. Uma combinação de porta e endereço IP de ponto final única pode ser referenciada por mais de um NEG.

  • Cada VM de ponto final tem de ter uma interface de rede na mesma rede VPC que o NEG. Os endereços IP dos pontos finais têm de estar associados à mesma sub-rede especificada no NEG.

  • Cada NEG suporta até ao número máximo de pontos finais por NEG. Os pontos finais podem ser distribuídos por esse número de VMs únicas ou estar todos localizados numa VM.

Para GCE_VM_IP_PORT NEGs, quando adiciona um ponto final, pode optar por especificar um endereço IP e uma porta, apenas um endereço IP ou nenhum dos dois:

  • Se especificar um endereço IP e uma porta, o endereço IP pode ser o endereço IP interno principal da VM na interface de rede ou um IP de alias na interface de rede. A porta é à sua escolha.

  • Se especificar apenas um endereço IP, o endereço IP pode ser o endereço IP interno principal da VM na interface de rede ou um endereço IP de alias na interface de rede. A porta usada é a porta predefinida do NEG.

  • Se omitir ambos, Google Cloud seleciona o endereço IP interno principal da VM e usa a porta predefinida do NEG.

GCE_VM_IP NEGs zonais

O seguinte tem de ser verdadeiro para os GCE_VM_IP NEGs zonais:

  • Tem de especificar o nome de cada ponto final da VM.

  • Cada VM de ponto final tem de estar localizada na mesma zona que o NEG.

  • Cada ponto final num NEG tem de ser um endereço IP exclusivo.GCE_VM_IP Um endereço IP de ponto final único pode ser referenciado por mais do que um NEG.

  • Cada GCE_VM_IP NEG está sempre associado a uma rede e a uma sub-rede. Quando adiciona um ponto final, pode optar por especificar um endereço IP ou não. Se for especificado um endereço IP, tem de 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 corresponda à sub-rede do NEG.

  • Cada NEG suporta até ao número máximo de pontos finais por NEG. Os pontos finais têm de ser distribuídos por todas as VMs exclusivas. Não é possível localizar vários pontos finais numa única VM porque uma VM não pode ter mais do que uma interface de rede associada à mesma sub-rede.

Balanceamento de carga com NEGs zonais

Os NEGs zonais podem ser usados como back-ends para serviços de back-end num balanceador de carga. Quando usa um NEG zonal como back-end para um serviço de back-end, todos os outros back-ends nesse serviço de back-end também têm de ser NEGs zonais do mesmo tipo (todos GCE_VM_IP ou GCE_VM_IP_PORT). Não pode usar grupos de instâncias e NEGs zonais como back-ends no mesmo serviço de back-end.

Pode adicionar o mesmo ponto final de rede a mais do que um NEG zonal. Pode usar o mesmo NEG zonal como back-end para mais do que um serviço de back-end.

Os NEGs zonais podem usar o RATE modo de equilíbrio de carga ou o CONNECTION modo de equilíbrio de carga, consoante o protocolo do serviço de back-end.GCE_VM_IP_PORT Os equilibradores de carga suportados requerem a definição de uma capacidade alvo.

Os NEGs zonais GCE_VM_IP têm de usar o modo de equilíbrio de carga CONNECTION. Além disso, os balanceadores de carga de rede de encaminhamento interno e os balanceadores de carga de rede de encaminhamento externo não suportam a definição de capacidade de destino.

Balanceadores de carga de rede de passagem

Os NEGs zonais com pontos finais GCE_VM_IP podem ser usados como back-ends para serviços de back-end apenas para equilibradores de carga de rede de encaminhamento interno e equilibradores de carga de rede de encaminhamento externo.

Consulte as secções seguintes para ver os principais exemplos de utilização de NEGs com GCE_VM_IP endpoints.

Agrupamento flexível de pontos finais

Tal como os grupos de instâncias, pode usar o mesmo NEG como back-end para vários balanceadores de carga de rede de encaminhamento. Ao contrário dos grupos de instâncias, um ponto final do NEG pode ser membro de vários NEGs, e cada um desses NEGs pode ser usado como back-end para um ou mais balanceadores de carga de rede de passagem. Em comparação com os grupos de instâncias, não está limitado ao facto de uma instância de VM só poder fazer parte de um único grupo de instâncias.

A figura seguinte mostra uma arquitetura de equilibrador de carga de encaminhamento interno de exemplo com uma VM partilhada.

Balanceadores de carga de rede de encaminhamento interno com NEGs zonais `GCE_VM_IP` sobrepostos.
Balanceadores de carga de passagem internos com NEGs zonais sobrepostos (clique para aumentar).

Interfaces não nic0 como pontos finais de back-end

Os NEGs zonais com pontos finais GCE_VM_IP permitem o equilíbrio de carga para interfaces de rede não nic0 de VMs. Isto pode ser útil quando se integra com VMs de dispositivos de terceiros que normalmente reservam nic0 para operações de gestão. Com os GCE_VM_IP NEGs, qualquer interface de rede não nic0 da mesma VM pode ser anexada a um back-end do NEG de um equilibrador de carga de rede de passagem.

Subconjuntos do GKE

O GKE usa NEGs zonais GCE_VM_IP e subconjuntos para melhorar a escalabilidade dos balanceadores de carga de rede de passagem internos da seguinte forma:

Sem a criação de subconjuntos, o GKE cria um grupo de instâncias não gerido por zona, composto pelos nós do cluster de todos os conjuntos de nós nessa zona. Estes grupos de instâncias zonais são usados como back-ends para um ou mais serviços de LoadBalancer internos (e para entradas externas que não usam NEGs).

Com a criação de subconjuntos, o GKE cria NEGs zonais para cada serviço de balanceador de carga interno.GCE_VM_IP O mesmo ponto final pode ser membro de mais do que um NEG zonal. Ao contrário dos grupos de instâncias, Google Cloud pode equilibrar a carga para vários NEGs zonais que contêm o mesmo ponto final.

A subdivisão distribui o tráfego de forma mais eficiente para os serviços LoadBalancer internos em clusters com mais de 250 nós. Por exemplo, um cluster do GKE com 300 nós pode ter um serviço LoadBalancer interno com 25 nós num NEG porque existem 25 pods de publicação para esse serviço. Não é necessário adicionar todos os 300 nós a um back-end do grupo de instâncias para este serviço.

Tenha em atenção que as quotas para NEGs, regras de encaminhamento, serviços de back-end e outros recursos de rede da Google Cloud continuam a aplicar-se.

Para mais detalhes, consulte o artigo Usar a subdivisão do balanceador de carga de rede de encaminhamento interno.

Balanceadores de carga de aplicações e balanceadores de carga de rede de proxy

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

Grupos de pontos finais de rede zonais no balanceamento de carga.
Grupos de pontos finais da rede zonais no equilíbrio de carga (clique para aumentar).

Para saber mais acerca dos requisitos de arquitetura destes equilibradores de carga, consulte:

O exemplo de utilização principal dos NEGs zonais GCE_VM_IP_PORT é o equilíbrio de carga nativo de contentores, para que possa distribuir o tráfego diretamente para contentores em execução em VMs, por exemplo, para endereços IP de pods em clusters do GKE.

O balanceamento de carga nativa do contentor permite que os balanceadores de carga segmentem diretamente os pods e tomem decisões de distribuição de carga ao nível do pod, em vez de ao nível da VM.

O exemplo seguinte demonstra como os balanceadores de carga distribuem o tráfego entre os microsserviços executados em contentores nas suas VMs. As VMs estão configuradas para usar intervalos de IP de alias das respetivas sub-redes, e esses intervalos são os endereços usados pelos contentores.

Equilíbrio de carga de grupos de pontos finais de rede zonais com contentores.
Equilíbrio de carga de grupos de pontos finais de rede zonais com contentores (clique para aumentar).

Existem duas formas de configurar o balanceamento de carga nativo do contentor: usar NEGs geridos pela entrada do GKE ou usar NEGs autónomos.

  • Ingress do Kubernetes com NEGs (recomendado)

    Quando os NEGs são usados com a entrada, o controlador de entrada facilita a criação de todos os aspetos de um balanceador de carga HTTP(S). Isto inclui a criação do endereço IP virtual, das regras de encaminhamento, das verificações de estado, das regras de firewall e muito mais. Para saber como configurar esta opção, consulte o artigo Balanceamento de carga nativo do contentor através da entrada.

    A entrada é a forma recomendada de usar NEGs para o balanceamento de carga nativo do contentor, uma vez que tem muitas funcionalidades que simplificam a gestão de NEGs. Em alternativa, pode criar um balanceador de carga de proxy manualmente, mas continuar a fazer com que o GKE faça a gestão da associação de pontos finais do NEG, conforme descrito no ponto seguinte (NEGs autónomos).

    Para ver instruções sobre como configurar um balanceador de carga através da entrada, consulte o artigo Balanceamento de carga nativa do contentor através da entrada.

  • NEGs autónomos

    Os NEGs autónomos oferecem uma forma de o seu cluster do GKE criar NEGs zonais com GCE_VM_IP_PORT pontos finais que representam endereços IP de pods e portas de contentores, ao mesmo tempo que lhe dão a flexibilidade de configurar os componentes do equilibrador de carga fora do GKE.

    Para ver exemplos de utilização de NEGs zonais autónomos com o GKE, consulte:

Limitações

  • Não pode usar NEGs zonais com redes antigas.
  • 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 pontos finais GCE_VM_IP só são suportados com balanceadores de carga de rede de encaminhamento interno e balanceadores de carga de rede de encaminhamento externo.
  • A propriedade default-port não é suportada para NEGs zonais GCE_VM_IP.

Quotas

O que se segue?