Vista geral dos grupos de pontos finais da rede da Internet

O Cloud Load Balancing suporta o encaminhamento de tráfego para back-ends externos fora Cloud de Confiance by S3NS. Para definir um back-end externo para um balanceador de carga, usa um recurso denominado grupo de pontos finais da rede (NEG) da Internet.

Pode usar este tipo de implementação quando quiser publicar conteúdo a partir de um back-end externo, mas quer que o equilibrador de carga seja o front-end. Cloud de Confiance Isto permite-lhe fazer o seguinte:

• Use a infraestrutura de rede perimetral da Google para terminar as ligações dos utilizadores.
• Direcionar as ligações para o seu back-end externo.
• Encaminhe tráfego para o seu ponto final público através da rede privada da Google, o que melhora a fiabilidade e pode diminuir a latência entre o cliente e o servidor.

As secções seguintes explicam como os back-ends externos são usados com o Cloud Load Balancing. Se quiser usar um back-end externo com o Cloud Service Mesh, consulte o artigo Cloud Service Mesh com grupos de pontos finais de rede da Internet.

Terminologia

Os seguintes termos são, por vezes, usados de forma intercambiável porque têm significados iguais ou semelhantes:

• Backend externo: um backend que reside fora do Cloud de Confiance by S3NS e é acessível através da Internet. O ponto final num NEG da Internet.
• Grupo de pontos finais da rede (NEG) da Internet: o recurso da API que usa para especificar um back-end externo. Cloud de Confiance by S3NS
• Ponto final externo: igual a um backend externo.

Este documento usa o termo backend externo, exceto quando se refere ao recurso da API NEG da Internet.

Componentes do balanceador de carga

Esta secção descreve 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 da interface é igual à de qualquer outro balanceador de carga.

As figuras seguintes mostram os Cloud de Confiance recursos necessários para configurar um balanceador de carga com um back-end externo.

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

Configuração da interface

Não é necessária nenhuma configuração especial do front-end para criar um balanceador de carga com um back-end de NEG da Internet. As regras de encaminhamento são usadas para encaminhar o tráfego por endereço IP, porta e protocolo para um proxy de destino. Em seguida, o proxy de destino termina as ligações dos clientes. Além disso, os balanceadores de carga baseados no Envoy requerem uma sub-rede apenas de proxy.

Os balanceadores de carga de aplicações também usam mapas de URLs para configurar o encaminhamento baseado em URLs de pedidos para os serviços de back-end adequados.

Para mais detalhes acerca de cada um destes componentes, consulte as secções de arquitetura do equilibrador de carga respetivo:

• Vista geral do balanceador de carga de aplicações externo
• Vista geral do balanceador de carga de aplicações interno
• Vista geral do External proxy Network Load Balancer
• Vista geral do balanceador de carga de rede do proxy interno

Grupos de pontos finais de rede (NEG) da Internet

Um NEG de Internet é um recurso usado para definir um back-end externo para o balanceador de carga. Existem dois tipos de NEGs da Internet: NEG da Internet global e NEG da Internet regional. Diferem no âmbito (global versus regional) e no comportamento. O motor de processamento de dados externo referenciado por um NEG de Internet global tem de ser acessível exclusivamente através da Internet. Não pode ser acessível através do Cloud VPN ou do Cloud Interconnect. Se o back-end externo fizer referência a uma API ou um serviço Google, o serviço tem de estar acessível através da porta TCP 80 ou 443 com o protocolo HTTP, HTTPS ou HTTP/2.

Existem duas formas de configurar o ponto final externo referenciado pelo NEG: INTERNET_FQDN_PORT ou INTERNET_IP_PORT. Se escolher o formato INTERNET_IP_PORT, só pode usar um endereço IP encaminhável da Internet pública. Se escolher o formato INTERNET_FQDN_PORT, o FQDN pode ser resolvido para um endereço IP encaminhável da Internet pública ou para um endereço IP privado, consoante o âmbito do ponto final: regional ou global.

Os NEGs de Internet regionais são baseados em proxies Envoy geridos. Cada NEG pode ter vários pontos finais e um serviço de back-end pode incluir vários NEGs de Internet.

Para o tráfego de saída, pode configurar gateways NAT da nuvem para definir os endereços IP de origem. Em alternativa, pode encaminhar o tráfego através de rotas aprendidas na sua rede VPC. Embora o Cloud NAT não seja necessário para este método de encaminhamento, é suportado.

A tabela seguinte descreve como os diferentes equilibradores de carga suportam os NEGs de Internet regionais.

Balanceadores de carga	Tipo de ponto final	Definição do ponto final	Âmbito	Verificações de funcionamento
Balanceador de carga de aplicações externo regional Balanceador de carga de aplicações 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 do domínio totalmente qualificado resolvível publicamente ou em privado e uma porta opcional. Por exemplo, backend.example.com:443*. O nome do domínio tem de ser resolvível pelo Cloud DNS. É permitido um máximo de 256 pontos finais por NEG.	Regional	Verificações de funcionamento distribuídas do Envoy
	INTERNET_IP_PORT	Apenas um endereço IP encaminhável publicamente e uma porta opcional. Por exemplo, 8.8.8.8:4432. O endereço IP não pode ser um endereço RFC 1918. É permitido um máximo de 256 pontos finais por NEG.

Resolução de DNS para pontos finais INTERNET_FQDN_PORT regionais

Se o seu domínio for resolvível através da Internet, não é necessária nenhuma outra configuração para configurar o DNS. No entanto, se estiver a resolver FQDNs privados, tem de configurar o Cloud DNS para facilitar a resolução de DNS. O nome tem de estar alojado no Cloud DNS ou ser resolvível através do encaminhamento de DNS do Cloud DNS para um DNS no local ou um peering de DNS se fizer referência a uma zona de DNS privado noutra rede de VPC.

Comece por criar uma zona do Cloud DNS para alojar os registos de DNS no seu projeto. Em seguida, adicione os registos de DNS. Para ver passos de configuração específicos, consulte a documentação do Cloud DNS. A ordem de resolução do Cloud DNS é detalhada em Ordem de resolução de nomes.

Se estiver a usar a VPC partilhada, tenha em atenção os requisitos específicos da rede. Também pode usar outras funcionalidades do Cloud DNS, como zonas de encaminhamento, para obter registos de um servidor DNS no local.

Resolução de endereços IP para pontos finais INTERNET_FQDN_PORT regionais

Os NEGs de Internet regionais suportam a resolução de nomes de domínio através do Cloud DNS.

Se o servidor DNS devolver vários endereços IP, o Envoy equilibra a carga do tráfego entre os endereços IP devolvidos com base no algoritmo de equilíbrio de carga configurado (round robin, pedido mínimo, etc.). A lista de pontos finais é atualizada periodicamente com base no TTL de DNS. Pode configurar políticas de repetição para forçar o Envoy a tentar estabelecer ligação a outro endereço IP se um 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 num serviço de back-end para direcionar o tráfego recebido 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 do NEG da Internet. Quando adiciona um NEG de Internet a um serviço de back-end, aplicam-se as seguintes considerações, consoante o âmbito 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. Pode adicionar até 50 NEGs de Internet ao mesmo serviço de back-end.

• Número de pontos finais por NEG

  • NEGs regionais. Pode adicionar até 256 pontos finais por NEG ao mesmo serviço de back-end.

  Os NEGs regionais não suportam modos de balanceamento de carga, como taxa, ligação ou utilização. Todos os pontos finais de todos os NEGs anexados a um serviço de back-end são agrupados num único grupo. O balanceamento de carga do tráfego entre este conjunto de pontos finais é processado através de algoritmos de balanceamento de carga do Envoy. Para ver os algoritmos da política de balanceamento de carga suportados, consulte localityLbPolicy na documentação da API do serviço de back-end regional.

• Verificações de saúde

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

• O esquema de balanceamento de carga do serviço de back-end tem de corresponder ao esquema exigido pelo balanceador de carga que está a implementar. Para ver a lista completa, consulte Serviços de back-end.

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

  Recomendamos vivamente que use 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 encriptada e autenticada quando transitar pela Internet pública.

  Além disso, quando usar HTTPS ou HTTP/2 como protocolo de back-end, certifique-se de que usa um ponto final INTERNET_FQDN_PORT para criar o back-end externo. Isto tem duas vantagens:

  • Garante que o equilibrador de carga valida o certificado do servidor SSL apresentado pelo back-end externo e verifica se as seguintes informações são verdadeiras:

    • O certificado é assinado por autoridades de certificação (ACs) conhecidas.
    • O certificado não expirou.
    • A assinatura do certificado é válida.
    • O FQDN configurado corresponde a um dos nomes alternativos de requerente (SANs) no certificado.

    Se criar o back-end externo através de um ponto final INTERNET_IP_PORT, não é feita a validação do certificado do servidor SSL.

  • A extensão Indicação do nome do servidor (SNI) SSL só é suportada com pontos finais INTERNET_FQDN_PORT. O NQD configurado é enviado um SNI no client hello durante o handshake SSL entre o equilibrador de carga e o ponto final externo. O SNI não é enviado quando usa um ponto final INTERNET_IP_PORT porque os literais de endereço IP não são permitidos no campo HostName de uma carga útil SNI.

Verificações de funcionamento

A configuração da verificação de funcionamento varia consoante o tipo de balanceador de carga:

• Balanceador de carga de aplicações externo regional, balanceador de carga de aplicações 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 estado são opcionais. As sondas de verificação de funcionamento destes balanceadores de carga têm origem na sub-rede apenas de proxy e são, em seguida, traduzidas por NAT (através do Cloud NAT) para endereços IP pré-reservados ou endereços IP NAT auto-atribuídos. Para ver detalhes, consulte o artigo NEGs regionais: use um gateway NAT da nuvem.

  As verificações de funcionamento do Envoy distribuídas são criadas através dos mesmos Cloud de Confiance processos da consola, da CLI gcloud e da API que as verificações de funcionamento centralizadas. Não é necessária nenhuma outra configuração.

  Aspetos a ter em conta:

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

  • Uma vez que o plano de dados do Envoy processa as verificações de estado, não pode usar a Cloud de Confiance consola, a API nem a CLI gcloud para verificar o estado de funcionamento destes pontos finais externos. Para NEGs híbridos com balanceadores de carga baseados no Envoy, a Cloud de Confiance consola mostra o estado da verificação de funcionamento comoN/A. Isto é normal.

  • Cada proxy Envoy atribuído à sub-rede apenas de proxy na região na rede VPC inicia verificações de estado de funcionamento de forma independente. Por conseguinte, pode verificar um aumento no tráfego de rede devido à verificação do estado. O aumento depende do número de proxies Envoy atribuídos à sua rede VPC numa região, da quantidade de tráfego recebido por estes proxies e do número de pontos finais que cada proxy Envoy tem de verificar o estado. No pior cenário, o tráfego de rede devido às verificações de estado aumenta a uma taxa (O(n^2)) quadrática.

  • Os registos de verificações de funcionamento para verificações de funcionamento do Envoy distribuídas não incluem estados de funcionamento detalhados. Para ver detalhes sobre o que é registado, consulte o artigo Registo de verificação de estado. Para resolver problemas de conetividade dos proxies Envoy para os seus pontos finais do NEG, também deve verificar os registos do equilibrador de carga respetivo.

    • Registo do balanceador de carga de aplicações externo regional
    • Registo do balanceador de carga de aplicações interno
    • Registo do balanceador de carga da rede de proxy

Ative o back-end externo para receber pedidos

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

NEGs regionais: use um gateway do Cloud NAT

Se estiver a usar um NEG da Internet regional, primeiro configure um gateway Cloud NAT para atribuir um conjunto de intervalos de endereços IP a partir dos quais o tráfego Cloud de Confiance deve ter origem.

O ponto final do gateway deve ser do tipo ENDPOINT_TYPE_MANAGED_PROXY_LB.

A gateway Cloud NAT pode ser configurada para atribuir automaticamente endereços IP externos com base na procura ou usar um conjunto de endereços IP externos pré-reservados manualmente.

• Endereços IP atribuídos automaticamente

  Use endereços IP atribuídos automaticamente se o seu ambiente de back-end externo não exigir que adicione endereços IP específicos que possam enviar tráfego para o back-end externo a uma lista de autorizações. Cloud de Confiance

• Endereços IP atribuídos manualmente

  Use endereços IP atribuídos manualmente apenas se o seu ambiente de back-end externo exigir que adicione Cloud de Confiance endereços IP específicos a uma lista de autorizações. Uma vez que cada Envoy atribuído à sua sub-rede de proxy consome um endereço IP completo, certifique-se de que o conjunto de endereços IP reservados é suficientemente grande para acomodar todos os Envoys.

  Se tiver problemas de conetividade em grande escala, verifique se atingiu os limites do Cloud NAT. Por predefinição, tem um limite de 50 endereços IP NAT atribuídos manualmente por gateway.

A atribuição dinâmica de portas é suportada para NEGs de Internet regionais. Os endereços IP podem ser partilhados por proxies, sendo assim totalmente utilizados.

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

A utilização do Cloud NAT incorre em custos para o tráfego de utilizadores e o tráfego de verificação de funcionamento. Para ver detalhes sobre como funcionam os preços de NEG da Internet regionais, consulte o artigo Preços de NEG da Internet regionais.

Os gateways NAT configurados em sub-redes apenas de proxy não suportam o registo nem a monitorização. Ou seja, as flags --enable-logging e --log-filter não são suportadas.

Autentique pedidos para o back-end externo

Esta secção aplica-se apenas a equilibradores de carga de aplicações.

Para autenticar pedidos enviados para o seu back-end externo, pode fazer uma das seguintes ações:

• Defina um cabeçalho personalizado para indicar que o pedido foi feito a partir de um Cloud de Confiance equilibrador de carga através de um cabeçalho de pedido personalizado. Por exemplo, pode usar 16 ou mais bytes criptograficamente aleatórios como uma chave partilhada.

  A implementação de transformações de cabeçalhos personalizados depende do tipo de equilibrador de carga que está a usar:

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

    Para estes equilibradores de carga baseados no Envoy, Host e authority são palavras-chave especiais reservadas pela Cloud de Confiance. Não pode modificar estes cabeçalhos para estes equilibradores de carga. Em alternativa, recomendamos que crie outros cabeçalhos personalizados (por exemplo, MyHost) para não interferir com os nomes de cabeçalhos reservados.

• Ative a IAP e confirme se o JWT assinado no cabeçalho do pedido está assinado pela Google e se a reivindicação aud (público-alvo) contém o número do projeto onde o seu equilibrador de carga está definido.

Registos

Os pedidos enviados por proxy para um back-end externo são registados no Cloud Logging da mesma forma que os pedidos para outros back-ends.

Para mais informações, consulte o seguinte:

• Registo do balanceador de carga de aplicações externo regional
• Registo do balanceador de carga da aplicação interno regional
• Registo do balanceador de carga da rede de proxy

Limitações

• Reveja a secção de serviço de back-end para ver as limitações associadas à configuração de NEGs da Internet como back-ends.
• Quando modifica um balanceador de carga para alterar o back-end de um NEG da Internet para qualquer outro tipo de back-end, ou altera o back-end de qualquer outro tipo de back-end para um NEG da Internet, a sua aplicação sofre uma indisponibilidade temporária de cerca de 30 a 90 segundos.

• Reveja a secção gateway do Cloud NAT para ver as limitações associadas a gateways de NAT configuradas em sub-redes apenas de proxy.

Quotas e limites

Para ver informações sobre quotas e limites, consulte a tabela de quotas de back-ends do NEG e a tabela de quotas de pontos finais por NEG.

Preços

O tráfego de saída para pontos finais NEG da Internet externa é cobrado às taxas de saída da Internet para a rede de nível Premium. A origem baseia-se na localização do cliente e o destino baseia-se na localização do seu ponto final público.

Se configurou um gateway Cloud NAT para mapear a sub-rede só de proxy do balanceador de carga baseado no Envoy regional, incorre em custos do Cloud NAT. As gateways do Cloud NAT atribuídas a balanceadores de carga incorrem em encargos por hora equivalentes a uma rede com mais de 32 instâncias de VM. Para ver detalhes, consulte os preços da NAT na nuvem.

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

O que se segue?

• Configure um Application Load Balancer externo regional com um NEG da Internet
• Configure um balanceador de carga de rede de proxy externo regional com um NEG da Internet