O Cloud Load Balancing suporta o encaminhamento de tráfego para back-ends externos fora Google Cloud. Para definir um back-end externo para um balanceador de carga, use 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. Google Cloud 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.
- Com os balanceadores de carga globais, pode usar o Cloud CDN para colocar conteúdo em cache para o seu back-end externo.
A Figura 1 mostra um Application Load Balancer externo com vários tipos de back-end, um dos quais é um back-end externo configurado com um NEG da Internet.
Os back-ends NEG da Internet são suportados com vários equilibradores de carga globais e regionais. Consoante o equilibrador de carga (global ou regional), o suporte de NEG da Internet difere no que diz respeito ao DNS, à verificação do estado, ao número disponível de pontos finais e aos comportamentos de encaminhamento de tráfego.
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 a 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 Google Cloud e é acessível através da Internet. O ponto final num NEG da Internet.
- origem personalizada: igual a um backend externo. Na RFC, a origem é o termo padrão da indústria para uma instância de back-end que publica conteúdo Web.
- Grupo de pontos finais da rede (NEG) da Internet: o recurso da API que usa para especificar um back-end externo. Google Cloud
- 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 Google Cloud recursos necessários para configurar um balanceador de carga com um back-end externo.
Global externo
Esta figura mostra os Google Cloud recursos necessários para configurar um balanceador de carga de aplicações externo global com um back-end externo.
Regional externo
Esta figura mostra os Google Cloud recursos necessários para configurar um Application Load Balancer externo regional com um back-end externo.
Regional interno
Esta figura mostra os Google Cloud recursos necessários para configurar um Application Load Balancer interno regional com um back-end externo.
Esta figura mostra os Google Cloud recursos necessários para configurar um balanceador de carga de rede de proxy interno regional 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 target_proxy 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 URL 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 back-end 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 da Cloud VPN nem 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.
As NEGs da Internet global são baseadas em tecnologias da interface de utilizador da Google (GFE). Usam um conjunto fixo de endereços IP fixos para o tráfego de saída para todos os clientes. Suportam apenas um ponto final por NEG e um NEG de Internet por serviço de back-end.
A tabela seguinte descreve como os diferentes equilibradores de carga suportam os NEGs da Internet globais.
| Balanceadores de carga | Tipo de ponto final | Definição de ponto final | Âmbito | Verificações de funcionamento |
|---|---|---|---|---|
|
|
Um nome do domínio totalmente qualificado resolvível publicamente e uma porta opcional. Por exemplo,
O nome de domínio tem de ser resolvível pela infraestrutura de DNS público da Google. Só é permitido um ponto final por NEG. |
Global | Não suportado |
|
Um endereço IP encaminhável publicamente e uma porta opcional. Por exemplo,
O endereço IP não pode ser um endereço RFC 1918. Só é permitido um ponto final por NEG. |
† Se não especificar uma porta ao adicionar o ponto final, é usada a porta predefinida do NEG. Se não especificou uma porta predefinida para o NEG, é usada a porta conhecida para o protocolo de back-end (80 para HTTP e 443 para HTTPS e HTTP/2).
Os NEGs da 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 de ponto final | Âmbito | Verificações de funcionamento |
|---|---|---|---|---|
|
|
Um nome do domínio totalmente qualificado resolvível publicamente ou em privado e uma porta opcional. Por exemplo,
O processo de resolução de nomes de domínio segue o processo de resolução de nomes do Cloud DNS. É permitido um máximo de 256 pontos finais por NEG. |
Regional | Verificações de estado de funcionamento distribuídas do Envoy |
|
Apenas um endereço IP encaminhável publicamente e uma porta opcional. Por exemplo,
O endereço IP não pode ser um endereço RFC 1918. É permitido um máximo de 256 pontos finais por NEG. |
* Com os NEGs de Internet regionais, tem de especificar uma porta. Pode especificar uma porta predefinida ao criar o NEG ou especificar uma porta sempre que adicionar um ponto final ao NEG, ou pode fazer ambas as opções. Se não especificar uma porta ao adicionar um ponto final, é usada a porta predefinida do 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 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 globais
Quando um ponto final INTERNET_FQDN_PORT aponta para um registo DNS que devolve vários endereços IP, o endereço IP é resolvido da seguinte forma:
O balanceador de carga usa um resolvedor de DNS numa Google Cloud região mais próxima do respetivo cliente na Internet. Se o registo DNS do seu ponto final
INTERNET_FQDN_PORTdevolver endereços IP diferentes com base na localização do cliente, certifique-se de que o equilibrador de carga consegue alcançar cada um desses endereços IP.O balanceador de carga tenta estabelecer ligação ao primeiro endereço IP na resposta de DNS. Se esse endereço IP não estiver acessível, o balanceador de carga devolve uma resposta HTTP
502 (Bad Gateway). Isto aplica-se mesmo que outros endereços IP da resposta DNS estejam disponíveis.
Para mais informações acerca dos intervalos de IP e das localizações usados pela infraestrutura de resolução de DNS da Google, consulte a documentação do DNS público da Google. Os 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 pontos finais INTERNET_FQDN_PORT regionais
Os NEGs da Internet regionais suportam a resolução de nomes de domínio através do Cloud DNS e do DNS público da Google.
- Para a resolução de DNS público, o Cloud DNS encaminha o tráfego para os servidores DNS públicos da Google.
- Para o Cloud DNS, o nome de domínio tem de ser um dos seguintes:
- Alojado no Cloud DNS
- Ser resolvível através do encaminhamento de DNS do Cloud DNS para um servidor DNS no local
- Ser resolvível através da interligação de DNS se estiver a referenciar uma zona de DNS privada noutra rede VPC.
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 globais. Só pode adicionar um back-end NEG da Internet a um 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 globais. Só pode adicionar um ponto final a um NEG da Internet.
Uma vez que apenas é permitido um ponto final em cada NEG da Internet global, o equilíbrio de carga não é realmente realizado. O balanceador de carga funciona apenas como front-end e encaminha o tráfego para o back-end externo especificado. Isto significa que não pode usar nenhum dos modos de equilíbrio de carga, como taxa, ligação ou utilização.
- 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
localityLbPolicyna documentação da API do serviço de back-end regional.Verificações de saúde
- NEGs globais. O serviço de back-end não pode fazer referência a uma verificação de estado.
- 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 um dos seguintes:
HTTP,HTTPSouHTTP2.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_PORTpara 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, a validação do certificado do servidor SSL não é realizada.A extensão Indicação do nome do servidor (SNI) SSL só é suportada com pontos finais
INTERNET_FQDN_PORT. O FQDN configurado é enviado um SNI no client hello durante o handshake SSL entre o balanceador de carga e o ponto final externo. O SNI não é enviado quando usa um ponto finalINTERNET_IP_PORT, porque os literais de endereço IP não são permitidos no campoHostNamede 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 global e balanceador de carga de aplicações clássico. Um serviço de back-end com um NEG de Internet global não suporta verificações de estado.
Se o seu back-end externo ficar inacessível ou se não for possível resolver o nome do anfitrião configurado (FQDN), o balanceador de carga devolve uma resposta HTTP
502 (Bad Gateway)aos respetivos clientes.
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 saúde são opcionais. As sondas de verificação de funcionamento destes balanceadores de carga têm origem na sub-rede só de proxy e são posteriormente 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 Google Cloud 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 gRPC não são suportadas.
- As verificações de estado 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 Google Cloud 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 consola mostra o estado da verificação de funcionamento como
N/A. Google Cloud 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 dos cenários, 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.
Ative o back-end externo para receber pedidos
Configure o back-end externo para permitir tráfego de Google Cloud.
Este procedimento depende do âmbito do NEG: global ou regional.
NEGs globais: permita os endereços IP de saída da Google predefinidos
Se estiver a usar um NEG da Internet global, tem de adicionar os intervalos de endereços IP que a Google usa para enviar pedidos a back-ends externos a uma lista de autorizações. Para procurar os endereços IP a adicionar a uma lista de autorizações, consulte o registo TXT de DNS através de uma ferramenta como dig ou nslookup._cloud-eoips.googleusercontent.com
Por exemplo, consulte Permita que o back-end externo receba tráfego de Google Cloud.
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 Google Cloud tráfego 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. Google Cloud
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 Google Cloud 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 inteiro, 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 o funcionamento dos preços NEG da Internet regionais, consulte o artigo Preços NEG da Internet regionais.
Existem algumas limitações para gateways NAT configurados em sub-redes apenas de proxy:
- Só é realizada a tradução NAT um-para-um. A partilha de endereços IP não é suportada.
- O registo e a monitorização não são suportados. Ou seja, os flags
--enable-logginge--log-filternão são suportados.
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 Google Cloud 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 global e balanceador de carga de aplicações clássico. As transformações de cabeçalhos personalizados podem ser configuradas no serviço de back-end ou no mapa de URLs.
Por exemplo, pode configurar o back-end externo para esperar um valor específico para o cabeçalho
Hostdo pedido HTTP e pode configurar o equilibrador de carga para definir o cabeçalhoHostpara esse valor esperado. Se não configurar um cabeçalho de pedido personalizado, o equilibrador de carga preserva os cabeçalhos que o cliente usou para estabelecer ligação ao equilibrador de carga e inclui o mesmo cabeçalho na respetiva resposta. No entanto, tenha em atenção que a modificação do cabeçalhoHostnão é suportada no mapa de URLs.Existem limitações adicionais associadas à configuração do cabeçalho
Host. Para ver detalhes, consulte o artigo Crie cabeçalhos personalizados em serviços de back-end. Para ver um exemplo específico, consulte o artigo Configure um Application Load Balancer externo global com um back-end externo.
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,
Hosteauthoritysão palavras-chave especiais reservadas pela Google Cloud. 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.Tenha em conta o seguinte:
- O IAP não é compatível com o Cloud CDN.
- O IAP não é suportado com equilibradores de carga de rede de proxy (internos e externos).
- Ative a autenticação de origem privada, que dá a um Application Load Balancer externo acesso a longo prazo a um contentor privado do Amazon Simple Storage Service (Amazon S3) ou a outras lojas de objetos compatíveis. O Cloud CDN (e, por conseguinte, a autenticação de origem privada) não é compatível com balanceadores de carga de aplicações externos regionais e balanceadores de carga de aplicações internos regionais.
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
Processamento de cabeçalhos com back-ends externos
Os diferentes equilibradores de carga podem processar os cabeçalhos de formas diferentes quando encaminham pedidos para um back-end externo. Reveja as informações seguintes para compreender como o tipo de equilibrador de carga pode processar cabeçalhos HTTP.
Balanceadores de carga de aplicações externos globais e balanceadores de carga de aplicações clássicos
Quando um balanceador de carga de aplicações externo global ou um balanceador de carga de aplicações clássico encaminha pedidos para um back-end externo, ajusta os cabeçalhos HTTP das seguintes formas:
Alguns cabeçalhos são unidos. Quando existem várias instâncias da mesma chave de cabeçalho (por exemplo,
Via), o balanceador de carga combina os respetivos valores numa única lista separada por vírgulas para uma única chave de cabeçalho. Apenas os cabeçalhos cujos valores podem ser representados como uma lista separada por vírgulas são unidos. Outros cabeçalhos, comoSet-Cookie, nunca são unidos.Os cabeçalhos são escritos com a primeira letra 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 apresentadas em maiúsculas para preservar a compatibilidade com clientes HTTP/1.1. Por exemplo,user-agenté alterado paraUser-Agentecontent-encodingé alterado paraContent-Encoding.Determinados cabeçalhos, como
Accept-CH(client hints), são convertidos para corresponder à representação padrão de letras misturadas.
Alguns cabeçalhos são adicionados ou são anexados valores aos mesmos. Os Application Load Balancers externos adicionam ou modificam sempre determinados cabeçalhos, como
ViaeX-Forwarded-For.
Balanceadores de carga de aplicações externos regionais e balanceadores de carga de aplicações internos regionais
Não existe processamento de cabeçalhos especial para equilibradores de carga baseados no Envoy que usam NEGs de Internet. Para saber como o Envoy processa normalmente os cabeçalhos, consulte o artigo Manipulação de cabeçalhos HTTP.
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.
Por exemplo, durante esta indisponibilidade, os clientes que enviam pedidos para
equilibradores de carga de aplicações externos globais veem erros
502com o código de errofailed_to_connect_to_backend. Este comportamento é o esperado.
- As seguintes funcionalidades avançadas de gestão de tráfego não são suportadas com back-ends NEG da Internet globais:
- Pedir espelhamento
- Políticas de repetição
- Políticas de tráfego (incluindo a política de localidade de equilíbrio de carga, a afinidade de sessão e a deteção de valores atípicos)
- Reveja a secção Gateway do Cloud NAT para ver as limitações associadas a gateways de NAT configurados 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 custos 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 global com um NEG de Internet
- Configure um Application Load Balancer clássico com um NEG da Internet
- Configure o Cloud CDN para um balanceador de carga de aplicações externo com um back-end externo
- Vista geral dos grupos de pontos finais de rede da Internet com o Cloud Service Mesh
- 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