Visão geral de grupos de endpoints de rede da Internet

O Cloud Load Balancing é compatível com o proxy de tráfego para back-ends externos fora do Trusted Cloud by S3NS. Para definir um back-end externo para um balanceador de carga, use um recurso chamado de grupo de endpoints de rede (NEG, na sigla em inglês) da Internet.

Use esse tipo de implantação quando quiser exibir conteúdo de um back-end externo, mas quiser que o balanceador de carga Trusted Cloud seja o front-end. Isso permite que você:

• Usar a infraestrutura do Google Edge para encerrar conexões de usuário.
• Direcionar as conexões para o back-end externo.
• Enviar tráfego para o endpoint público por meio do backbone privado do Google, o que aumenta a confiabilidade e pode diminuir a latência entre o cliente e o servidor.

Nas seções a seguir, explicamos como os back-ends externos são usados com o Cloud Load Balancing. Se você quiser usar um back-end externo com o Cloud Service Mesh, consulte Cloud Service Mesh com grupos de endpoints de rede da Internet.

Terminologia

Às vezes, os termos a seguir são usados de maneira intercambiável porque têm significados iguais ou semelhantes:

• Back-end externo:um back-end que reside fora do Trusted Cloud by S3NS e pode ser acessado pela Internet. O endpoint em um NEG da Internet.
• Grupo de endpoints da rede na Internet (NEG): o recurso da API Trusted Cloud by S3NS usado para especificar um back-end externo.
• Endpoint externo: igual a um back-end externo.

Este documento usa o termo back-end externo, exceto ao se referir ao recurso de API do NEG da Internet.

Componentes do balanceador de carga

Nesta seção, descrevemos a arquitetura de balanceamento de carga e os recursos necessários para configurar um balanceador de carga com um back-end externo. O balanceador de carga requer uma configuração especial apenas para o serviço de back-end. A configuração do front-end é a mesma que qualquer outro balanceador de carga.

As figuras a seguir mostram os recursos do Trusted Cloud necessários para configurar um balanceador de carga com um back-end externo.

Só é possível usar NEGs da Internet no nível de serviço de rede Premium.

Configuração de front-end

Nenhuma configuração de front-end especial é necessária para criar um balanceador de carga com um back-end de NEG da Internet. Regras de encaminhamento são usadas para rotear o tráfego por endereço IP, porta e protocolo para um proxy de destino. O proxy de destino encerra as conexões dos clientes. Além disso, balanceadores de carga baseados no Envoy exigem uma sub-rede somente proxy.

Os balanceadores de carga de aplicativo também usam mapas de URL para configurar o roteamento baseado em URL de solicitações aos serviços de back-end apropriados.

Para mais detalhes sobre cada um desses componentes, consulte as seções de arquitetura do respectivo balanceador de carga:

• 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

NEG da Internet

Um NEG da Internet é um recurso usado para definir um back-end externo para o balanceador de carga. Há dois tipos de NEGs da Internet: NEG global da Internet e NEG regional da Internet. Eles diferem no escopo (global x regional) e no comportamento. O back-end externo referenciado por um NEG da Internet global precisa ser acessível exclusivamente pela Internet. Ele não pode ser acessado pelo Cloud VPN ou pelo Cloud Interconnect. Se o back-end externo se referir a um serviço ou uma API do Google, o serviço precisará ser acessível pela porta TCP 80 ou 443 usando o protocolo HTTP, HTTPS ou HTTP/2.

Há duas maneiras de configurar o endpoint externo referenciado pelo NEG: INTERNET_FQDN_PORT ou INTERNET_IP_PORT. Se o formato INTERNET_IP_PORT for escolhido, só será possível usar um endereço IP roteável da Internet pública. Se o formato INTERNET_FQDN_PORT for escolhido, o FQDN poderá ser resolvido para um endereço IP roteável da Internet pública ou para um endereço IP particular, dependendo do escopo do endpoint: regional ou global.

As NEGs regionais da Internet são alimentadas por proxies Envoy gerenciados. Cada NEG pode ter vários endpoints, e um serviço de back-end pode incluir vários NEGs da Internet.

Para o tráfego de saída, é possível configurar gateways do Cloud NAT para definir os endereços IP de origem. Outra opção é rotear o tráfego usando rotas aprendidas na sua rede VPC. Embora o Cloud NAT não seja necessário para esse método de roteamento, ele é compatível.

A tabela a seguir descreve como diferentes balanceadores de carga oferecem suporte a NEGs regionais da Internet.

Balanceadores de carga	Tipo de endpoint	Definição do endpoint	Escopo	Verificações de integridade
Balanceador de carga de aplicativo externo regional Balanceador de carga de aplicativo interno regional Balanceador de carga de rede de proxy externo regional Balanceador de carga de rede de proxy interno regional	INTERNET_FQDN_PORT	Um nome de domínio totalmente qualificado que pode ser resolvido publicamente ou de forma privada e uma porta opcional. Por exemplo, backend.example.com:443*. O nome de domínio precisa ser resolvido pelo Cloud DNS. São permitidos no máximo 256 endpoints por NEG.	Regional	Verificações de integridade distribuídas do Envoy
	INTERNET_IP_PORT	Apenas um endereço IP roteável publicamente e uma porta opcional. Por exemplo, 8.8.8.8:4432. O endereço IP não pode ser RFC 1918. São permitidos no máximo 256 endpoints por NEG.

Resolução DNS para endpoints regionais INTERNET_FQDN_PORT

Se seu domínio puder ser resolvido pela Internet, nenhuma outra configuração precisará ser definida no DNS. No entanto, se você estiver resolvendo FQDNs particulares, será necessário configurar o Cloud DNS para facilitar a resolução de DNS. O nome precisa estar hospedado no Cloud DNS ou ser resolvido via encaminhamento de DNS do Cloud DNS para um DNS local ou peering de DNS se estiver referenciando uma zona DNS privada em outra rede VPC.

Comece criando uma zona do Cloud DNS para hospedar os registros DNS no seu projeto. Em seguida, adicione os registros DNS a ele. Para ver etapas específicas de configuração, consulte a documentação do Cloud DNS. A ordem de resolução do Cloud DNS é detalhada em Ordem de resolução de nomes.

Se você estiver usando a VPC compartilhada, observe os requisitos de rede específicos. Também é possível usar outros recursos do Cloud DNS, como as zonas de encaminhamento, para buscar registros de um servidor DNS local.

Resolução de endereços IP para endpoints regionais INTERNET_FQDN_PORT

Os NEGs regionais da Internet são compatíveis com a resolução de nome de domínio usando o Cloud DNS.

Se o servidor DNS retornar vários endereços IP, o Envoy fará o balanceamento de carga do tráfego entre os endereços IP retornados com base no algoritmo de balanceamento de carga configurado (round-robin, solicitação mínima e assim por diante). A lista de endpoints é atualizada periodicamente com base no TTL do DNS. É possível configurar políticas de nova tentativa para forçar o Envoy a tentar se conectar a outro endereço IP se um deles falhar.

Serviço de back-end

Os serviços de back-end fornecem informações de configuração ao balanceador de carga. Os balanceadores de carga usam as informações de um serviço de back-end para direcionar o tráfego de entrada para um ou mais back-ends anexados.

Para configurar um balanceador de carga com um back-end externo, configure o serviço de back-end com um back-end de NEG da Internet. Quando você adiciona um NEG da Internet a um serviço de back-end, as seguintes considerações se aplicam, dependendo do escopo do NEG:

• O serviço de back-end também não pode usar outros tipos de back-end (como NEGs zonais ou grupos de instâncias) como back-ends.

• Número de NEGs por serviço de back-end

  • NEGs regionais. É possível adicionar até 50 NEGs da Internet ao mesmo serviço de back-end.

• Número de endpoints por NEG

  • NEGs regionais. É possível adicionar até 256 endpoints por NEG ao mesmo serviço de back-end.

  Os NEGs regionais não são compatíveis com modos de balanceamento de carga, como taxa, conexão ou utilização. Todos os endpoints de todos os NEGs anexados a um serviço de back-end são agrupados em um único pool. O balanceamento de carga do tráfego entre esse pool de endpoints é processado usando algoritmos de balanceamento de carga do Envoy. Para saber os algoritmos da política de balanceamento de carga compatíveis, consulte localityLbPolicy na documentação da API do serviço de back-end regional.

• Verificações de integridade

  • NEGs regionais. O balanceador de carga usa verificações de integridade distribuídas do Envoy.

• O esquema de balanceamento de carga do serviço de back-end precisa corresponder ao esquema necessário ao balanceador de carga que você está implantando. Para ver a lista completa, consulte Serviços de back-end.

• O protocolo do serviço de back-end precisa ser HTTP, HTTPS ou HTTP2.

  É altamente recomendável usar HTTPS ou HTTP/2 como protocolo ao configurar um serviço de back-end com um NEG da Internet para que a comunicação entre o balanceador de carga e o back-end seja criptografada e autenticada durante s transição para Internet pública.

  Além disso, ao usar HTTPS ou HTTP/2 como protocolo de back-end, use um endpoint INTERNET_FQDN_PORT para criar o back-end externo. Você terá estas duas vantagens:

  • Isso garante que o balanceador de carga valide o certificado do servidor SSL apresentado pelo back-end externo e verifique se as seguintes informações são verdadeiras:

    • O certificado é assinado por autoridades de certificação (CAs, na sigla em inglês) conhecidas.
    • o certificado não expirou;
    • a assinatura do certificado é válida;
    • O FQDN configurado corresponde a um dos nomes alternativos para o requerente (SANs) no certificado.

    Se você criar o back-end externo usando um endpoint INTERNET_IP_PORT, a validação do certificado do servidor SSL não será executada.

  • A extensão de indicação de nome do servidor (SNI, na sigla em inglês) SSL é compatível apenas com endpoints INTERNET_FQDN_PORT. O FQDN configurado recebe um SNI no client hello durante o handshake de SSL entre o balanceador de carga e o endpoint externo. A SNI não é enviada quando você usa um endpoint INTERNET_IP_PORT porque os literais de endereço IP não são permitidos no campo HostName de um payload de SNI.

Verificações de integridade

A configuração da verificação de integridade varia de acordo com o tipo de balanceador de carga:

• Balanceador de carga de aplicativo externo regional, balanceador de carga de aplicativo interno regional, balanceador de carga de rede de proxy externo regional e balanceador de carga de rede de proxy interno regional. As verificações de integridade são opcionais. As sondagens da verificação de integridade nesses balanceadores de carga são provenientes da sub-rede somente proxy e, em seguida, são convertidas por NAT (usando o Cloud NAT) para endereços IP pré-reservados ou endereços IP NAT alocados automaticamente. Para detalhes, consulte NEGs regionais: usar um gateway do Cloud NAT.

  As verificações de integridade do Envoy distribuídas são criadas usando os mesmos processos doTrusted Cloud console, da CLI gcloud e da API que as verificações de integridade centralizadas. Nenhuma outra configuração é necessária.

  Observações:

  • As verificações de integridade do gRPC não são suportadas.
  • As verificações de integridade com o protocolo PROXY v1 ativado não são suportadas.

  • Como o plano de dados do Envoy processa verificações de integridade, não é possível usar o console doTrusted Cloud , a API ou a CLI gcloud para verificar o status de integridade desses endpoints externos. Para NEGs híbridos com balanceadores de carga baseados no Envoy, o console Trusted Cloud mostra o status da verificação de integridade comoN/A. Isso já é esperado.

  • Cada proxy Envoy atribuído à sub-rede somente proxy da região na rede VPC inicia verificações de integridade de maneira independente. Portanto, talvez você perceba um aumento no tráfego de rede devido a uma verificação de integridade. O aumento depende do número de proxies Envoy atribuídos à sua rede VPC em uma região, da quantidade de tráfego recebida por esses proxies e do número de endpoints que cada proxy Envoy precisa verificar. Na pior das hipóteses, o tráfego de rede aumenta a uma taxa quadrática (O(n^2)) devido às verificações.

  • Os registros das verificações de integridade distribuídas do Envoy não incluem estados de integridade detalhados. Para detalhes sobre o que é registrado, consulte Geração de registros de verificação de integridade. Para uma melhor resolução de problemas de conectividade via proxies do Envoy com os endpoints do NEG, verifique também os respectivos registros do balanceador de carga.

    • Geração de registros do balanceador de carga de aplicativo externo regional
    • Geração de registros do balanceador de carga de aplicativo interno
    • Geração de registros do balanceador de carga de rede proxy

Ativar o back-end externo para receber solicitações

Configure seu back-end externo para permitir o tráfego de Trusted Cloud.

NEGs regionais: usar um gateway do Cloud NAT

Se você estiver usando um NEG regional da Internet, primeiro configure um gateway do Cloud NAT para alocar um conjunto de intervalos de endereços IP que originará o tráfego de Trusted Cloud .

O endpoint do gateway precisa ser do tipo ENDPOINT_TYPE_MANAGED_PROXY_LB.

O gateway do Cloud NAT pode ser configurado para alocar dinamicamente endereços IP externos com base na demanda ou usar um conjunto de endereços IP externos pré-reservados manualmente.

• Endereços IP alocados automaticamente

  Use endereços IP alocados automaticamente se o ambiente de back-end externo não exigir que você adicione endereços IP específicos Trusted Cloud que podem enviar tráfego para o back-end externo a uma lista de permissões.

• Endereços IP alocados manualmente

  Use endereços IP alocados manualmente somente se o ambiente de back-end externo exige que você adicione endereços IP específicos do Trusted Cloud a uma lista de permissões. Como cada Envoy atribuído à sub-rede de proxy consome uma endereço IP, verifique se o pool de endereços IP reservados é grande o suficiente para acomodar todos os Envoys.

  Se você tiver problemas de conectividade em escala, verifique se atingiu os limites do Cloud NAT. Por padrão, o limite é de 50 endereços IP NAT alocados manualmente por gateway.

A alocação dinâmica de portas é compatível com NEGs regionais da Internet. Os endereços IP podem ser compartilhados por proxies, sendo totalmente utilizados.

Essa configuração do Cloud NAT se aplica a toda a sub-rede somente proxy. O tráfego da Internet associado a todos os balanceadores de carga baseados no Envoy na região compartilha o mesmo gateway NAT.

O uso do Cloud NAT gera cobranças pelo tráfego do usuário e pelo tráfego da verificação de integridade. Para detalhes sobre como funcionam os preços de NEG regional da Internet, consulte este link.

Há algumas limitações para gateways NAT configurados em sub-redes somente proxy:

• Apenas a conversão NAT um para um é realizada. O compartilhamento de endereços IP não é compatível.
• A geração de registros e o monitoramento não são compatíveis. Ou seja, as flags --enable-logging e --log-filter não são compatíveis.

Autenticar solicitações para o back-end externo

Esta seção se aplica somente aos balanceadores de carga de aplicativo.

Para autenticar as solicitações enviadas ao seu back-end externo, siga um destes procedimentos:

• Defina um cabeçalho personalizado para indicar que a solicitação veio de um balanceador de carga Trusted Cloud usando um cabeçalho de solicitação personalizado. Por exemplo, é possível usar 16 ou mais bytes criptograficamente aleatórios como uma chave compartilhada.

  A implementação de transformações de cabeçalho personalizado depende do tipo de balanceador de carga em uso:

  • Balanceador de carga de aplicativo externo regional e balanceador de carga de aplicativo interno regional. As transformações de cabeçalhos personalizados só podem ser configuradas no mapa de URL.

    Para esses balanceadores de carga baseados no Envoy, Host e authority são palavras-chave especiais reservadas por Trusted Cloud. Não é possível modificar esses cabeçalhos nesses balanceadores de carga. Em vez disso, recomendamos que você crie outros cabeçalhos personalizados (por exemplo, MyHost) para que não interfira nos nomes de cabeçalho reservados.

• Ative o IAP e verifique se o JWT assinado no cabeçalho da solicitação foi assinado pelo Google e se a declaração (público-alvo) aud contém o número do projeto em que o balanceador de carga está definido.

Registros

As solicitações encaminhadas por proxy para um back-end externo são registradas no Cloud Logging da mesma forma que as solicitações de outros back-ends.

Para ver mais informações, consulte os seguintes tópicos:

• Geração de registros do balanceador de carga de aplicativo externo regional
• Geração de registros do balanceador de carga de aplicativo interno regional
• Geração de registros do balanceador de carga de rede proxy

Limitações

• Consulte a seção do serviço de back-end para ver as limitações associadas à configuração de NEGs da Internet como back-ends.
• Quando você modifica um balanceador de carga para alterar o back-end de um NEG da Internet para qualquer outro tipo de back-end ou vice-versa, o aplicativo passa por uma inatividade temporária de cerca de 30 a 90 segundos.

• Consulte a seção Gateway do Cloud NAT para ver as limitações associadas aos gateways NAT configurados nas sub-redes somente proxy.

Cotas e limites

Para informações sobre cotas e limites, consulte a tabela de cotas de back-ends de NEG e a tabela de cotas de endpoints por NEG.

Preços

O tráfego de saída para endpoints de NEG externos da Internet é cobrado de acordo com as taxas de saída da Internet para rede de nível Premium. A origem é baseada na localização do cliente, e o destino é baseado na localização do endpoint público.

Se você configurou um gateway do Cloud NAT para mapear a sub-rede somente proxy do balanceador de carga baseado no Envoy, haverá cobranças do Cloud NAT. Os gateways Cloud NAT alocados para balanceadores de carga geram cobranças por hora equivalentes a uma rede com mais de 32 instâncias de VM. Para detalhes, consulte Preços do Cloud NAT.

Para mais informações, consulte Preços do Cloud Load Balancing.

A seguir

• Configurar um balanceador de carga de aplicativo externo regional com um NEG da Internet
• Configurar um balanceador de carga de rede de proxy externo regional com um NEG da Internet