Vista geral do balanceador de carga de aplicações externo

Este documento apresenta os conceitos que tem de compreender para configurar um Application Load Balancer externo.

Um Application Load Balancer externo é um balanceador de carga da camada 7 baseado em proxy que lhe permite executar e dimensionar os seus serviços através de um único endereço IP externo. O balanceador de carga de aplicações externo distribui o tráfego HTTP e HTTPS para back-ends alojados numa variedade deGoogle Cloud plataformas (como o Compute Engine, o Google Kubernetes Engine [GKE] e o Cloud Storage), bem como back-ends externos ligados através da Internet ou de conetividade híbrida. Para mais detalhes, consulte o artigo Vista geral do Application Load Balancer: exemplos de utilização.

Modos de funcionamento

Pode configurar um Application Load Balancer externo nos seguintes modos:

• Balanceador de carga de aplicações externo global. Este é um equilibrador de carga global que é implementado como um serviço gerido nos front-ends da Google (GFEs). Usa o proxy Envoy de código aberto para suportar capacidades de gestão de tráfego avançada, como a replicação de tráfego, a divisão de tráfego baseada em peso e as transformações de cabeçalhos baseadas em pedidos ou respostas.
• Classic Application Load Balancer. Este é o Application Load Balancer externo clássico que é global no nível Premium, mas pode ser configurado para ser regional no nível Standard. Este balanceador de carga é implementado em front-ends da Google (GFEs). Os GFEs são distribuídos globalmente e funcionam em conjunto através da rede global e do plano de controlo da Google.
• Balanceador de carga de aplicações externo regional. Este é um balanceador de carga regional que é implementado como um serviço gerido no proxy Envoy de código aberto. Inclui capacidades de gestão avançada de tráfego, como a replicação de tráfego, a divisão de tráfego baseada em peso e as transformações de cabeçalhos baseadas em pedidos ou respostas.

Modo do balanceador de carga	Exemplos de utilização recomendados	Capacidades
Balanceador de carga de aplicações externo global	Use este balanceador de carga para cargas de trabalho HTTP(S) externas com utilizadores dispersos a nível global ou serviços de back-end em várias regiões.	Compatível com o GKE através de Gateway (totalmente orquestrado) ou NEGs autónomos (orquestração manual) Suporta gestão avançada de tráfego Endereços IP externos de Anycast global através do nível Premium Pode aceder a back-ends em várias regiões Suporta o Cloud CDN Suporta o Cloud Armor
Balanceador de carga de aplicações clássico	Este balanceador de carga é global no nível Premium. No nível do serviço de rede premium, este equilibrador de carga oferece o equilíbrio de carga em várias regiões, tenta direcionar o tráfego para o back-end saudável mais próximo que tenha capacidade e termina o tráfego HTTP(S) o mais próximo possível dos seus utilizadores. Para ver detalhes sobre o processo de distribuição de pedidos, consulte o artigo Distribuição de tráfego. No nível de serviço de rede padrão, este balanceador de carga só pode distribuir tráfego para servidores de back-end numa única região.	Compatível com o GKE através de Gateway (totalmente orquestrado), Ingress (totalmente orquestrado) ou NEGs autónomos (orquestração manual) Suporta o Google Cloud Armor Menos funcionalidades de planeamento de rotas com base no trânsito Consulte a página de funcionalidades de equilíbrio de carga para ver a lista completa de capacidades.
Balanceador de carga de aplicações externo regional	Este balanceador de carga contém muitas das funcionalidades do balanceador de carga de aplicações clássico existente, juntamente com capacidades de gestão de tráfego avançadas. Use este equilibrador de carga se quiser publicar conteúdo a partir de apenas uma geolocalização (por exemplo, para cumprir os regulamentos de conformidade). Este equilibrador de carga pode ser configurado no nível Premium ou Standard.	Compatível com o GKE através de NEGs autónomos (orquestração manual) Suporta capacidades de gestão avançada de tráfego VIPs regionais que usam o nível da rede padrão Termina o TLS numa única região que configura Apresenta conteúdo apenas da região configurada Para ver a lista completa, consulte Funcionalidades de equilíbrio de carga.

Identifique o modo

Consola

1. Na Google Cloud consola, aceda à página Equilíbrio de carga.

   Aceda a Balanceamento de carga

2. No separador Balanceadores de carga, são apresentados o tipo, o protocolo e a região do balanceador de carga. Se a região estiver em branco, o balanceador de carga é global. A tabela seguinte resume como identificar o modo do equilibrador de carga.

Modo do balanceador de carga	Tipo de balanceador de carga	Tipo de acesso	Região
Balanceador de carga de aplicações externo global	Aplicação	Externo
Balanceador de carga de aplicações clássico	Aplicação(clássica)	Externo
Balanceador de carga de aplicações externo regional	Aplicação	Externo	Especifica uma região

gcloud

Para determinar o modo de um equilibrador de carga, execute o seguinte comando:

   gcloud compute forwarding-rules describe FORWARDING_RULE_NAME
   

Na saída do comando, verifique o esquema de balanceamento de carga, a região e o nível de rede. A tabela seguinte resume como identificar o modo do equilibrador de carga.

Modo do balanceador de carga	Esquema de balanceamento de carga	Regra de encaminhamento	Nível da rede
Balanceador de carga de aplicações externo global	EXTERNAL_MANAGED	Global	Premium
Balanceador de carga de aplicações clássico	EXTERNO	Global	Standard ou Premium
Balanceador de carga de aplicações externo regional	EXTERNAL_MANAGED	Especifica uma região	Standard ou Premium

Importante: depois de criar um equilibrador de carga, não pode editar o respetivo modo. Em alternativa, tem de eliminar o balanceador de carga e criar um novo.

Arquitetura

Os seguintes recursos são necessários para uma implementação do balanceador de carga da aplicação externo:

• Apenas para balanceadores de carga de aplicações externos regionais, é usada uma sub-rede apenas de proxy para enviar ligações do balanceador de carga para os back-ends.

• Uma regra de encaminhamento externa especifica um endereço IP externo, uma porta e um proxy HTTP(S) de destino. Os clientes usam o endereço IP e a porta para estabelecer ligação ao equilibrador de carga.

• Um proxy HTTP(S) de destino recebe um pedido do cliente. O proxy HTTP(S) avalia o pedido através do mapa de URLs para tomar decisões de encaminhamento de tráfego. O proxy também pode autenticar comunicações através de certificados SSL.

  • Para o balanceamento de carga HTTPS, o proxy HTTPS de destino usa certificados SSL para provar a sua identidade aos clientes. Um proxy HTTPS de destino suporta até ao número documentado de certificados SSL.

• O proxy HTTP(S) usa um mapa de URLs para tomar uma determinação de encaminhamento com base em atributos HTTP (como o caminho do pedido, os cookies ou os cabeçalhos). Com base na decisão de encaminhamento, o proxy encaminha os pedidos do cliente para serviços de back-end ou contentores de back-end específicos. O mapa de URLs pode especificar ações adicionais, como o envio de redirecionamentos para clientes.

• Um serviço de back-end distribui pedidos para back-ends íntegros. Os balanceadores de carga de aplicações externos globais também suportam contentores de back-end. Tem de associar um ou mais back-ends ao serviço de back-end ou ao contentor de back-end.

• Uma verificação de funcionamento monitoriza periodicamente a prontidão dos seus back-ends. Isto reduz o risco de os pedidos serem enviados para back-ends que não conseguem processar o pedido.

• Regras de firewall para que os seus back-ends aceitem sondagens de verificação de funcionamento. Os balanceadores de carga de aplicações externos regionais requerem uma regra de firewall adicional para permitir que o tráfego da sub-rede só de proxy alcance os back-ends.

Global

Este diagrama mostra os componentes de uma implementação do Application Load Balancer externo global. Esta arquitetura aplica-se ao balanceador de carga de aplicações externo global e ao balanceador de carga de aplicações clássico no nível Premium.

Componentes do balanceador de carga de aplicações externo global (clique para aumentar).

Regional

Este diagrama mostra os componentes de uma implementação de um Application Load Balancer externo regional.

Componentes do balanceador de carga da aplicação externo regional (clique para ampliar).

Sub-rede só de proxy

As sub-redes apenas de proxy só são necessárias para equilibradores de carga de aplicações externos regionais.

A sub-rede apenas de proxy fornece um conjunto de endereços IP que a Google usa para executar proxies do Envoy em seu nome. Tem de criar uma sub-rede apenas de proxy em cada região de uma rede VPC onde usa balanceadores de carga de aplicações externos regionais. A flag --purpose para esta sub-rede apenas de proxy está definida como REGIONAL_MANAGED_PROXY. Todos os equilibradores de carga baseados no Envoy regionais na mesma região e rede VPC partilham um conjunto de proxies do Envoy da mesma sub-rede apenas de proxy. Além disso:

• As sub-redes apenas de proxy são usadas apenas para proxies do Envoy e não para os seus back-ends.
• As VMs ou os pontos finais de back-end de todos os equilibradores de carga de aplicações externos regionais numa região e numa rede VPC recebem ligações da sub-rede apenas de proxy.
• O endereço IP do Application Load Balancer externo regional não está localizado na sub-rede apenas de proxy. O endereço IP do balanceador de carga é definido pela respetiva regra de encaminhamento gerida externa, que é descrita abaixo.

Se criou anteriormente uma sub-rede só de proxy com o comando --purpose=INTERNAL_HTTPS_LOAD_BALANCER, migre a finalidade da sub-rede para REGIONAL_MANAGED_PROXY antes de poder criar outros balanceadores de carga baseados no Envoy na mesma região da rede VPC.

Regras de encaminhamento e endereços IP

As regras de encaminhamento encaminham o tráfego por endereço IP, porta e protocolo para uma configuração de equilíbrio de carga que consiste num proxy de destino, num mapa de URLs e num ou mais serviços de back-end.

Especificação do endereço IP. Cada regra de encaminhamento fornece um único endereço IP que pode ser usado em registos DNS para a sua aplicação. Não é necessário o equilíbrio de carga baseado em DNS. Pode especificar o endereço IP a usar ou permitir que o Cloud Load Balancing atribua um por si.

Especificação da porta. Cada regra de encaminhamento para um Application Load Balancer pode fazer referência a uma única porta de 1 a 65535. Para suportar várias portas, tem de configurar várias regras de encaminhamento. Pode configurar várias regras de encaminhamento para usar o mesmo endereço IP externo (VIP) e para referenciar o mesmo proxy HTTP(S) de destino, desde que a combinação geral de endereço IP, porta e protocolo seja exclusiva para cada regra de encaminhamento. Desta forma, pode usar um único equilibrador de carga com um mapa de URLs partilhado como um proxy para várias aplicações.

O tipo de regra de encaminhamento, endereço IP e esquema de balanceamento de carga usados pelos balanceadores de carga de aplicações externos dependem do modo do balanceador de carga e do nível do serviço de rede em que o balanceador de carga se encontra.

Modo do balanceador de carga	Nível de serviço de rede	Regra de encaminhamento, endereço IP e esquema de balanceamento de carga	Encaminhamento da Internet para a interface do balanceador de carga
Balanceador de carga de aplicações externo global	Nível premium	Regra de encaminhamento externo global Endereço IP externo global Esquema de balanceamento de carga: EXTERNAL_MANAGED	Pedidos encaminhados para o GFE mais próximo do cliente na Internet.
Balanceador de carga de aplicações clássico	Nível premium	Regra de encaminhamento externo global Endereço IP externo global Esquema de balanceamento de carga: EXTERNAL ^1	Pedidos encaminhados para o GFE mais próximo do cliente na Internet.
	Nível Standard	Regra de encaminhamento externo regional Endereço IP externo regional Esquema de balanceamento de carga: EXTERNAL^1	Pedidos encaminhados para um GFE na região do balanceador de carga.
Balanceador de carga de aplicações externo regional	Nível premium ou nível padrão	Regra de encaminhamento externo regional Endereço IP externo regional Esquema de balanceamento de carga: EXTERNAL_MANAGED	Os pedidos chegam Google Cloud ao PoP mais próximo do cliente. Os pedidos são, em seguida, encaminhados através da rede principal premium da Google até chegarem aos proxies Envoy na mesma região que o equilibrador de carga. Google Cloud

¹ É possível anexar serviços de back-end a regras de encaminhamento EXTERNAL.EXTERNAL_MANAGED No entanto, não é possível anexar serviços de back-end da EXTERNAL a regras de encaminhamento da EXTERNAL_MANAGED. Para tirar partido das novas funcionalidades disponíveis apenas com o Application Load Balancer externo global, recomendamos que migre os seus recursos EXTERNAL existentes para EXTERNAL_MANAGED através do processo de migração descrito em Migre recursos do Application Load Balancer externo clássico para o global.

Para ver a lista completa de protocolos suportados pelas regras de encaminhamento do Application Load Balancer externo em cada modo, consulte as funcionalidades do balanceador de carga.

Regras de encaminhamento e redes VPC

Esta secção descreve como as regras de encaminhamento usadas por equilibradores de carga de aplicações externos estão associadas a redes VPC.

Modo do balanceador de carga	Associação da rede da VPC
Balanceador de carga de aplicações externo global Balanceador de carga de aplicações clássico	Nenhuma rede de VPC associada. A regra de encaminhamento usa sempre um endereço IP que está fora da rede VPC. Por conseguinte, a regra de encaminhamento não tem nenhuma rede de VPC associada.
Balanceador de carga de aplicações externo regional	A rede VPC da regra de encaminhamento é a rede onde a sub-rede só de proxy foi criada. Especifica a rede quando cria a regra de encaminhamento. Consoante use um intervalo de endereços IPv4 ou IPv6, existe sempre uma rede VPC explícita ou implícita associada à regra de encaminhamento. Os endereços IPv4 externos regionais existem sempre fora das redes VPC. No entanto, quando cria a regra de encaminhamento, tem de especificar a rede VPC onde a sub-rede apenas de proxy foi criada. Por conseguinte, a regra de encaminhamento tem uma associação de rede explícita. Os intervalos de endereços IPv6 externos regionais existem sempre numa rede VPC. Quando cria a regra de encaminhamento, tem de especificar a sub-rede a partir da qual é retirado o intervalo de endereços IP. Esta sub-rede tem de estar na mesma região e na rede VPC onde foi criada uma sub-rede apenas de proxy. Assim, existe uma associação de rede implícita.

Proxies de destino

Os proxies de destino terminam as ligações HTTP(S) dos clientes. Uma ou mais regras de encaminhamento direcionam o tráfego para o proxy de destino, e o proxy de destino consulta o mapa de URLs para determinar como encaminhar o tráfego para os back-ends.

Não confie no proxy para preservar a capitalização dos nomes dos cabeçalhos de pedidos ou respostas. Por exemplo, um cabeçalho de resposta Server: Apache/1.0 pode aparecer no cliente como server: Apache/1.0.

Nota: para grupos de pontos finais de rede (NEGs) da Internet, os pedidos do equilibrador de carga provêm de diferentes intervalos de IP, consoante o tipo de NEG (global ou regional). Para mais informações, consulte o artigo Autenticar pedidos.

A tabela seguinte especifica o tipo de proxy de destino exigido pelos equilibradores de carga de aplicações externos.

Modo do balanceador de carga	Tipos de proxies de destino	Cabeçalhos adicionados pelo proxy	Cabeçalhos personalizados suportados
Balanceador de carga de aplicações externo global	HTTP global, HTTPS global	Os proxies definem os cabeçalhos de pedido/resposta HTTP da seguinte forma: Via: 1.1 google (pedidos e respostas) X-Forwarded-Proto: [http | https] (apenas pedidos) X-Forwarded-For: [<supplied-value>,]<client-ip>,<load-balancer-ip> (consulte o cabeçalho X-Forwarded-For) (apenas pedidos) Os proxies também definem o cabeçalho X-Cloud-Trace-Context se ainda não estiver presente.	Configurado no serviço de back-end ou no contentor de back-end Não suportado com o Cloud CDN
Balanceador de carga de aplicações clássico	HTTP global, HTTPS global	Os proxies definem os cabeçalhos de pedido/resposta HTTP da seguinte forma: Via: 1.1 google (pedidos e respostas) X-Forwarded-Proto: [http | https] (apenas pedidos) X-Forwarded-For: [<supplied-value>,]<client-ip>,<load-balancer-ip> (consulte o cabeçalho X-Forwarded-For) (apenas pedidos) Os proxies também definem o cabeçalho X-Cloud-Trace-Context se ainda não estiver presente.	Configurado no serviço de back-end ou no contentor de back-end
Balanceador de carga de aplicações externo regional	HTTP regional, HTTPS regional	X-Forwarded-Proto: [http | https] (apenas pedidos) Via: 1.1 google (pedidos e respostas) X-Forwarded-For: [<supplied-value>,]<client-ip>,<load-balancer-ip> (consulte o cabeçalho X-Forwarded-For) (apenas pedidos)	Configurado no mapa de URLs

Nota: de acordo com o RFC 2616 , os seguintes cabeçalhos de salto a salto não são propagados pelo proxy de destino: Connection, Keep-Alive, Proxy-Authenticate, Proxy-Authorization, TE, Trailers, Transfer-Encoding e Upgrade.

Além dos cabeçalhos adicionados pelo proxy de destino, o balanceador de carga ajusta outros cabeçalhos HTTP das seguintes formas:

• Para o Application Load Balancer externo global, os cabeçalhos de pedidos e respostas podem ser convertidos em letras minúsculas.

  A única exceção a isto é quando usa back-ends NEG da Internet global com HTTP/1.1. Para ver detalhes sobre como os cabeçalhos HTTP/1.1 são processados com NEGs da Internet globais, consulte a vista geral dos NEGs da Internet.

• Para o balanceador de carga de aplicações clássico, os cabeçalhos de pedidos e respostas são convertidos em letras minúsculas, exceto quando usa HTTP/1.1. Com o HTTP/1.1, os cabeçalhos têm as letras maiúsculas e minúsculas adequadas. 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 para User-Agent, e content-encoding é alterado para Content-Encoding.

• 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, como Set-Cookie, nunca são unidos.

Cabeçalho de anfitrião

Quando o balanceador de carga faz o pedido HTTP, preserva o cabeçalho Host do pedido original.

Cabeçalho X-Forwarded-For

O balanceador de carga anexa dois endereços IP ao cabeçalho X-Forwarded-For, separados por uma única vírgula, na seguinte ordem:

1. O endereço IP do cliente que se liga ao equilibrador de carga
2. O endereço IP da regra de encaminhamento do balanceador de carga

Se o pedido recebido não incluir um cabeçalho X-Forwarded-For, o cabeçalho resultante é o seguinte:

X-Forwarded-For: <client-ip>,<load-balancer-ip>

Se o pedido recebido já incluir um cabeçalho X-Forwarded-For, o equilibrador de carga anexa os respetivos valores ao cabeçalho existente:

X-Forwarded-For: <existing-value>,<client-ip>,<load-balancer-ip>

Aviso: o balanceador de carga não valida nenhum endereço IP que preceda <client-ip>,<load-balancer-ip> neste cabeçalho. Os endereços IP anteriores podem conter outros carateres, incluindo espaços.

Remova valores de cabeçalho existentes através de um cabeçalho de pedido personalizado

É possível remover os valores dos cabeçalhos existentes através de cabeçalhos de pedidos personalizados no serviço de back-end. O exemplo seguinte usa a flag --custom-request-header para recriar o cabeçalho X-Forwarded-For usando as variáveis client_ip_address e server_ip_address. Esta configuração substitui o cabeçalho X-Forwarded-For recebido apenas pelo cliente e o endereço IP do balanceador de carga.

--custom-request-header=x-forwarded-for:{client_ip_address},{server_ip_address}

Nota: esta abordagem rejeita todos os valores X-Forwarded-For existentes do pedido. Uma vez que Google Cloud não regista valores de cabeçalho, não é possível recuperar estes valores. Se precisar de manter o conteúdo do cabeçalho original, pode armazená-lo num cabeçalho personalizado separado.

Como o software de proxy inverso de back-end pode modificar o cabeçalho X-Forwarded-For

Se os back-ends do balanceador de carga executarem software de proxy inverso HTTP, o software pode anexar um ou ambos os seguintes endereços IP ao final do cabeçalho X-Forwarded-For:

1. O endereço IP do GFE que se ligou ao back-end. Os endereços IP do GFE estão nos intervalos 130.211.0.0/22 e 35.191.0.0/16.

2. O endereço IP do próprio sistema de back-end.

Como resultado, um sistema a montante pode ver um cabeçalho X-Forwarded-For estruturado da seguinte forma:

<existing-value>,<client-ip>,<load-balancer-ip>,<GFE-ip>,<backend-ip>

Apoio técnico do Cloud Trace

O rastreio não é suportado com equilibradores de carga de aplicações. Os equilibradores de carga de aplicações globais e clássicos adicionam o cabeçalho X-Cloud-Trace-Context se não estiver presente. O balanceador de carga de aplicações externo regional não adiciona este cabeçalho. Se o cabeçalho X-Cloud-Trace-Context já estiver presente, passa pelos balanceadores de carga sem alterações. No entanto, o equilibrador de carga não exporta rastreios nem intervalos.

Mapas de URLs

Os mapeamentos de URLs definem padrões de correspondência para o encaminhamento baseado em URLs de pedidos para os serviços de back-end adequados. O mapa de URLs permite dividir o tráfego examinando os componentes do URL para enviar pedidos a diferentes conjuntos de back-ends. É definido um serviço predefinido para processar todos os pedidos que não correspondam a uma regra de anfitrião especificada ou a uma regra de correspondência de caminho.

Em algumas situações, como o exemplo de equilíbrio de carga em várias regiões, pode não definir regras de URL e depender apenas do serviço predefinido.

Os mapas de URLs suportam várias funcionalidades avançadas de gestão de tráfego, como o encaminhamento de tráfego baseado em cabeçalhos, a divisão de tráfego baseada em peso e a replicação de pedidos. Para mais informações, consulte o seguinte:

• Vista geral da gestão de tráfego para o balanceador de carga de aplicações externo global

• Vista geral da gestão de tráfego para o balanceador de carga de aplicações externo regional

A tabela seguinte especifica o tipo de mapa de URLs exigido pelos equilibradores de carga de aplicações externos em cada modo.

Modo do balanceador de carga	Tipo de mapa de URL
Balanceador de carga de aplicações externo global	Global
Balanceador de carga de aplicações clássico	Global (com apenas um subconjunto das funcionalidades suportadas)
Balanceador de carga de aplicações externo regional	Regional

Certificados SSL

Os balanceadores de carga de aplicações externos que usam proxies HTTPS de destino requerem chaves privadas e certificados SSL como parte da configuração do balanceador de carga.

• Google Cloud oferece dois métodos de configuração para atribuir chaves privadas e certificados SSL a proxies HTTPS de destino: certificados SSL do Compute Engine e Certificate Manager. Para ver uma descrição de cada configuração, consulte os métodos de configuração de certificados na vista geral dos certificados SSL.

• Google Cloud oferece dois tipos de certificados: autogerido e gerido pela Google. Para uma descrição de cada tipo, consulte Tipos de certificados na vista geral dos certificados SSL.

O tipo de Application Load Balancer externo (global, regional ou clássico) determina que métodos de configuração e tipos de certificados são suportados. Para mais detalhes, consulte a secção Certificados e Google Cloud equilibradores de carga na vista geral dos certificados SSL.

Políticas de SSL

As políticas SSL especificam o conjunto de funcionalidades SSL que os balanceadores de carga usam quando negociam SSL com os clientes. Google Cloud

Por predefinição, o balanceamento de carga HTTPS usa um conjunto de funcionalidades SSL que oferece uma boa segurança e uma ampla compatibilidade. Algumas aplicações requerem mais controlo sobre as versões e as cifras SSL usadas para as respetivas ligações HTTPS ou SSL. Pode definir uma política de SSL para especificar o conjunto de funcionalidades de SSL que o seu equilibrador de carga usa quando negoceia SSL com os clientes. Além disso, pode aplicar essa política de SSL ao seu proxy HTTPS de destino.

A tabela seguinte especifica o suporte da política SSL para equilibradores de carga em cada modo.

Modo do balanceador de carga	Políticas de SSL suportadas
Balanceador de carga de aplicações externo global
Balanceador de carga de aplicações clássico
Balanceador de carga de aplicações externo regional

Serviços de back-end

Um serviço de back-end fornece informações de configuração ao equilibrador de carga para que possa direcionar pedidos para os respetivos back-ends, por exemplo, grupos de instâncias do Compute Engine ou grupos de pontos finais de rede (NEGs). Para mais informações sobre os serviços de back-end, consulte a vista geral dos serviços de back-end.

Para ver um exemplo que mostra como configurar um balanceador de carga com um serviço de back-end e um back-end do Compute Engine, consulte o artigo Configurar um balanceador de carga de aplicações externo com um back-end do Compute Engine.

Âmbito do serviço de back-end

A tabela seguinte indica o recurso e o âmbito do serviço de back-end usados pelos balanceadores de carga de aplicações externos:

Modo do balanceador de carga	Recurso de serviço de back-end
Balanceador de carga de aplicações externo global	backendServices (global)
Balanceador de carga de aplicações clássico	backendServices (global)
Balanceador de carga de aplicações externo regional	regionBackendServices (regional)

Protocolo para os back-ends

Os serviços de back-end para balanceadores de carga de aplicações têm de usar um dos seguintes protocolos para enviar pedidos para back-ends:

• HTTP, que usa HTTP/1.1 e não usa TLS
• HTTPS, que usa HTTP/1.1 e TLS
• HTTP/2, que usa HTTP/2 e TLS (o HTTP/2 sem encriptação não é suportado).
• H2C, que usa HTTP/2 sobre TCP. O TLS não é obrigatório. O H2C não é suportado para balanceadores de carga de aplicações clássicos.

O balanceador de carga usa apenas o protocolo de serviço de back-end que especificar para comunicar com os respetivos back-ends. O balanceador de carga não recorre a um protocolo diferente se não conseguir comunicar com os back-ends através do protocolo de serviço de back-end especificado.

O protocolo do serviço de back-end não tem de corresponder ao protocolo usado pelos clientes para comunicar com o balanceador de carga. Por exemplo, os clientes podem enviar pedidos ao balanceador de carga através de HTTP/2, mas o balanceador de carga pode comunicar com os back-ends através de HTTP/1.1 (HTTP ou HTTPS).

Contentores de back-end

Os contentores de back-end direcionam o tráfego de entrada para contentores do Cloud Storage. Para ver um exemplo de como adicionar um contentor a um balanceador de carga de aplicações externo, consulte o artigo Configurar um balanceador de carga com contentores de back-end. Para ver informações gerais sobre o Cloud Storage, consulte o artigo O que é o Cloud Storage?

Back-ends

A tabela seguinte especifica os back-ends e as funcionalidades relacionadas suportadas pelos Application Load Balancers externos em cada modo.

Modo do balanceador de carga	Back-ends suportados num serviço de back-end^1						Suporta contentores de back-end	Suporta o Cloud Armor	Suporta o Cloud CDN^2	Suporta IAP^2	Suporta extensões de serviços
	Grupos de instâncias^3	Zonal NEGs^4	NEGs da Internet	NEGs sem servidor	NEGs híbridos	NEGs do Private Service Connect
Balanceador de carga de aplicações externo global
Balanceador de carga de aplicações clássico									Nível premium
Balanceador de carga de aplicações externo regional

¹Os back-ends num serviço de back-end têm de ser do mesmo tipo: todos os grupos de instâncias ou todos do mesmo tipo de NEG. Uma exceção a esta regra é que os NEGs zonais e os NEGs híbridos podem ser usados no mesmo serviço de back-end para suportar uma arquitetura híbrida.GCE_VM_IP_PORT

² O CNA e o Cloud CDN são incompatíveis entre si. Não é possível ativá-las ambas no mesmo serviço de back-end.

³ As combinações de grupos de instâncias geridos zonais, não geridos zonais e regionais são suportadas no mesmo serviço de back-end. Quando usar o ajuste de escala automático para um grupo de instâncias gerido que seja um back-end para dois ou mais serviços de back-end, configure a política de ajuste de escala automático do grupo de instâncias para usar vários sinais.

⁴ Os NEGs zonais têm de usar pontos finais GCE_VM_IP_PORT.

Back-ends e redes VPC

As restrições sobre a localização dos back-ends dependem do tipo de equilibrador de carga.

Para back-ends do Application Load Balancer externo global, aplica-se o seguinte:

• As instâncias de back-end (para back-ends do grupo de instâncias) e os pontos finais de back-end (para back-ends do NEG) podem estar localizados em qualquer rede de VPC na mesma organização. As diferentes redes VPC não precisam de estar ligadas através do intercâmbio das redes da VPC, porque os GFEs comunicam diretamente com os back-ends nas respetivas redes VPC.

• Os contentores do Cloud Storage não estão associados a uma rede VPC. Podem estar localizados em qualquer projeto na mesma organização.

  Os balanceadores de carga de aplicações externos globais também suportam ambientes de VPC partilhada, onde pode partilhar redes VPC e os respetivos recursos associados entre projetos. No entanto, para os Application Load Balancers externos globais, não precisa de configurar a VPC partilhada para poder referenciar serviços de back-end ou contentores de back-end de outros projetos na sua organização.

Para back-ends do balanceador de carga de aplicações clássico, aplica-se o seguinte:

• Todas as instâncias de back-end dos back-ends de grupos de instâncias e todos os pontos finais de back-end dos back-ends de NEG têm de estar localizados no mesmo projeto. No entanto, um back-end de grupo de instâncias ou um NEG pode usar uma rede VPC diferente nesse projeto. Não é necessário ligar as diferentes redes VPC através do intercâmbio das redes da VPC, porque os GFEs comunicam diretamente com os back-ends nas respetivas redes VPC.

• Os contentores do Cloud Storage não estão associados a uma rede VPC. No entanto, têm de estar localizadas no mesmo projeto que o balanceador de carga.

Para back-ends do Application Load Balancer externo regional, aplica-se o seguinte:

• Para grupos de instâncias, NEGs zonais e NEGs de conetividade híbrida, todos os back-ends têm de estar localizados no mesmo projeto e região que o serviço de back-end. No entanto, um equilibrador de carga pode fazer referência a um back-end que usa uma rede VPC diferente no mesmo projeto que o serviço de back-end. A conetividade entre a rede VPC do balanceador de carga e a rede VPC de back-end pode ser configurada através do intercâmbio da rede VPC, de túneis do Cloud VPN, de anexos de VLAN do Cloud Interconnect ou de uma framework do Network Connectivity Center.

  Definição da rede de back-end

  • Para NEGs zonais e NEGs híbridos, especifica explicitamente a rede VPC quando cria o NEG.
  • Para grupos de instâncias geridas, a rede VPC é definida no modelo de instância.
  • Para grupos de instâncias não geridos, a rede VPC do grupo de instâncias é definida para corresponder à rede VPC da interface nic0 para a primeira VM adicionada ao grupo de instâncias.

  Requisitos de rede de back-end

  A rede do seu back-end tem de cumprir um dos seguintes requisitos de rede:

  • A rede da VPC do back-end tem de corresponder exatamente à rede da VPC da regra de encaminhamento.

  • A rede da VPC do back-end tem de estar ligada à rede da VPC da regra de encaminhamento através do intercâmbio das redes da VPC. Tem de configurar as trocas de trajetos de sub-rede para permitir a comunicação entre a sub-rede apenas de proxy na rede VPC da regra de encaminhamento e as sub-redes usadas pelas instâncias ou os pontos finais de back-end.

• Tanto a rede de VPC do back-end como a rede de VPC da regra de encaminhamento têm de ter raios de VPC anexados ao mesmo hub do Network Connectivity Center. Os filtros de importação e exportação têm de permitir a comunicação entre a sub-rede apenas de proxy na rede VPC da regra de encaminhamento e as sub-redes usadas por instâncias ou pontos finais de back-end.

• Para todos os outros tipos de back-end, todos os back-ends têm de estar localizados na mesma rede e região da VPC.

  Os equilibradores de carga de aplicações externos regionais também suportam ambientes de VPC partilhada, onde pode partilhar redes VPC e os respetivos recursos associados entre projetos. Se quiser que o serviço de back-end e os back-ends do Application Load Balancer externo regional estejam num projeto diferente da regra de encaminhamento, tem de configurar o equilibrador de carga num ambiente de VPC partilhada com referências de serviços entre projetos.

Back-ends e interfaces de rede

Se usar back-ends de grupos de instâncias, os pacotes são sempre entregues a nic0. Se quiser enviar pacotes para interfaces não nic0 (vNICs ou interfaces de rede dinâmicas), use backends de NEG.

Se usar back-ends de NEG zonais, os pacotes são enviados para qualquer interface de rede representada pelo ponto final no NEG. Os pontos finais do NEG têm de estar na mesma rede VPC que a rede VPC definida explicitamente do NEG.

Verificações de funcionamento

Cada serviço de back-end especifica uma verificação de estado que monitoriza periodicamente a disponibilidade dos back-ends para receber uma ligação do equilibrador de carga. Isto reduz o risco de os pedidos serem enviados para back-ends que não podem processar o pedido. As verificações de estado não verificam se a própria aplicação está a funcionar.

Para as sondas de verificação do estado, tem de criar uma regra de firewall de permissão de entrada que permita que as sondas de verificação do estado alcancem as instâncias de back-end. Normalmente, as sondas de verificação de funcionamento têm origem no mecanismo de verificação de funcionamento centralizado da Google.

Os balanceadores de carga de aplicações externos regionais que usam back-ends de NEG híbridos são uma exceção a esta regra porque as respetivas verificações de funcionamento têm origem na sub-rede apenas de proxy. Para ver detalhes, consulte a vista geral das NEGs híbridas.

Protocolo de verificação de funcionamento

Embora não seja obrigatório e nem sempre seja possível, é uma prática recomendada usar uma verificação de estado cujo protocolo corresponda ao protocolo do serviço de back-end. Por exemplo, uma verificação de funcionamento de HTTP/2 testa com maior precisão a conetividade HTTP/2 aos back-ends. Por outro lado, os balanceadores de carga de aplicações externos regionais que usam back-ends de NEG híbridos não suportam verificações de funcionamento de gRPC. Para ver a lista de protocolos de verificação de funcionamento suportados, consulte as funcionalidades de balanceamento de carga.

A tabela seguinte especifica o âmbito das verificações de estado suportadas pelos equilibradores de carga de aplicações externos em cada modo.

Modo do balanceador de carga	Tipo de verificação de funcionamento
Balanceador de carga de aplicações externo global	Global
Balanceador de carga de aplicações clássico	Global
Balanceador de carga de aplicações externo regional	Regional

Para mais informações sobre as verificações de funcionamento, consulte o seguinte:

• Vista geral das verificações de saúde
• Criar verificações de funcionamento

Regras de firewall

O balanceador de carga requer as seguintes regras de firewall:

• Para os balanceadores de carga de aplicações externos globais, uma regra de permissão de entrada para permitir que o tráfego dos front-ends da Google (GFEs) alcance os seus back-ends. Para o balanceador de carga de aplicações externo regional, uma regra de permissão de entrada para permitir que o tráfego da sub-rede só de proxy alcance os seus back-ends.
• Uma regra de permissão de entrada para permitir o tráfego dos intervalos de sondas de verificação de funcionamento. Para mais informações sobre as sondas de verificação de estado e o motivo pelo qual é necessário permitir o tráfego das mesmas, consulte o artigo Intervalos de IPs de sondas e regras de firewall.

As regras de firewall são implementadas ao nível da instância da VM e não nos proxies GFE. Não pode usar Google Cloud regras de firewall para impedir que o tráfego alcance o balanceador de carga. Para o balanceador de carga de aplicações externo global e o balanceador de carga de aplicações clássico, pode usar o Google Cloud Armor para o conseguir.

As portas destas regras de firewall têm de ser configuradas da seguinte forma:

• Permita o tráfego para a porta de destino da verificação do estado de funcionamento de cada serviço de back-end.

• Para back-ends de grupos de instâncias: determine as portas a configurar através do mapeamento entre a porta denominada do serviço de back-end e os números das portas associados a essa porta denominada em cada grupo de instâncias. Os números das portas podem variar entre os grupos de instâncias atribuídos ao mesmo serviço de back-end.

• Para back-ends de GCE_VM_IP_PORT NEG: permita o tráfego para os números de porta dos pontos finais.

A tabela seguinte resume os intervalos de endereços IP de origem necessários para as regras de firewall:

Modo do balanceador de carga	Intervalos de origens de verificações de funcionamento	Intervalos de origens dos pedidos
Balanceador de carga de aplicações externo global	35.191.0.0/16 130.211.0.0/22 Para o tráfego IPv6 para os back-ends: 2600:2d00:1:b029::/64	A origem do tráfego do GFE depende do tipo de back-end: Grupos de instâncias e NEGs zonais (GCE_VM_IP_PORT): 130.211.0.0/22 35.191.0.0/16 Para o tráfego IPv6 para os back-ends: 2600:2d00:1:1::/64 NEGs de conetividade híbrida (NON_GCP_PRIVATE_IP_PORT): 130.211.0.0/22 35.191.0.0/16 NEGs da Internet (INTERNET_FQDN_PORT e INTERNET_IP_PORT): 34.96.0.0/20 34.127.192.0/18 SERVERLESS NEGs e buckets de back-end: a rede de produção da Google processa o encaminhamento de pacotes
Balanceador de carga de aplicações clássico	35.191.0.0/16 130.211.0.0/22	A origem do tráfego do GFE depende do tipo de back-end: Grupos de instâncias, NEGs zonais (GCE_VM_IP_PORT) e NEGs de conetividade híbrida (NON_GCP_PRIVATE_IP_PORT): 35.191.0.0/16 130.211.0.0/22 NEGs da Internet (INTERNET_FQDN_PORT e INTERNET_IP_PORT): 34.96.0.0/20 34.127.192.0/18 SERVERLESS NEGs e buckets de back-end: a rede de produção da Google processa o encaminhamento de pacotes.
Balanceador de carga de aplicações externo regional	35.191.0.0/16 130.211.0.0/22 Para o tráfego IPv6 para os back-ends: 2600:2d00:1:b029::/64 Não é necessário permitir o tráfego dos intervalos de sondagem de verificação de estado da Google para NEGs híbridos. No entanto, se estiver a usar uma combinação de NEGs híbridos e zonais num único serviço de back-end, tem de permitir o tráfego dos intervalos de sondas de verificação de estado da Google para os NEGs zonais.	A sub-rede só de proxy que configurar.

Importante: certifique-se de que permite pacotes dos intervalos de verificação de estado de funcionamento completos. Se a sua regra de firewall permitir pacotes apenas de um subconjunto dos intervalos, pode ver falhas na verificação de estado porque o balanceador de carga não consegue comunicar com os seus back-ends. Isto provoca respostas de código de estado HTTP 502

Apoio técnico do GKE

O GKE usa balanceadores de carga de aplicações externos das seguintes formas:

• Os gateways externos criados com o controlador do GKE Gateway podem usar qualquer modo de um balanceador de carga de aplicações externo. Controla o modo do balanceador de carga escolhendo uma GatewayClass. O controlador do GKE Gateway usa sempre back-ends de GCE_VM_IP_PORTNEG zonaisGCE_VM_IP_PORT.

• Os ingressos externos criados com o controlador de ingressos do GKE são sempre balanceadores de carga de aplicações clássicos. O controlador GKE Ingress prefere usar back-ends NEG zonais GCE_VM_IP_PORT, embora os back-ends do grupo de instâncias também sejam suportados.

• Pode usar GCE_VM_IP_PORT NEG zonais criados e geridos pelos serviços do GKE como back-ends para qualquer equilibrador de carga de aplicações ou equilibrador de carga de rede de proxy. Para mais informações, consulte o artigo Balanceamento de carga nativa do contentor através de NEGs zonais autónomos.

Arquitetura de VPC partilhada

Os balanceadores de carga de aplicações externos suportam redes que usam a VPC partilhada. A VPC partilhada permite que as organizações liguem recursos de vários projetos a uma rede VPC comum para que possam comunicar entre si de forma segura e eficiente através de endereços IP internos dessa rede. Se ainda não estiver familiarizado com a VPC partilhada, leia a vista geral da VPC partilhada.

Existem várias formas de configurar um Application Load Balancer externo numa rede de VPC partilhada. Independentemente do tipo de implementação, todos os componentes do equilibrador de carga têm de estar na mesma organização.

Balanceador de carga	Componentes da interface	Componentes de back-end
Balanceador de carga de aplicações externo global	Se estiver a usar uma rede VPC partilhada para os seus back-ends, crie a rede necessária no projeto anfitrião da VPC partilhada. O endereço IP externo global, a regra de encaminhamento, o proxy HTTP(S) de destino e o mapa de URLs associado têm de ser definidos no mesmo projeto. Este projeto pode ser um projeto anfitrião ou um projeto de serviço.	Pode efetuar uma das seguintes ações: Crie serviços de back-end, contentores de back-end e back-ends (grupos de instâncias, NEGs sem servidor ou quaisquer outros tipos de back-end suportados) no mesmo projeto de serviço que os componentes de front-end. Crie serviços de back-end, contentores de back-end e back-ends (grupos de instâncias, NEGs sem servidor ou quaisquer outros tipos de back-end suportados) em projetos de serviço. Um único mapa de URLs pode fazer referência a serviços de back-end em diferentes projetos. Este tipo de implementação é conhecido como referência de serviços entre projetos. Cada serviço de back-end tem de ser definido no mesmo projeto que os back-ends aos quais faz referência. As verificações de estado de funcionamento associadas aos serviços de back-end também têm de ser definidas no mesmo projeto que o serviço de back-end. Os back-ends podem fazer parte de uma rede VPC partilhada do projeto anfitrião ou de uma rede VPC autónoma, ou seja, uma rede VPC não partilhada no projeto de serviço.
Balanceador de carga de aplicações clássico	O endereço IP externo global, a regra de encaminhamento, o proxy HTTP(S) de destino e o mapa de URLs associado têm de ser definidos no mesmo projeto de anfitrião ou de serviço que os back-ends.	Tem de definir um serviço de back-end global no mesmo projeto de anfitrião ou de serviço que os back-ends (grupos de instâncias ou NEGs). As verificações de estado de funcionamento associadas aos serviços de back-end também têm de ser definidas no mesmo projeto que o serviço de back-end.
Balanceador de carga de aplicações externo regional	Crie a rede e a sub-rede apenas de proxy necessárias no projeto anfitrião da VPC partilhada. O endereço IP externo regional, a regra de encaminhamento, o proxy HTTP(S) de destino e o mapa de URLs associado têm de ser definidos no mesmo projeto. Este projeto pode ser o projeto anfitrião ou um projeto de serviço.	Pode efetuar uma das seguintes ações: Crie serviços de back-end e back-ends (grupos de instâncias, NEGs sem servidor ou quaisquer outros tipos de back-end suportados) no mesmo projeto de serviço que os componentes de front-end. Crie serviços de back-end e back-ends (grupos de instâncias, NEGs sem servidor ou quaisquer outros tipos de back-end suportados) em tantos projetos de serviço quanto necessário. Um único mapa de URLs pode fazer referência a serviços de back-end em diferentes projetos. Este tipo de implementação é conhecido como referência de serviços entre projetos. Cada serviço de back-end tem de ser definido no mesmo projeto que os back-ends aos quais faz referência. As verificações de estado de funcionamento associadas aos serviços de back-end também têm de ser definidas no mesmo projeto que o serviço de back-end.

Embora possa criar todos os componentes de equilíbrio de carga e back-ends no projeto anfitrião da VPC partilhada, este tipo de implementação não separa as responsabilidades de administração de rede e desenvolvimento de serviços.

Todos os componentes do balanceador de carga e back-ends num projeto de serviço

O diagrama de arquitetura seguinte mostra uma implementação padrão de VPC partilhada em que todos os componentes do equilibrador de carga e os back-ends estão num projeto de serviço. Este tipo de implementação é suportado por todos os equilibradores de carga de aplicações.

Os componentes do equilibrador de carga e os back-ends têm de usar a mesma rede VPC.

Balanceador de carga de aplicações externo regional na rede VPC partilhada (clique para aumentar).

Back-ends sem servidor num ambiente de VPC partilhada

Para um equilibrador de carga que esteja a usar um back-end de NEG sem servidor, o serviço do Cloud Run ou das funções do Cloud Run do back-end tem de estar no mesmo projeto que o NEG sem servidor.

Além disso, para o Application Load Balancer externo regional que suporta a referência de serviços entre projetos, o serviço de back-end, o NEG sem servidor e o serviço do Cloud Run têm de estar sempre no mesmo projeto de serviço.

Referência de serviços entre projetos

A referência de serviços entre projetos é um modelo de implementação em que o front-end e o mapa de URLs do balanceador de carga estão num projeto, e o serviço de back-end e os back-ends do balanceador de carga estão num projeto diferente.

A referência de serviços entre projetos permite que as organizações configurem um balanceador de carga central e encaminhem o tráfego para centenas de serviços distribuídos por vários projetos diferentes. Pode gerir centralmente todas as regras de encaminhamento de tráfego e políticas num único mapa de URLs. Também pode associar o equilibrador de carga a um único conjunto de nomes de anfitriões e certificados SSL. Por conseguinte, pode otimizar o número de equilibradores de carga necessários para implementar a sua aplicação e reduzir a capacidade de gestão, os custos operacionais e os requisitos de quota.

Ao ter projetos diferentes para cada uma das suas equipas funcionais, também pode alcançar a separação de funções na sua organização. Os proprietários de serviços podem concentrar-se na criação de serviços em projetos de serviços, enquanto as equipas de rede podem aprovisionar e manter equilibradores de carga noutro projeto. Ambos podem ser ligados através da referência de serviços entre projetos.

Os proprietários de serviços podem manter a autonomia sobre a exposição dos respetivos serviços e controlar os utilizadores que podem aceder aos respetivos serviços através do balanceador de carga. Isto é conseguido através de uma função IAM especial denominada função de utilizador dos serviços do balanceador de carga do Compute (roles/compute.loadBalancerServiceUser).

O suporte de referências de serviços entre projetos difere consoante o tipo de balanceador de carga:

• Para equilibradores de carga de aplicações externos globais: o front-end e o mapa de URLs do equilibrador de carga podem fazer referência a serviços de back-end ou contentores de back-end de qualquer projeto na mesma organização. Não se aplicam restrições de rede VPC. Embora possa usar um ambiente de VPC partilhada para configurar uma implementação entre projetos, conforme mostrado neste exemplo, isto não é um requisito.

• Para balanceadores de carga de aplicações externos regionais: tem de criar o balanceador de carga num ambiente de VPC partilhada. O front-end e o mapa de URLs do balanceador de carga têm de estar num projeto anfitrião ou de serviço, e os serviços de back-end e os back-ends do balanceador de carga podem ser distribuídos por projetos anfitriões ou de serviço no mesmo ambiente de VPC partilhada.

Para saber como configurar a VPC partilhada para um balanceador de carga de aplicações externo global, com e sem referências de serviços entre projetos, consulte o artigo Configure um balanceador de carga de aplicações externo global com a VPC partilhada.

Para saber como configurar a VPC partilhada para um balanceador de carga de aplicações externo regional, com e sem referências de serviços entre projetos, consulte o artigo Configure um balanceador de carga de aplicações externo regional com a VPC partilhada.

Notas de utilização para referências de serviços entre projetos

• É possível usar referências de serviços entre projetos com grupos de instâncias, NEGs sem servidor e a maioria dos outros tipos de back-end suportados. No entanto, aplicam-se as seguintes limitações:

  • Com os equilibradores de carga de aplicações externos globais, não pode fazer referência a um serviço de back-end entre projetos se o serviço de back-end tiver back-ends NEG sem servidor com o App Engine.

  • Com os Application Load Balancers externos regionais, não pode fazer referência a um serviço de back-end entre projetos se o serviço de back-end tiver back-ends de NEG de Internet regionais.
• A referência de serviços entre projetos não é suportada para o Application Load Balancer clássico.
• Google Cloud não faz a distinção entre recursos (por exemplo, serviços de back-end) que usam o mesmo nome em vários projetos. Por conseguinte, quando usar referências de serviços entre projetos, recomendamos que use nomes de serviços de back-end exclusivos entre projetos na sua organização.
• Se vir um erro como "As referências entre projetos para este recurso não são permitidas", certifique-se de que tem autorização para usar o recurso. Um administrador do projeto proprietário do recurso tem de lhe conceder a função de utilizador dos serviços de balanceamento de carga do Compute (roles/compute.loadBalancerServiceUser). Esta função pode ser concedida ao nível do projeto ou ao nível do recurso. Para ver um exemplo, consulte o artigo Conceda autorizações ao administrador do equilibrador de carga do Compute para usar o serviço de back-end ou o contentor de back-end.

Exemplo 1: front-end e back-end do balanceador de carga em diferentes projetos de serviço

Segue-se um exemplo de uma implementação de VPC partilhada em que o front-end e o mapa de URLs do equilibrador de carga são criados no projeto de serviço A, e o mapa de URLs faz referência a um serviço de back-end no projeto de serviço B.

Neste caso, os administradores de rede ou os administradores do balanceador de carga no projeto de serviço A precisam de acesso aos serviços de back-end no projeto de serviço B. Os administradores do projeto de serviço B concedem a função de utilizador dos serviços de equilibrador de carga de computação (roles/compute.loadBalancerServiceUser) aos administradores do equilibrador de carga no projeto de serviço A que querem fazer referência ao serviço de back-end no projeto de serviço B.

Front-end e back-end do balanceador de carga em diferentes projetos de serviço (clique para aumentar).

Exemplo 2: front-end do equilibrador de carga no projeto anfitrião e back-ends em projetos de serviço

Segue-se um exemplo de uma implementação de VPC partilhada em que o front-end e o mapa de URLs do equilibrador de carga são criados no projeto anfitrião, e os serviços de back-end (e os back-ends) são criados em projetos de serviço.

Neste caso, os administradores de rede ou os administradores do equilibrador de carga no projeto anfitrião precisam de acesso aos serviços de back-end no projeto de serviço. Os administradores do projeto de serviço concedem a função de utilizador dos serviços de equilibrador de carga de computação (roles/compute.loadBalancerServiceUser) aos administradores do equilibrador de carga no projeto anfitrião A que querem fazer referência ao serviço de back-end no projeto de serviço.

Front-end do balanceador de carga e mapa de URLs no projeto anfitrião (clique para aumentar).

Exemplo 3: interface e back-ends do balanceador de carga em projetos diferentes

Segue-se um exemplo de uma implementação em que o front-end do balanceador de carga de aplicações externo global e o mapa de URLs são criados num projeto diferente do serviço de back-end e dos back-ends do balanceador de carga. Este tipo de implementação não usa a VPC partilhada e só é suportado para equilibradores de carga de aplicações externos globais.

Front-end e back-ends do balanceador de carga em projetos diferentes (clique para aumentar).

Para saber mais acerca desta configuração, consulte o artigo Configure referências de serviços entre projetos com um serviço de back-end e um contentor de back-end.

Alta disponibilidade e ativação pós-falha

A elevada disponibilidade e a comutação por falha nos balanceadores de carga de aplicações externos podem ser configuradas ao nível do balanceador de carga. Isto é processado através da criação de balanceadores de carga de aplicações externos regionais de cópia de segurança em qualquer região onde precise de uma cópia de segurança.

A tabela seguinte descreve o comportamento de comutação por falha.

Modo do balanceador de carga	Métodos de comutação por falha
Balanceador de carga de aplicações externo global Balanceador de carga de aplicações clássico	Pode configurar uma configuração de comutação por falha ativa-passiva em que o tráfego comuta por falha para um Application Load Balancer externo regional de yedek. Usa verificações de estado para detetar interrupções e políticas de encaminhamento do Cloud DNS para encaminhar tráfego quando a comutação por falha é acionada.
Balanceador de carga de aplicações externo regional	Use um dos seguintes métodos para garantir uma implementação altamente disponível: Pode configurar uma configuração de comutação por falha ativa-passiva em que o tráfego comuta por falha para um Application Load Balancer externo regional de yedek. Usa verificações de funcionamento para detetar interrupções e uma política de encaminhamento de comutação por falha do Cloud DNS para encaminhar tráfego quando a comutação por falha é acionada por verificações de funcionamento com falhas. Para ver detalhes, consulte o artigo Failover para balanceadores de carga de aplicações externos. Pode configurar uma configuração de comutação por falha ativa-ativa em que implementa vários equilibradores de carga de aplicações externos regionais individuais em regiões que determinam que suportam melhor o tráfego para a sua aplicação. Usa uma política de encaminhamento de geolocalização do Cloud DNS para encaminhar o tráfego para a região adequada com base na origem do pedido do cliente. Também pode usar verificações de saúde para detetar indisponibilidades e encaminhar o tráfego apenas para os equilibradores de carga em bom estado. Para mais detalhes, consulte o artigo Alta disponibilidade para balanceadores de carga de aplicações externos regionais.

Compatibilidade com HTTP/2

O HTTP/2 é uma revisão importante do protocolo HTTP/1. Existem 2 modos de suporte do HTTP/2:

• HTTP/2 sobre TLS
• HTTP/2 em texto simples através de TCP

HTTP/2 sobre TLS

O HTTP/2 sobre TLS é suportado para ligações entre clientes e o balanceador de carga de aplicações externo, e para ligações entre o balanceador de carga e os respetivos back-ends.

O balanceador de carga negoceia automaticamente o HTTP/2 com os clientes como parte da negociação TLS através da extensão TLS ALPN. Mesmo que um balanceador de carga esteja configurado para usar HTTPS, os clientes modernos usam o HTTP/2 por predefinição. Isto é controlado no cliente e não no equilibrador de carga.

Se um cliente não suportar HTTP/2 e o balanceador de carga estiver configurado para usar HTTP/2 entre o balanceador de carga e as instâncias de back-end, o balanceador de carga pode negociar uma ligação HTTPS ou aceitar pedidos HTTP não seguros. Esses pedidos HTTPS ou HTTP são, em seguida, transformados pelo balanceador de carga para encaminhar os pedidos através de HTTP/2 para as instâncias de back-end.

Para usar o HTTP/2 sobre TLS, tem de ativar o TLS nos seus back-ends e definir o protocolo de serviço de back-end como HTTP2. Para mais informações, consulte o artigo Encriptação do equilibrador de carga para os back-ends.

Streams simultâneas máximas de HTTP/2

A definição HTTP/2 SETTINGS_MAX_CONCURRENT_STREAMS descreve o número máximo de streams que um ponto final aceita, iniciado pelo par. O valor anunciado por um cliente HTTP/2 a um equilibrador de carga é efetivamente insignificante porque o equilibrador de carga não inicia streams para o cliente.Google Cloud

Nos casos em que o balanceador de carga usa o HTTP/2 para comunicar com um servidor que está a ser executado numa VM, o balanceador de carga respeita o valor SETTINGS_MAX_CONCURRENT_STREAMS anunciado pelo servidor, até um valor máximo de 100. Na direção do pedido (Google Cloud equilibrador de carga → servidor gRPC), o equilibrador de carga usa a frame SETTINGS inicial do servidor gRPC para determinar quantos streams por ligação podem estar em uso simultaneamente. Se o servidor anunciar um valor superior a 100, o equilibrador de carga usa 100 como o número máximo de streams simultâneas. Se for anunciado um valor de zero, o balanceador de carga não pode encaminhar pedidos para o servidor e isto pode resultar em erros.

Tamanho da tabela de cabeçalhos dinâmicos HTTP/2

O HTTP/2 melhora significativamente o HTTP/1.1 com funcionalidades como a multiplexagem e a compressão de cabeçalhos HPACK. O HPACK usa uma tabela dinâmica que melhora a compressão de cabeçalhos, tornando tudo mais rápido. Para compreender o impacto das alterações dinâmicas ao tamanho da tabela de cabeçalhos no HTTP/2, como esta funcionalidade pode melhorar o desempenho e como um erro específico em várias bibliotecas de clientes HTTP pode causar problemas na compressão de cabeçalhos HPACK, consulte o artigo da comunidade.

Limitações do HTTP/2

• O HTTP/2 entre o balanceador de carga e a instância pode exigir significativamente mais ligações TCP à instância do que o HTTP ou o HTTPS. A partilha de ligações, uma otimização que reduz o número destas ligações com HTTP ou HTTPS, não está disponível com HTTP/2. Consequentemente, pode observar latências elevadas no back-end, uma vez que as ligações ao back-end são feitas com maior frequência.
• O HTTP/2 entre o balanceador de carga e o back-end não suporta a execução do protocolo WebSocket numa única stream de uma ligação HTTP/2 (RFC 8441).
• O HTTP/2 entre o balanceador de carga e o back-end não suporta o push de servidor.
• A taxa de erros e o volume de pedidos do gRPC não estão visíveis naGoogle Cloud API nem na Google Cloud consola. Se o ponto final gRPC devolver um erro, os registos do equilibrador de carga e os dados de monitorização comunicam o código de estado HTTP 200 OK.

HTTP/2 em texto não cifrado através de TCP (H2C)

O HTTP/2 de texto não cifrado através de TCP, também conhecido como H2C, permite-lhe usar o HTTP/2 sem TLS. O H2C é suportado para ambas as seguintes ligações:

• Ligações entre os clientes e o balanceador de carga. Não é necessária nenhuma configuração especial.

• Ligações entre o balanceador de carga e os respetivos back-ends.

  Para configurar o H2C para ligações entre o balanceador de carga e os respetivos back-ends, defina o protocolo do serviço de back-end como H2C.

O suporte de H2C também está disponível para balanceadores de carga criados com o controlador do GKE Gateway e o Cloud Service Mesh.

O H2C não é suportado para balanceadores de carga de aplicações clássicos.

Suporte de HTTP/3

O HTTP/3 é um protocolo de Internet de nova geração. É criado com base no IETF QUIC, um protocolo desenvolvido a partir do protocolo Google QUIC original. O HTTP/3 é suportado entre o balanceador de carga de aplicações externo, o Cloud CDN e os clientes.

O apoio técnico do Google QUIC (também conhecido como gQUIC) foi removido em abril de 2023 a favor do HTTP/3 sobre o IETF QUIC, que é uma norma do IETF e demonstrou ter um desempenho superior ao gQUIC.

Em concreto:

• O QUIC da IETF é um protocolo da camada de transporte que oferece controlo de congestionamento e fiabilidade semelhantes ao TCP, usa o TLS 1.3 para segurança e tem um desempenho melhorado.
• O HTTP/3 é uma camada de aplicação criada com base no IETF QUIC e depende do QUIC para processar a multiplexagem, o controlo de congestionamento, a deteção de perdas e a retransmissão.
• O HTTP/3 permite uma iniciação mais rápida da ligação do cliente, elimina o bloqueio de cabeça de fila em streams multiplexadas e suporta a migração de ligações quando o endereço IP de um cliente muda.
• O HTTP/3 é suportado para ligações entre clientes e o balanceador de carga, mas não para ligações entre o balanceador de carga e os respetivos back-ends.
• As ligações HTTP/3 usam o algoritmo de controlo de congestionamento BBR.

O HTTP/3 no equilibrador de carga pode melhorar os tempos de carregamento das páginas Web, reduzir o rebuffer do vídeo e melhorar o débito nas ligações com maior latência.

A tabela seguinte especifica o suporte de HTTP/3 para balanceadores de carga de aplicações externos em cada modo.

Modo do balanceador de carga	Suporte de HTTP/3
Balanceador de carga de aplicações externo global (sempre no nível Premium)
Balanceador de carga de aplicações clássico no nível Premium
Balanceador de carga de aplicações clássico no nível Standard
Balanceador de carga de aplicações externo regional (nível Premium ou Standard)

Como é negociado o HTTP/3

Quando o HTTP/3 está ativado, o balanceador de carga anuncia este suporte aos clientes, o que permite que os clientes que suportam o HTTP/3 tentem estabelecer ligações HTTP/3 com o balanceador de carga HTTPS.

• Os clientes implementados corretamente recorrem sempre ao HTTPS ou ao HTTP/2 quando não conseguem estabelecer uma ligação HTTP/3.
• Os clientes que suportam o HTTP/3 usam os respetivos conhecimentos anteriores em cache do suporte do HTTP/3 para poupar viagens de ida e volta desnecessárias no futuro.
• Devido a esta alternativa, a ativação ou a desativação do HTTP/3 no equilibrador de carga não interrompe a capacidade do equilibrador de carga de se ligar aos clientes.

O suporte é anunciado no cabeçalho da resposta HTTP Alt-Svc. Quando o HTTP/3 está ativado, as respostas do balanceador de carga incluem o seguinte valor do cabeçalho alt-svc:

alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000"

Nota: o cabeçalho Alt-Svc anuncia várias versões do HTTP/3 para suportar rascunhos anteriores usados por alguns clientes, por exemplo, o h3-29.

Se o HTTP/3 tiver sido definido explicitamente como DISABLE, as respostas não incluem um cabeçalho de resposta alt-svc.

Quando tem o HTTP/3 ativado no balanceador de carga HTTPS, em algumas circunstâncias, o cliente pode voltar a usar o HTTPS ou o HTTP/2 em vez de negociar o HTTP/3. Estas incluem o seguinte:

• Quando um cliente suporta versões do HTTP/3 que não são compatíveis com as versões do HTTP/3 suportadas pelo balanceador de carga HTTPS.
• Quando o equilibrador de carga deteta que o tráfego UDP está bloqueado ou com limite de velocidade de uma forma que impede o HTTP/3 de funcionar.
• O cliente não suporta o HTTP/3 e, por isso, não tenta negociar uma ligação HTTP/3.

Quando uma ligação volta a usar HTTPS ou HTTP/2, não consideramos isto uma falha do balanceador de carga.

Antes de ativar o HTTP/3, certifique-se de que os comportamentos descritos anteriormente são aceitáveis para as suas cargas de trabalho.

Configure o HTTP/3

As opções NONE (predefinição) e ENABLE ativam a compatibilidade com HTTP/3 para o balanceador de carga.

Quando o HTTP/3 está ativado, o balanceador de carga anuncia-o aos clientes, o que permite que os clientes que o suportam negociem uma versão HTTP/3 com o balanceador de carga. Os clientes que não suportam HTTP/3 não negociam uma ligação HTTP/3. Não tem de desativar explicitamente o HTTP/3, a menos que tenha identificado implementações de cliente danificadas.

Os balanceadores de carga de aplicações externos oferecem três formas de configurar o HTTP/3, conforme mostrado na tabela seguinte.

valor quicOverride	Comportamento
NONE	O suporte para HTTP/3 é anunciado aos clientes.
ENABLE	O suporte para HTTP/3 é anunciado aos clientes.
DISABLE	Desativa explicitamente a publicidade HTTP/3 e Google QUIC aos clientes.

Para ativar (ou desativar) explicitamente o HTTP/3, siga estes passos.

Consola: HTTPS

Nota: atualmente, a definição da negociação HTTP/3 não é suportada na página de proxies de destino e tem de ser configurada editando a configuração do balanceador de carga.

1. Na Google Cloud consola, aceda à página Equilíbrio de carga.

Aceda a Balanceamento de carga

1. Selecione o equilibrador de carga que quer editar.
2. Clique em Configuração do front-end.
3. Selecione o endereço IP e a porta do front-end que quer editar. Para editar uma configuração HTTP/3, o protocolo tem de ser HTTPS.

Ative o HTTP/3

1. Selecione o menu Negociação QUIC.
2. Para ativar explicitamente o HTTP/3 para este front-end, selecione Ativado.
3. Se tiver várias regras de front-end que representam IPv4 e IPv6, certifique-se de que ativa o HTTP/3 em cada regra.

Desative o HTTP/3

1. Selecione o menu Negociação QUIC.
2. Para desativar explicitamente o HTTP/3 para esta interface, selecione Desativado.
3. Se tiver várias regras de front-end que representam IPv4 e IPv6, certifique-se de que desativa o HTTP/3 para cada regra.

gcloud: HTTPS

Antes de executar este comando, tem de criar um recurso de certificado SSL para cada certificado.

gcloud compute target-https-proxies create HTTPS_PROXY_NAME \
    --global \
    --quic-override=QUIC_SETTING

Substitua QUIC_SETTING por uma das seguintes opções:

• NONE (predefinição): permite que a Google controle quando o HTTP/3 é anunciado.

  Quando seleciona NONE, o HTTP/3 é anunciado aos clientes, mas o Google QUIC não é anunciado. Na Google Cloud consola, esta opção é denominada Automático (predefinição).

• ENABLE: anuncia o HTTP/3 aos clientes.

• DISABLE: não anuncia o HTTP/3 aos clientes.

API: HTTPS

POST https://www.googleapis.com/v1/compute/projects/PROJECT_ID/global/targetHttpsProxies/TARGET_PROXY_NAME/setQuicOverride

{
  "quicOverride": QUIC_SETTING
}

Substitua QUIC_SETTING por uma das seguintes opções:

• NONE (predefinição): permite que o Google controle quando o HTTP/3 é anunciado.

  Quando seleciona NONE, o HTTP/3 é anunciado aos clientes, mas o Google QUIC não é anunciado. Na Google Cloud consola, esta opção é denominada Automático (predefinição).

• ENABLE: anuncia HTTP/3 e Google QUIC aos clientes.

• DISABLE: não anuncia HTTP/3 nem Google QUIC aos clientes.

Suporte do WebSocket

Google Cloud Os balanceadores de carga baseados em HTTP(S) suportam o protocolo WebSocket quando usa HTTP ou HTTPS como protocolo para o back-end. O equilibrador de carga não requer qualquer configuração para usar proxy de ligações WebSocket.

O protocolo WebSocket fornece um canal de comunicação full duplex entre os clientes e o balanceador de carga. Para mais informações, consulte o RFC 6455.

O protocolo WebSocket funciona da seguinte forma:

1. O balanceador de carga reconhece um pedido de websocket Upgrade de um cliente HTTP ou HTTPS. O pedido contém os cabeçalhos Connection: Upgrade e Upgrade: websocket, seguidos de outros cabeçalhos de pedidos relacionados com o websocket relevantes.
2. O back-end envia uma resposta Upgrade do WebSocket. A instância de back-end envia uma resposta 101 switching protocol com os cabeçalhos Connection: Upgrade e Upgrade: websocket e outros cabeçalhos de resposta relacionados com o WebSocket.
3. O balanceador de carga encaminha o tráfego bidirecional durante a ligação atual.

Se a instância de back-end devolver um código de estado 426 ou 502, o balanceador de carga fecha a ligação.

Os limites de tempo da ligação WebSocket dependem do tipo de balanceador de carga (global, regional ou clássico). Para ver detalhes, consulte o artigo Limite de tempo do serviço de back-end.

A afinidade de sessão para websockets funciona da mesma forma que para qualquer outro pedido. Para mais informações, consulte o artigo Afinidade de sessões.

Compatibilidade com gRPC

O gRPC é uma framework de código aberto para chamadas de procedimento remoto. Baseia-se na norma HTTP/2. Seguem-se alguns exemplos de utilização do gRPC:

• Sistemas distribuídos de baixa latência e altamente escaláveis
• Desenvolver clientes para dispositivos móveis que comunicam com um servidor na nuvem
• Conceber novos protocolos que têm de ser precisos, eficientes e independentes do idioma
• Design em camadas para permitir a extensão, a autenticação e o registo

Para usar o gRPC com as suas Google Cloud aplicações, tem de encaminhar os pedidos de extremo a extremo através de HTTP/2. Para o fazer, crie um balanceador de carga da aplicação com uma das seguintes configurações:

• Para tráfego não encriptado ponto a ponto (sem TLS): cria um balanceador de carga HTTP (configurado com um proxy HTTP de destino). Além disso, configura o balanceador de carga para usar o HTTP/2 para ligações não encriptadas entre o balanceador de carga e os respetivos back-ends definindo o protocolo do serviço de back-end como H2C.

• Para tráfego encriptado ponto a ponto (com TLS): cria um balanceador de carga HTTPS (configurado com um proxy HTTPS de destino e um certificado SSL). O equilibrador de carga negoceia o HTTP/2 com os clientes como parte do handshake SSL através da extensão TLS ALPN.

  Além disso, tem de se certificar de que os backends conseguem processar o tráfego TLS e configurar o balanceador de carga para usar o HTTP/2 para ligações encriptadas entre o balanceador de carga e os respetivos backends, definindo o protocolo do serviço de backend como HTTP2.

  O balanceador de carga ainda pode negociar HTTPS com alguns clientes ou aceitar pedidos HTTP não seguros num balanceador de carga configurado para usar HTTP/2 entre o balanceador de carga e as instâncias de back-end. Esses pedidos HTTP ou HTTPS são transformados pelo equilibrador de carga para encaminhar os pedidos através de HTTP/2 para as instâncias de back-end.

Se quiser configurar um balanceador de carga de aplicações através de HTTP/2 com a entrada do Google Kubernetes Engine ou através de gRPC e HTTP/2 com a entrada, consulte o artigo HTTP/2 para o balanceamento de carga com a entrada.

Se quiser configurar um Application Load Balancer externo através do HTTP/2 com o Cloud Run, consulte o artigo Use HTTP/2 behind a load balancer (Use o HTTP/2 atrás de um balanceador de carga).

Para obter informações sobre a resolução de problemas com o HTTP/2, consulte o artigo Resolva problemas com o HTTP/2 nos back-ends.

Para obter informações sobre as limitações do HTTP/2, consulte o artigo Limitações do HTTP/2.

Suporte de TLS

Por predefinição, um proxy de destino HTTPS aceita apenas TLS 1.0, 1.1, 1.2 e 1.3 quando termina pedidos SSL de clientes.

Quando o balanceador de carga de aplicações externo global ou o balanceador de carga de aplicações externo regional usam HTTPS como o protocolo do serviço de back-end, podem negociar TLS 1.2 ou 1.3 para o back-end.

Quando o Application Load Balancer clássico usa HTTPS como o protocolo de serviço de back-end, pode negociar TLS 1.0, 1.1, 1.2 ou 1.3 para o back-end.

Suporte de TLS mútuo

O TLS mútuo, ou mTLS, é um protocolo da norma da indústria para a autenticação mútua entre um cliente e um servidor. O mTLS ajuda a garantir que o cliente e o servidor se autenticam entre si, verificando se cada um tem um certificado válido emitido por uma autoridade de certificação (AC) fidedigna. Ao contrário do TLS padrão, em que apenas o servidor é autenticado, o mTLS requer que o cliente e o servidor apresentem certificados, confirmando as identidades de ambas as partes antes de a comunicação ser estabelecida.

Todos os balanceadores de carga de aplicações suportam mTLS. Com o mTLS, o equilibrador de carga pede ao cliente que envie um certificado para se autenticar durante o handshake TLS com o equilibrador de carga. Pode configurar um arquivo de confiança do gestor de certificados que o equilibrador de carga usa para validar a cadeia de confiança do certificado de cliente.

Para mais informações sobre o mTLS, consulte o artigo Autenticação TLS mútua.

Suporte de dados iniciais do TLS 1.3

Nota: o TLS 1.3 Early Data ou o 0-RTT só é suportado para retomar sessões anteriores entre os clientes e a RFC ou o balanceador de carga. O CDN na nuvem ou o equilibrador de carga não podem usar dados iniciais do TLS ao encaminhar pedidos para os servidores de origem.

Os dados antecipados do TLS 1.3 são suportados no proxy HTTPS de destino dos seguintes balanceadores de carga de aplicações externos para HTTPS sobre TCP (HTTP/1.1, HTTP/2) e HTTP/3 sobre QUIC:

• Balanceadores de carga de aplicações externos globais
• Balanceadores de carga de aplicações clássicos

O TLS 1.3 foi definido na RFC 8446 e introduz o conceito de dados iniciais, também conhecidos como dados de tempo de ida e volta zero (0-RTT), que podem melhorar o desempenho da aplicação para ligações retomadas em 30 a 50%.

Com o TLS 1.2, são necessários dois processos de ida e volta antes de os dados poderem ser transmitidos em segurança. O TLS 1.3 reduz este processo a uma viagem de ida e volta (1-RTT) para novas ligações, o que permite aos clientes enviar dados da aplicação imediatamente após a primeira resposta do servidor. Além disso, o TLS 1.3 introduz o conceito de dados iniciais para sessões retomadas, o que permite aos clientes enviar dados de aplicações com o ClientHello inicial, reduzindo assim o tempo de resposta efetivo para zero (0-RTT). O TLS 1.3 early data permite que o servidor de back-end comece a processar os dados do cliente antes de o processo de handshake com o cliente estar concluído, reduzindo assim a latência. No entanto, é preciso ter cuidado para mitigar os riscos de repetição.

Uma vez que os dados iniciais são enviados antes de o handshake estar concluído, um atacante pode tentar capturar e repetir pedidos. Para mitigar esta situação, o servidor de back-end tem de controlar cuidadosamente a utilização de dados antecipada, limitando a respetiva utilização a pedidos idempotentes. Os métodos HTTP destinados a ser idempotentes, mas que podem acionar alterações não idempotentes, como um pedido GET que modifica uma base de dados, não podem aceitar dados antecipados. Nestes casos, o servidor de back-end tem de rejeitar pedidos com o cabeçalho HTTP Early-Data: 1 devolvendo um código de estado HTTP 425 Too Early.

Os pedidos com dados antecipados têm o cabeçalho HTTP Early-Data definido com o valor 1, o que indica ao servidor de back-end que o pedido foi transmitido em dados antecipados do TLS. Também indica que o cliente compreende o código de estado 425 Too EarlyHTTP.

Modos de dados iniciais do TLS (0-RTT)

Pode configurar os dados antecipados do TLS através de um dos seguintes modos no recurso de proxy HTTPS de destino do equilibrador de carga.

• STRICT. Isto ativa o TLS 1.3 Early Data para pedidos com métodos HTTP seguros (GET, HEAD, OPTIONS, TRACE) e pedidos HTTP que não têm parâmetros de consulta. Os pedidos que enviam dados antecipados que contêm métodos HTTP não idempotentes (como POST ou PUT) ou com parâmetros de consulta são rejeitados com um código de estado HTTP 425.

• PERMISSIVE. Isto ativa o TLS 1.3 Early Data para pedidos com métodos HTTP seguros (GET, HEAD, OPTIONS, TRACE). Este modo não nega pedidos que incluam parâmetros de consulta. O proprietário da aplicação tem de garantir que os dados iniciais são seguros para utilização em cada caminho de pedido, especialmente para pontos finais em que a repetição de pedidos pode causar efeitos secundários não intencionais, como atualizações de registo ou de base de dados acionadas por pedidos GET.

• DISABLED. O TLS 1.3 Early Data não é anunciado e quaisquer tentativas (inválidas) de enviar dados iniciais são rejeitadas. Se as suas aplicações não estiverem equipadas para processar pedidos de dados antecipados em segurança, tem de desativar os dados antecipados. O TLS 1.3 Early Data está desativado por predefinição.

• UNRESTRICTED (não recomendado para a maioria das cargas de trabalho). Isto ativa os dados antecipados do TLS 1.3 para pedidos com qualquer método HTTP, incluindo métodos não idempotentes, como POST. Este modo não aplica outras limitações. Este modo pode ser valioso para exemplos de utilização de gRPC. No entanto, não recomendamos este método, a menos que tenha avaliado a sua postura de segurança e mitigado o risco de ataques de repetição através de outros mecanismos.

Configure os dados antecipados do TLS

Para ativar ou desativar explicitamente os dados antecipados do TLS, faça o seguinte:

Consola

1. Na Google Cloud consola, aceda à página Equilíbrio de carga.

   Aceda a Balanceamento de carga

2. Selecione o equilibrador de carga para o qual tem de ativar os dados antecipados.

3. Clique em Editar.

4. Clique em Configuração do front-end.

5. Selecione o endereço IP e a porta do front-end que quer editar. Para ativar os dados antecipados do TLS, o protocolo tem de ser HTTPS.

6. Na lista Dados antecipados (0-RTT), selecione um modo de dados antecipados do TLS.

7. Clique em Concluído.

8. Para atualizar o balanceador de carga, clique em Atualizar.

gcloud

1. Configure o modo de dados antecipados do TLS no proxy HTTPS de destino de um balanceador de carga de aplicações.

   gcloud compute target-https-proxies update TARGET_HTTPS_PROXY \
     --tls-early-data=TLS_EARLY_DATA_MODE
   

   Substitua o seguinte:

   • TARGET_HTTPS_PROXY: o proxy HTTPS de destino do seu balanceador de carga
   • TLS_EARLY_DATA_MODE: STRICT, PERMISSIVE, DISABLED ou UNRESTRICTED

API

PATCH https://compute.googleapis.com/compute/v1/projects/{project}/global/targetHttpsProxies/TARGET_HTTPS_PROXY
{
    "tlsEarlyData":"TLS_EARLY_DATA_MODE",
    "fingerprint": "FINGERPRINT"
}

Substitua o seguinte:

• TARGET_HTTPS_PROXY: o proxy HTTPS de destino do seu balanceador de carga
• TLS_EARLY_DATA_MODE: STRICT, PERMISSIVE, DISABLED ou UNRESTRICTED
• FINGERPRINT: uma string codificada em Base64. Tem de fornecer uma impressão digital atualizada para aplicar patches ao proxy HTTPS de destino; caso contrário, o pedido falha com um código de estado HTTP 412 Precondition Failed.

Depois de configurar os dados antecipados do TLS, pode emitir pedidos a partir de um cliente HTTP que suporte dados antecipados do TLS. Pode observar uma latência mais baixa para pedidos retomados.

Se um cliente não compatível com a RFC enviar um pedido com um método não idempotente ou com parâmetros de consulta, o pedido é recusado. Vê um código de estado HTTP 425 Early nos registos do balanceador de carga e a seguinte resposta HTTP:

  HTTP/1.1 425 Too Early
  Content-Type: text/html; charset=UTF-8
  Referrer-Policy: no-referrer
  Content-Length: 1558
  Date: Thu, 03 Aug 2024 02:45:14 GMT
  Connection: close
  <!DOCTYPE html>
  <html lang=en>
  <title>Error 425 (Too Early)</title>
  <p>The request was sent to the server too early, please retry. That's
  all we know.</p>
  </html>
  

Limitações

• Os balanceadores de carga HTTPS não enviam um alerta de encerramento close_notify quando terminam as ligações SSL. Ou seja, o balanceador de carga fecha a ligação TCP em vez de realizar um encerramento SSL.

• Os equilibradores de carga HTTPS suportam apenas carateres em minúsculas em domínios num atributo de nome comum (CN) ou num atributo de nome alternativo do assunto (SAN) do certificado. Os certificados com carateres maiúsculos nos domínios só são devolvidos quando definidos como o certificado principal no proxy de destino.

• Os balanceadores de carga HTTPS não usam a extensão Indicação do nome do servidor (SNI) quando se ligam ao back-end, exceto para balanceadores de carga com back-ends de NEG da Internet. Para mais informações, consulte o artigo Encriptação do equilibrador de carga para os servidores de back-end.

• Google Cloud não garante que uma ligação TCP subjacente possa permanecer aberta durante todo o valor do limite de tempo do serviço de back-end. Os sistemas cliente têm de implementar uma lógica de repetição em vez de dependerem de uma ligação TCP para estarem abertos durante longos períodos.

• Quando cria um Application Load Balancer externo regional no nível Premium através daGoogle Cloud consola, apenas as regiões que suportam o nível Standard estão disponíveis na Google Cloud consola. Para aceder a outras regiões, use a CLI gcloud ou a API.

• Os proxies GFE usados pelos equilibradores de carga de aplicações globais e clássicos não suportam respostas antecipadas 200 OK que são enviadas antes de o payload POST do pedido ter sido totalmente encaminhado por proxy para o back-end. O envio de uma resposta 200 OK antecipada faz com que o GFE feche a ligação ao back-end.

  O seu back-end tem de responder com 100 Continue respostas depois de receber os cabeçalhos do pedido e, em seguida, aguardar até que a carga útil POST do pedido seja totalmente encaminhada por proxy antes de responder com o código de resposta 200 OK final.

• Quando usar balanceadores de carga de aplicações externos regionais com o Cloud Run num ambiente de VPC partilhada, as redes VPC autónomas nos projetos de serviço podem enviar tráfego para quaisquer outros serviços do Cloud Run implementados em quaisquer outros projetos de serviço no mesmo ambiente de VPC partilhada. Este é um problema conhecido.

• O Cloud CDN permite-lhe forçar a ignorância de um objeto ou um conjunto de objetos pela cache pedindo uma invalidação da cache. Quando usa um Application Load Balancer externo global com referência de serviço entre projetos da VPC partilhada, por predefinição, os administradores do projeto de serviço não têm as autorizações necessárias para pedir invalidações da cache. Isto deve-se ao facto de a invalidação da cache estar configurada no projeto de front-end (ou seja, o projeto que tem a regra de encaminhamento, o proxy de destino e o mapa de URLs do equilibrador de carga). Assim, as invalidações da cache só podem ser emitidas por diretores que tenham as funções do IAM para configurar recursos relacionados com o equilibrador de carga nos projetos de front-end (por exemplo, a função de administrador de rede de computação). Os administradores de serviços, que controlam o aprovisionamento dos serviços de back-end num projeto separado, têm de trabalhar com o administrador do balanceador de carga do projeto de front-end para emitir a invalidação da cache para os respetivos serviços entre projetos.

O que se segue?

• Para saber como os balanceadores de carga de aplicações externos processam as ligações, encaminham o tráfego e mantêm a afinidade de sessão, consulte o artigo Distribuição de pedidos para balanceadores de carga de aplicações externos.

• Para saber como implementar um Application Load Balancer externo global, consulte o artigo Configurar um Application Load Balancer externo com um back-end do Compute Engine.

• Para saber como implementar um Application Load Balancer externo regional, consulte o artigo Configurar um Application Load Balancer externo regional com um back-end do Compute Engine.

• Se for um utilizador existente do Application Load Balancer clássico, certifique-se de que revê a vista geral da migração quando planear uma nova implementação com o Application Load Balancer externo global.

• Para saber como automatizar a configuração do balanceador de carga de aplicações externo com o Terraform, consulte os exemplos de módulos Terraform para balanceadores de carga de aplicações externos.

• Para saber como configurar as capacidades avançadas de gestão de tráfego disponíveis com o balanceador de carga de aplicações externo global, consulte o artigo Vista geral da gestão de tráfego para balanceadores de carga de aplicações externos globais.

• Para saber como configurar as capacidades de gestão de tráfego avançadas disponíveis com o balanceador de carga de aplicações externo regional, consulte a vista geral da gestão de tráfego para balanceadores de carga de aplicações externos regionais.

• Para saber mais sobre a publicação de Websites, consulte o artigo Publicar Websites.

• Para encontrar as localizações dos PoPs da Google, consulte as localizações da GFE.

• Para saber mais sobre a gestão da capacidade, consulte o tutorial de gestão da capacidade com equilíbrio de carga e as otimizações da capacidade das aplicações com equilíbrio de carga global.

• Para saber como usar o Gestor de certificados para aprovisionar e gerir certificados SSL, consulte a vista geral do Gestor de certificados.

• Para inserir lógica personalizada no caminho de dados do equilíbrio de carga, configure plug-ins ou chamadas de extensões de serviço.

• Apenas para equilibradores de carga de aplicações externos regionais, pode experimentar usar a Apigee Shadow API Discovery para encontrar APIs shadow (também conhecidas como APIs não documentadas) na sua Google Cloud infraestrutura existente. Certifique-se de que lê as limitações associadas antes de ativar a deteção de APIs fantasma.