O Cloud Load Balancing é compatível com o proxy de tráfego para back-ends externos fora do Google Cloud. 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 do Google 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.
- Com balanceadores de carga globais, é possível usar o Cloud CDN para armazenar conteúdo em cache do seu back-end externo.
A Figura 1 mostra um balanceador de carga de aplicativo externo com vários tipos de back-end, em que um deles é um back-end externo configurado com um NEG da Internet.
Os back-ends de NEG da Internet são compatíveis com vários balanceadores de carga regionais e globais. Dependendo do seu balanceador de carga (global ou regional), a compatibilidade com NEG da Internet varia em relação a DNS, verificação de integridade, número de endpoints disponíveis e comportamentos de roteamento de tráfego.
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 Google Cloud e pode ser acessado pela Internet. O endpoint em um NEG da Internet.
- Origem personalizada: igual a um back-end externo. Na CDN, origem é o termo padrão do setor para uma instância de back-end que exibe conteúdo da Web.
- Grupo de endpoints da rede na Internet (NEG): o recurso da API Google Cloud 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 Google Cloud necessários para configurar um balanceador de carga com um back-end externo.
Global externo
Esta figura mostra os recursos do Google Cloud necessários para configurar um balanceador de carga de aplicativo externo global com um back-end externo.
Regional externo
Esta figura mostra os recursos do Google Cloud necessários para configurar um balanceador de carga de aplicativo externo regional com um back-end externo.
Regional interno
Esta figura mostra os recursos do Google Cloud necessários para configurar um balanceador de carga de aplicativo interno regional com um back-end externo.
Esta figura mostra os recursos do Google Cloud necessários para configurar um balanceador de carga de rede de proxy interno regional 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: global e regional. Eles diferem no escopo (global ou regional) e no
comportamento. O back-end externo referenciado por um NEG global da Internet precisa ser
acessível exclusivamente pela Internet. Ele não pode ser acessível pelo
Cloud VPN ou 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, apenas um endereço IP público roteável pela Internet poderá ser usado. Se o
formato INTERNET_FQDN_PORT for escolhido, o FQDN poderá ser resolvido em um
endereço IP público roteável pela Internet ou em um endereço IP particular, dependendo do
escopo do endpoint: regional ou global.
Os NEGs globais da Internet são alimentados por tecnologias do Google Front End (GFE). Eles usam um conjunto fixo de endereços IP fixos para tráfego de saída para todos os clientes. Eles oferecem suporte a apenas um endpoint por NEG e um NEG da Internet por serviço de back-end.
A tabela a seguir descreve como diferentes balanceadores de carga oferecem suporte a NEGs globais da Internet.
| Balanceadores de carga | Tipo de endpoint | Definição do endpoint | Escopo | Verificações de integridade |
|---|---|---|---|---|
|
|
Um nome de domínio totalmente qualificado que pode ser resolvido publicamente e uma porta opcional. Por exemplo,
O nome de domínio precisa ser resolvido pela infraestrutura pública de DNS do Google. Só é permitido um endpoint por NEG. |
Global | Sem suporte |
|
Um endereço IP roteável publicamente e uma porta opcional. Por exemplo, O endereço IP não pode ser RFC 1918. Só é permitido um endpoint por NEG. |
† Se você não especificar uma porta ao adicionar o endpoint, a
porta padrão do NEG será usada. Se você não especificou uma porta padrão para o NEG, será usada a porta conhecida do protocolo de back-end (80 para HTTP e 443 para HTTPS e HTTP/2).
Os NEGs regionais da Internet são fornecidos por proxies Envoy gerenciados e gateways do Cloud NAT. Eles oferecem suporte a vários endpoints por NEG e vários NEGs da Internet por serviço de back-end. Os endereços IP usados para o tráfego de saída para clientes podem ser configurados usando gateways do Cloud NAT.
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 |
|---|---|---|---|---|
|
|
Um nome de domínio totalmente qualificado que pode ser resolvido publicamente ou
de forma privada e uma porta opcional. Por exemplo,
O processo de resolução de nomes de domínio segue a ordem de resolução de nomes do Cloud DNS. São permitidos no máximo 256 endpoints por NEG. |
Regional | Verificações de integridade distribuídas do Envoy |
|
Apenas um endereço IP roteável publicamente e uma porta opcional. Por exemplo, O endereço IP não pode ser RFC 1918. São permitidos no máximo 256 endpoints por NEG. |
* Com NEGs da Internet regionais, é necessário especificar uma porta. É possível especificar uma porta padrão ao criar o NEG, especificar uma porta sempre que adicionar um endpoint ao NEG ou realizar as duas ações. Se você não especificar uma porta ao adicionar um endpoint, a porta padrão do NEG será usada.
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 usando o encaminhamento de DNS do Cloud DNS para um DNS local ou peering de DNS se estiver referenciando uma zona de DNS particular 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 está 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 globais INTERNET_FQDN_PORT
Quando um endpoint INTERNET_FQDN_PORT aponta para um registro DNS que retorna
vários endereços IP, o endereço IP é resolvido da seguinte forma:
O balanceador de carga usa um resolvedor de DNS em uma região do Google Cloud mais próxima do cliente na Internet. Se o registro DNS do endpoint
INTERNET_FQDN_PORTretornar endereços IP diferentes com base na localização do cliente, verifique se cada um deles pode ser acessado pelo balanceador de carga.O balanceador de carga tenta se conectar ao primeiro endereço IP na resposta DNS. Se esse endereço IP não estiver acessível, o balanceador de carga retornará uma resposta HTTP
502 (Bad Gateway). Isso ocorre mesmo que outros endereços IP da resposta DNS estejam disponíveis.
Para mais informações sobre os locais e intervalos de IP usados pela infraestrutura do resolvedor de DNS do Google, consulte a documentação do DNS público do Google. Nomes que não podem ser resolvidos pelo sistema DNS público não são utilizáveis como back-ends externos.
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 e o DNS público do Google.
- Para a resolução de DNS público, o Cloud DNS encaminha o tráfego para os servidores DNS públicos do Google.
- Para o Cloud DNS, o nome de domínio precisa ser um dos seguintes:
- Hospedado no Cloud DNS
- Ser resolvido usando o encaminhamento de DNS do Cloud DNS para um servidor DNS local
- Ser resolvido usando o peering de DNS se você estiver fazendo referência a uma zona de DNS particular em outra rede VPC.
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 globais. Só é possível adicionar um back-end de NEG da Internet a um 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 globais. Apenas um endpoint pode ser adicionado a um NEG da Internet.
Como é permitido apenas um endpoint em cada NEG global da Internet, o balanceamento de carga não é realmente realizado. O balanceador de carga serve apenas como front-end e faz o proxy do tráfego para o back-end externo especificado. Isso significa que não é possível usar nenhum dos modos de balanceamento de carga, como taxa, conexão ou utilização.
- 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
localityLbPolicyna documentação da API do serviço de back-end regional.Verificações de integridade
- NEGs globais. O serviço de back-end não pode se referir a uma verificação 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,HTTPSouHTTP2.É 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_PORTpara 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 endpointINTERNET_IP_PORTporque os literais de endereço IP não são permitidos no campoHostNamede 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 global e balanceador de carga de aplicativo clássico. Um serviço de back-end com um NEG global da Internet não é compatível com verificações de integridade.
Se o back-end externo ficar inacessível ou o nome do host configurado (FQDN, na sigla em inglês) não puder ser resolvido, o balanceador de carga retornará uma resposta HTTP
502 (Bad Gateway)aos clientes.
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 do console do Google Cloud, 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 do Google 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 do Google Cloud mostra o status da verificação de integridade como
N/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.
Ativar o back-end externo para receber solicitações
Configure o back-end externo para permitir o tráfego do Google Cloud.
Esse procedimento depende do escopo do NEG: global ou regional.
NEGs globais: lista de permissões de endereços IP de saída padrão do Google
Se estiver usando um NEG global de Internet,
precisa adicionar os intervalos de endereços IP que o Google usa para enviar solicitações
para uma lista de permissões. Para procurar os endereços IP a serem adicionados a um
lista de permissões, consulte o registro TXT do DNS _cloud-eoips.googleusercontent.com
usando ferramentas como dig ou nslookup.
Por exemplo, consulte Permitir que o back-end externo receba tráfego do Google 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 do Google 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 back-end externo não exige que você adicione recursos específicos do Google Cloud Endereços IP que podem enviar tráfego para o back-end externo para 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 Google 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.
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-logginge--log-filternão são compatíveis. - Recursos relacionados a portas, como alocação de portas estáticas e dinâmicas, configuração de portas máximas e mínimas por VM e mapeamento independente de endpoint, não são compatíveis. Cada proxy recebe todas as 65.536 portas.
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 de aplicativo do Google 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 global e balanceador de carga de aplicativo clássico. As transformações de cabeçalho personalizadas podem ser configuradas no serviço de back-end ou no mapa de URL.
Por exemplo, é possível configurar o back-end externo para que espere um valor específico para o cabeçalho
Hostda solicitação HTTP e configurar o balanceador de carga para que defina o cabeçalhoHostcom esse valor esperado. Se você não configurar um cabeçalho de solicitação personalizado, o balanceador de carga preservará os cabeçalhos usados pelo cliente para se conectar ao balanceador de carga e incluirá o mesmo cabeçalho na resposta. No entanto, lembre-se que modificar o cabeçalhoHostnão é possível no mapa de URL.Há outras limitações associadas à configuração do cabeçalho
Host. Para detalhes, consulte Criar cabeçalhos personalizados em serviços de back-end. Para um exemplo específico, consulte Configurar um balanceador de carga de aplicativo externo global com um back-end externo.
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,
Hosteauthoritysão palavras-chave especiais reservadas pelo Google 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)
audcontém o número do projeto em que o balanceador de carga está definido.Observe o seguinte:
- O IAP não é compatível com o Cloud CDN.
- O IAP não é compatível com balanceadores de carga de rede de proxy (internos e externos).
- Ative a autenticação de origem particular, que fornece a um balanceador de carga de aplicativo externo acesso de longo prazo a um bucket particular do Amazon Simple Storage Service (Amazon S3) ou a outros armazenamentos de objetos compatíveis. O Cloud CDN (e, portanto, a autenticação de origem particular) não é compatível com balanceadores de carga de aplicativo externos regionais e balanceadores de carga de aplicativo internos regionais.
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
Processamento de cabeçalho com back-ends externos
Diferentes balanceadores de carga podem lidar com o processamento de cabeçalho de maneiras diferentes quando fazem proxy das solicitações para um back-end externo. Revise as seguintes informações para entender como seu tipo de balanceador de carga pode processar cabeçalhos HTTP.
Balanceadores de carga de aplicativo externos globais e Balanceadores de carga de aplicativo clássicos
Quando um balanceador de carga de aplicativo externo global ou um balanceador de carga de aplicativo clássico encaminha solicitações para um back-end externo, ele ajusta os cabeçalhos HTTP das seguintes maneiras:
Alguns cabeçalhos são agrupados. Quando houver várias instâncias da mesma chave de cabeçalho (por exemplo,
Via), o balanceador de carga combinará os valores delas em uma lista separada por vírgulas para uma chave de cabeçalho. Serão agrupados somente cabeçalhos com valores que possam ser representados como uma lista separada por vírgulas. Outros cabeçalhos, comoSet-Cookie, nunca são agrupados.Os cabeçalhos têm a primeira letra de cada palavra exibida em maiúscula quando o protocolo do serviço de back-end é
HTTPouHTTPS:A primeira letra da chave do cabeçalho e todas as letras após um hífen (
-) são exibidas em maiúsculas para preservar a compatibilidade com clientes HTTP/1.1. Por exemplo,user-agenté alterado paraUser-Agentecontent-encodingé alterado paraContent-Encoding.Alguns cabeçalhos, como
Accept-CH(dicas de cliente), são convertidos para corresponder à representação padrão de letras mistas.
Alguns cabeçalhos são adicionados ou têm valores anexados a eles. Os balanceadores de carga de aplicativo externos sempre adicionam ou modificam determinados cabeçalhos, como
ViaeX-Forwarded-For.
Balanceadores de carga de aplicativo externos regionais e balanceadores de carga de aplicativo internos regionais
Não há processamento de cabeçalhos especiais para balanceadores de carga baseados no Envoy usando NEGs da Internet. Para saber como o Envoy normalmente processa cabeçalhos, consulte Manipulação de cabeçalho HTTP.
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.
Por exemplo, durante esse tempo de inatividade, os clientes que enviam solicitações a balanceadores de carga de aplicativo externos globais encontram erros
502com o código de errofailed_to_connect_to_backend. Esse é o comportamento esperado.
- Os seguintes recursos avançados de gerenciamento de tráfego não são compatíveis com back-ends de NEG globais da Internet:
- Solicitar espelhamento
- Políticas de repetição
- Políticas de tráfego (incluindo política de localidade de balanceamento de carga, afinidade de sessão e detecção de outlier)
- 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 mais informações sobre cotas e limites, consulte a tabela de cota de back-ends de NEG e a tabela de cota 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 global com um NEG da Internet
- Configure um balanceador de carga de aplicativo clássico com um NEG da Internet
- Configurar o Cloud CDN para um balanceador de carga de aplicativo externo com um back-end externo
- Visão geral do Cloud Service Mesh com grupos de endpoints de rede da Internet
- 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