Visão geral do balanceador de carga de aplicativo externo

Neste documento, apresentamos os conceitos necessários para configurar um balanceador de carga de aplicativo externo.

O balanceador de carga de aplicativo externo é um balanceador de carga de camada 7 baseado em proxy que permite executar e escalonar seus serviços atrás de um único endereço IP externo. O balanceador de carga de aplicativo externo distribui o tráfego HTTP e HTTPS para back-ends hospedados em várias plataformas doGoogle Cloud , como Compute Engine, Google Kubernetes Engine (GKE) e Cloud Storage, bem como back-ends externos conectados pela Internet ou por conectividade híbrida. Para detalhes, consulte Visão geral do balanceador de carga de aplicativo: casos de uso.

Modos de operação

É possível configurar um balanceador de carga de aplicativo externo nos seguintes modos:

• Balanceador de carga de aplicativo externo global. Esse é um balanceador de carga global que é implementado como um serviço gerenciado no Google Front Ends (GFEs). Ele usa o proxy Envoy de código aberto para oferecer suporte a recursos avançados de gerenciamento de tráfego, como espelhamento de tráfego, divisão de tráfego baseada em peso e transformações de cabeçalho com base em solicitação ou resposta.

• Balanceador de carga de aplicativo clássico. Este é o balanceador de carga de aplicativo externo clássico que é global no nível Premium, mas pode ser configurado para ser regional no nível Standard. Esse balanceador de carga é implementado no Google Front Ends (GFEs). Os GFEs são distribuídos globalmente e funcionam em conjunto usando a rede global e o plano de controle do Google.

• Balanceador de carga de aplicativo externo regional. Esse é um balanceador de carga regional implementado como um serviço gerenciado no proxy Envoy de código aberto. Ele inclui recursos de gerenciamento de tráfego avançado, como espelhamento de tráfego, divisão de tráfego baseada em peso e transformações de cabeçalho com base em solicitação ou resposta.

Modo balanceador de carga	Casos de uso recomendados	Recursos
Balanceador de carga de aplicativo externo global	Use esse balanceador de carga para cargas de trabalho HTTP(S) externas com usuários dispersos globalmente ou serviços de back-end em várias regiões.	Compatível com o GKE usando o gateway (totalmente orquestrado) ou NEGs independentes (orquestração manual). Suporta gerenciamento de tráfego avançado Endereços IP externos Anycast globais no nível Premium Pode acessar back-ends em várias regiões Compatível com Cloud CDN. Compatível com o Cloud Armor
Balanceador de carga de aplicativo clássico	Esse balanceador de carga é global no nível Premium. No nível do serviço de rede Premium, esse balanceador de carga oferece balanceamento de carga multirregional, tenta redirecionar o tráfego para o back-end íntegro mais próximo que tiver capacidade e encerra o tráfego HTTP(S) o mais próximo possível dos usuários. Para detalhes sobre o processo de distribuição de solicitações, consulte Distribuição de tráfego. No nível de serviço de rede padrão, esse balanceador de carga pode distribuir tráfego apenas para back-ends em uma única região.	Compatível com o GKE usando o Gateway (totalmente orquestrado), Entrada (totalmente orquestrada) ou NEGs independentes (orquestração manual). Compatível com o Google Cloud Armor Menos recursos de roteamento de tráfego Consulte a página de Recursos do balanceamento de carga para ver a lista completa de recursos.
Balanceador de carga de aplicativo externo regional	Esse balanceador de carga contém muitos dos recursos do balanceador de carga de aplicativo clássico atual, além de recursos de gerenciamento de tráfego avançado. Use este balanceador de carga se quiser veicular conteúdo de apenas uma geolocalização (por exemplo, para atender a regulamentações de conformidade). Este balanceador de carga pode ser configurado no nível Premium ou Standard.	Compatível com o GKE usando NEGs independentes (orquestração manual). Compatível com recursos avançados de gerenciamento de tráfego VIPs regionais usando o nível Padrão de rede Encerra o TLS em uma única região que você configura Veicula conteúdo somente da região configurada Para ver a lista completa, consulte Recursos de balanceamento de carga.

Identificar o modo

Console

1. No console do Google Cloud , acesse a página Balanceamento de carga.

   Acessar o "Balanceamento de carga"

2. Na guia Balanceadores de carga, você verá o protocolo, a região e o tipo de balanceador. Se a região estiver em branco, o balanceador de carga será global. Confira na tabela a seguir como identificar o modo do balanceador de carga.

Modo balanceador de carga	Tipo do balanceador de carga	Tipo de acesso	Região
Balanceador de carga de aplicativo externo global	legado	Externos
Balanceador de carga de aplicativo clássico	Aplicativo (clássico)	Externo
Balanceador de carga de aplicativo externo regional	legado	Externos	Especifica uma região

gcloud

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

   gcloud compute forwarding-rules describe FORWARDING_RULE_NAME
   

Na resposta ao comando, verifique o esquema de balanceamento de carga, a região e o nível da rede. Veja na tabela a seguir como identificar o modo do balanceador de carga.

Modo balanceador de carga	Esquema de balanceamento de carga	Regra de encaminhamento	Nível da rede
Balanceador de carga de aplicativo externo global	EXTERNAL_MANAGED	Global	Premium
Balanceador de carga de aplicativo clássico	EXTERNO	Global	Padrão ou Premium
Balanceador de carga de aplicativo externo regional	EXTERNAL_MANAGED	Especifica uma região	Padrão ou Premium

Importante: depois de criar um balanceador de carga, não é possível editar o modo. Em vez disso, é preciso excluir o balanceador de carga e criar um novo.

Arquitetura

Os seguintes recursos são necessários para uma implantação externa do balanceador de carga de aplicativo:

• Somente para balanceadores de carga de aplicativo regionais externos, uma sub-rede somente proxy é usada para enviar conexões do balanceador de carga para os back-ends.

• Uma regra de encaminhamento externo 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 se conectar ao balanceador de carga.

• Um proxy HTTP(S) de destino recebe uma solicitação do cliente. O proxy HTTP(S) avalia a solicitação usando o mapa de URL para tomar decisões de roteamento de tráfego. O proxy também pode autenticar comunicações usando certificados SSL.

  • Para o balanceamento de carga HTTPS, o proxy HTTPS de destino usa certificados SSL para provar sua identidade aos clientes. Um proxy HTTPS de destino é compatível com até o número documentado de certificados SSL.

• O proxy HTTP(S) usa um mapa de URL para determinar o roteamento com base em atributos HTTP, como o caminho da solicitação, cookies ou cabeçalhos. Com base na decisão de roteamento, o proxy encaminha as solicitações do cliente para serviços de back-end ou buckets de back-end específicos. O mapa de URL pode especificar outras ações, como enviar redirecionamentos a clientes.

• Um serviço de back-end distribui as solicitações para back-ends íntegros. Os balanceadores de carga de aplicativo externos globais também são compatíveis com buckets de back-end. Um ou mais back-ends precisam estar conectados ao serviço de back-end ou bucket de back-end.

• Uma verificação de integridade monitora periodicamente a prontidão dos back-ends. Isso reduz o risco de que solicitações sejam enviadas para back-ends que não possam atender à solicitação.

• Regras de firewall para que os back-ends aceitem sondagens de verificação de integridade. Os balanceadores de carga de aplicativo externos regionais exigem uma regra de firewall extra para permitir que o tráfego da sub-rede somente proxy atinja os back-ends.

Global

Este diagrama mostra os componentes de uma implantação do balanceador de carga de aplicativo externo global. Essa arquitetura se aplica ao balanceador de carga de aplicativo externo global e ao balanceador de carga de aplicativo clássico no nível Premium.

Componentes do balanceador de carga de aplicativo externo global (clique para ampliar).

Regional

Este diagrama mostra os componentes de uma implantação do balanceador de carga de aplicativo externo regional.

Componentes do balanceador de carga de aplicativo externo regional (clique para ampliar).

Sub-rede somente proxy

Sub-redes somente proxy são necessárias apenas para balanceadores de carga de aplicativo externos regionais.

A sub-rede somente proxy fornece um conjunto de endereços IP que o Google usa para executar proxies Envoy em seu nome. É necessário criar uma sub-rede somente proxy em cada região de uma rede VPC em que você usa balanceadores de carga de aplicativo externos regionais. A flag --purpose dessa sub-rede somente proxy está definida como REGIONAL_MANAGED_PROXY. Todos os balanceadores de carga regionais baseados em Envoy na mesma região e rede VPC compartilham um pool de proxies do Envoy da mesma sub-rede somente proxy. Além disso:

• As sub-redes somente proxy são usadas apenas para proxies Envoy, não para seus back-ends.
• As VMs de back-end ou os endpoints de todos os balanceadores de carga de aplicativo internos em uma região e uma rede VPC recebem conexões da sub-rede somente proxy.
• O endereço IP do balanceador de carga de aplicativo externo regional não está localizado na sub-rede somente proxy. O endereço IP do balanceador de carga é definido pela regra de encaminhamento gerenciada externa, descrita abaixo.
• As sub-redes somente proxy podem ser configuradas com um tipo de pilha IPV4_IPV6 ou IPV4_ONLY.

Se você já tiver criado uma sub-rede somente proxy com --purpose=INTERNAL_HTTPS_LOAD_BALANCER, migre a finalidade da sub-rede para REGIONAL_MANAGED_PROXY antes de criar outros balanceadores de carga baseados no Envoy na mesma região da rede VPC.

Regras de encaminhamento e endereços IP

Prévia — Os balanceadores de carga de aplicativo entre regiões, externos regionais e internos regionais podem encerrar o tráfego IPv6

Este recurso está sujeito aos Termos das Soluções Pré-GA na seção Termos Gerais de Serviço dos Termos Específicos de Serviço. Os recursos pré-GA estão disponíveis "no estado em que se encontram" e podem ter suporte limitado. Para mais informações, consulte as descrições da fase de lançamento.

As regras de encaminhamento roteiam o tráfego por endereço IP, porta e protocolo para uma configuração de balanceamento de carga que consiste em um proxy de destino, um mapa de URL e um ou mais serviços de back-end.

Especificação de endereço IP. Cada regra de encaminhamento fornece um endereço IP que pode ser usado nos registros DNS para seu aplicativo. Não é necessário nenhum balanceamento de carga baseado no DNS. É possível especificar o endereço IPv4 ou IPv6 a ser usado ou permitir que o Cloud Load Balancing atribua um para você.

Especificação da porta. Cada regra de encaminhamento para um balanceador de carga de aplicativo pode referenciar uma única porta de 1 a 65535. Para permitir várias portas, configure várias regras de encaminhamento. É possível configurar várias regras de encaminhamento para usar o mesmo endereço IP externo (VIP) e ter referência ao mesmo proxy HTTP(S) de destino, desde que a combinação geral do endereço IP, da porta e do protocolo sejam exclusivos para cada regra de encaminhamento. Dessa forma, é possível usar um único balanceador de carga com um mapa de URL compartilhado como um proxy para vários aplicativos.

O tipo de regra de encaminhamento, o endereço IP e o esquema de balanceamento de carga usado por balanceadores de carga de aplicativo externos depende do modo do balanceador de carga e de qual nível de serviço de rede o balanceador está.

Modo balanceador de carga	Nível de serviço de rede	Regra de encaminhamento, endereço IP e esquema de balanceamento de carga	Como rotear da Internet para o front-end do balanceador de carga
Balanceador de carga de aplicativo externo global	Nível Premium	Regra de encaminhamento externo global Endereço IP externo global Esquema de balanceamento de carga: EXTERNAL_MANAGED	Solicitações encaminhadas para o GFE mais próximo do cliente na Internet.
Balanceador de carga de aplicativo clássico	Nível Premium	Regra de encaminhamento externo global Endereço IP externo global Esquema de balanceamento de carga: EXTERNAL ^1	Solicitações encaminhadas 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	Solicitações encaminhadas para um GFE na região do balanceador de carga.
Balanceador de carga de aplicativo externo regional	Nível Premium ou Standard	Regra de encaminhamento externo regional Endereço IP externo regional Esquema de balanceamento de carga: EXTERNAL_MANAGED	As solicitações chegam ao Google Cloud no PoP mais próximo do cliente. As solicitações são encaminhadas pelo backbone premium do Google Cloud até chegarem aos proxies do Envoy na mesma região que o balanceador de carga.

¹ É possível anexar EXTERNAL_MANAGED serviços de back-end a EXTERNAL regras de encaminhamento. No entanto, os serviços de back-end EXTERNAL não podem ser anexados a regras de encaminhamento EXTERNAL_MANAGED. Para aproveitar os novos recursos disponíveis apenas com o balanceador de carga de aplicativo externo global, recomendamos migrar os recursos EXTERNAL atuais para EXTERNAL_MANAGED usando o processo de migração descrito em Migrar recursos do balanceador de carga de aplicativo clássico para o externo global.

Confira a lista completa de protocolos compatíveis com as regras de encaminhamento do balanceador de carga de aplicativo em cada modo em Recursos do balanceador de carga.

Regras de encaminhamento e redes VPC

Esta seção descreve como as regras de encaminhamento usadas por balanceadores de carga de aplicativo externos são associadas às redes VPC.

Modo balanceador de carga	Associação de rede VPC
Balanceador de carga de aplicativo externo global Balanceador de carga de aplicativo clássico	Nenhuma rede VPC associada. A regra de encaminhamento sempre usa um endereço IP que está fora da rede VPC. Portanto, a regra de encaminhamento não tem uma rede VPC associada.
Balanceador de carga de aplicativo externo regional	A rede VPC da regra de encaminhamento é a rede em que a sub-rede somente proxy foi criada. Você especifica a rede ao criar a regra de encaminhamento. Dependendo de você usar um endereço IPv4 ou um intervalo de endereços IPv6, sempre há uma rede VPC explícita ou implícita associada à regra de encaminhamento. Os endereços IPv4 externos regionais sempre existem fora das redes VPC. No entanto, ao criar a regra de encaminhamento, é necessário especificar a rede VPC em que a sub-rede somente proxy foi criada. Portanto, a regra de encaminhamento tem uma associação de rede explícita. Os intervalos de endereços IPv6 externos regionais sempre existem dentro de uma rede VPC. Ao criar a regra de encaminhamento, é necessário especificar a sub-rede de onde o intervalo de endereços IP é retirado. Essa sub-rede precisa estar na mesma região e rede VPC em que uma sub-rede somente proxy foi criada. Assim, há uma associação de rede implícita. Requisitos de rede e sub-rede. Para tráfego IPv6, sua rede e sub-redes precisam atender aos seguintes requisitos de configuração: Rede VPC: use uma rede VPC de modo personalizado configurada com a flag --enable-ula-internal-ipv6. Sub-rede da regra de encaminhamento: precisa ser uma sub-rede de pilha dupla (IPv4_IPv6) ou IPV6_ONLY com ipv6-access-type definido como EXTERNAL. Opções de alocação de endereços IPv6. A regra de encaminhamento precisa fazer referência a um intervalo /96 de endereços IPv6 do intervalo de endereços IPv6 externos /64 da sub-rede. Limitações. Para especificar um endereço IPv6 efêmero personalizado, use a Google Cloud CLI ou a API. O console do Google Cloud não é compatível com a especificação de endereços IPv6 temporários personalizados para regras de encaminhamento.

Proxies de destino

Os proxies de destino encerram as conexões HTTP(S) dos clientes. Uma ou mais regras de encaminhamento direcionam o tráfego para o proxy de destino, que consulta o mapa de URL para determinar como rotear o tráfego para os back-ends.

Não confie no proxy para preservar as letras maiúsculas e minúsculas dos nomes de cabeçalho de solicitação ou cabeçalho de resposta. Por exemplo, um cabeçalho de resposta Server: Apache/1.0 pode aparecer no cliente como server: Apache/1.0.

Observação: para grupos de endpoints de rede (NEGs, na sigla em inglês) da Internet, as solicitações do balanceador de carga vêm de diferentes intervalos de IPs, dependendo do tipo de NEG (global ou regional) ). Para mais informações, consulte Como autenticar solicitações.

A tabela a seguir especifica o tipo de proxy de destino exigido pelos balanceadores de carga de aplicativo externos.

Modo balanceador de carga	Tipos de proxy de destino	Cabeçalhos adicionados pelo proxy	Cabeçalhos personalizados compatíveis
Balanceador de carga de aplicativo externo global	HTTP global, HTTPS global	Os proxies definem os cabeçalhos de solicitação/resposta HTTP da seguinte maneira: Via: 1.1 google (solicitações e respostas) X-Forwarded-Proto: [http] https] (apenas solicitações) X-Forwarded-For: [<fornecido-valor>],<cliente-ip>,<load-balancer-ip> (consulte Cabeçalho X-Forwarded-For) (somente solicitações) Os proxies também definem o cabeçalho X-Cloud-Trace-Context se ele ainda não estiver presente.	Configurado no serviço de back-end ou bucket de back-end Sem suporte ao Cloud CDN
Balanceador de carga de aplicativo clássico	HTTP global, HTTPS global	Os proxies definem cabeçalhos de solicitação/resposta HTTP da seguinte maneira: Via: 1.1 google (solicitações e respostas) X-Forwarded-Proto: [http] https] (apenas solicitações) X-Forwarded-For: [<fornecido-valor>],<cliente-ip>,<load-balancer-ip> (consulte Cabeçalho X-Forwarded-For) (somente solicitações) Os proxies também definem o cabeçalho X-Cloud-Trace-Context se ele ainda não estiver presente.	Configurado no serviço de back-end ou bucket de back-end
Balanceador de carga de aplicativo externo regional	HTTP regional, HTTPS regional	X-Forwarded-Proto: [http] https] (apenas solicitações) Via: 1.1 google (solicitações e respostas) X-Forwarded-For: [<supplied-value>,]<client-ip>,<load-balancer-ip> (consulte Cabeçalho X-Forwarded-For) (somente solicitações)	Configurado no mapa de URL

Observação :de acordo com a RFC 2616, os seguintes cabeçalhos de salto por 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 maneiras:

• Para o balanceador de carga de aplicativo externo global, os cabeçalhos de resposta e solicitação podem ser convertidos em letras minúsculas.

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

• Para o balanceador de carga de aplicativo clássico, os cabeçalhos de solicitação e cabeçalhos de resposta são convertidos em letras minúsculas, exceto quando você usa HTTP/1.1. No HTTP/1.1, os cabeçalhos são inseridos corretamente. A primeira letra da chave do cabeçalho e todas as letras após um hífen (-) são exibidas em maiúsculas para preservar a compatibilidade com clientes HTTP/1.1. Por exemplo, user-agent é alterado para User-Agent e content-encoding é alterado para Content-Encoding.

• Alguns cabeçalhos são agrupados. Quando houver várias instâncias da mesma chave de cabeçalho (por exemplo, Via), o balanceador de carga combinará os valores delas em uma lista separada por vírgulas para uma chave de cabeçalho. Serão agrupados somente cabeçalhos com valores que possam ser representados como uma lista separada por vírgulas. Outros cabeçalhos, como Set-Cookie, nunca são agrupados.

Cabeçalho Host

Quando o balanceador de carga faz a solicitação HTTP, o balanceador de carga preserva o cabeçalho Host da solicitação 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 conecta ao balanceador de carga
2. O endereço IP da regra de encaminhamento do balanceador de carga

Se a solicitação recebida não incluir um cabeçalho X-Forwarded-For, o cabeçalho resultante será o seguinte:

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

Se a solicitação recebida já incluir um cabeçalho X-Forwarded-For, o balanceador de carga vai anexar os valores dele ao cabeçalho atual:

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

Atenção :o balanceador de carga não verifica endereços IP que precedem <client-ip>,<load-balancer-ip> neste cabeçalho. Os endereços IP anteriores podem conter outros caracteres, incluindo espaços.

Remover valores de cabeçalho usando um cabeçalho de solicitação personalizado

É possível remover valores de cabeçalho usando cabeçalhos de solicitação personalizados no serviço de back-end. O exemplo a seguir 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. Essa configuração substitui o cabeçalho X-Forwarded-For de entrada apenas pelo endereço IP do cliente e do balanceador de carga.

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

Observação: essa abordagem descarta todos os valores X-Forwarded-For da solicitação. Como o Google Cloud não registra valores de cabeçalho, esses valores não podem ser recuperados. Se você precisar manter o conteúdo do cabeçalho original, armazene-o em um cabeçalho personalizado separado.

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

Se os back-ends do balanceador de carga executarem um software de proxy reverso HTTP, ele poderá 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 conectou ao back-end. Os intervalos de proxy do GFE estão listados no documento Regras de firewall.

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

Como resultado, um sistema upstream pode ver um cabeçalho X-Forwarded-For estruturado da seguinte maneira:

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

Suporte do Cloud Trace

O Trace não é compatível com balanceadores de carga de aplicativo. Os balanceadores de carga de aplicativo globais e clássicos adicionam o cabeçalho X-Cloud-Trace-Context se ele não estiver presente. O balanceador de carga de aplicativo externo regional não adiciona esse cabeçalho. Se o cabeçalho X-Cloud-Trace-Context já estiver presente, ele vai passar pelos balanceadores de carga sem modificações. No entanto, nenhum rastreamento ou intervalo é exportado pelo balanceador de carga.

Mapas de URL

Os mapas de URL definem os padrões de correspondência do roteamento de solicitações baseado em URL aos serviços de back-end apropriados. O mapa de URL permite dividir o tráfego examinando os componentes do URL para enviar solicitações a diferentes conjuntos de back-ends. Um serviço padrão é definido para processar todas as solicitações que não correspondem a uma regra de host ou de correspondência de caminho especificada.

Em algumas situações, como no exemplo de balanceamento de carga multirregional, talvez você não defina nenhuma regra de URL e dependa apenas do serviço padrão.

Os mapas de URL são compatíveis com vários recursos avançados de gerenciamento de tráfego, como direcionamento de tráfego baseado em cabeçalho, divisão de tráfego baseado em peso e espelhamento de solicitação. Para ver mais informações, consulte os seguintes tópicos:

• Visão geral do gerenciamento de tráfego para balanceador de carga de aplicativo externo global

• Visão geral do gerenciamento de tráfego para balanceador de carga de aplicativo externo regional

A tabela a seguir especifica o tipo de mapa de URL exigido pelos balanceadores de carga de aplicativo externos em cada modo.

Modo balanceador de carga	Tipo de mapa de URL
Balanceador de carga de aplicativo externo global	Global
Balanceador de carga de aplicativo clássico	Global (com apenas um subconjunto de recursos compatíveis)
Balanceador de carga de aplicativo externo regional	Regional

Certificados SSL

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

• OGoogle 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 uma descrição de cada configuração, consulte Métodos de configuração de certificado nas informações gerais dos certificados SSL.

• OGoogle Cloud oferece dois tipos de certificado: autogerenciados e gerenciados pelo Google. Para conferir uma descrição de cada tipo, consulte Tipos de certificado nas informações gerais de certificados SSL.

O tipo de balanceador de carga de aplicativo externo (global, regional ou clássico) determina quais métodos de configuração e tipos de certificado são compatíveis. Para mais detalhes, consulte Certificados e balanceadores de carga do Google Cloud nas informações gerais dos certificados SSL.

Políticas de SSL

As políticas de SSL especificam o conjunto de recursos de SSL que os balanceadores de carga do Google Cloud usam ao negociar SSL com clientes.

Por padrão, o balanceamento de carga HTTPS usa um conjunto de recursos SSL que oferece boa segurança e ampla compatibilidade. Alguns aplicativos exigem mais controle sobre quais versões de SSL e criptografias são usadas nas próprias conexões HTTPS ou SSL. É possível definir uma política de SSL para especificar o conjunto de recursos de SSL que o balanceador de carga usa ao negociar SSL com clientes. Além disso, é possível aplicar essa política de SSL ao proxy HTTPS de destino.

A tabela a seguir especifica o suporte da política de SSL com balanceadores de carga em cada modo.

Modo balanceador de carga	Políticas de SSL suportadas
Balanceador de carga de aplicativo externo global
Balanceador de carga de aplicativo clássico
Balanceador de carga de aplicativo externo regional

Serviços de back-end

Um serviço de back-end fornece informações de configuração ao balanceador de carga para que ele possa direcionar solicitações aos back-ends, por exemplo, grupos de instâncias do Compute Engine ou grupos de endpoints de rede (NEGs). Para mais informações sobre os serviços de back-end, consulte Visão geral dos serviços de back-end.

Para 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 Como configurar um balanceador de carga de aplicativo externo com um back-end do Compute Engine.

Escopo do serviço de back-end

A tabela a seguir indica qual recurso e escopo de serviço de back-end é usado por balanceadores de carga de aplicativo externos:

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

Protocolo para os back-ends

Os serviços de back-end para balanceadores de carga de aplicativo precisam usar um dos seguintes protocolos para enviar solicitações aos back-ends:

• HTTP, que usa HTTP/1.1 e nenhum TLS
• HTTPS, que usa HTTP/1.1 e TLS
• HTTP/2, que usa HTTP/2 e TLS. Não há suporte para HTTP/2 sem criptografia.
• H2C, que usa HTTP/2 sobre TCP. O TLS não é obrigatório. O H2C não é compatível com balanceadores de carga de aplicativo clássicos.

O balanceador de carga usa apenas o protocolo de serviço de back-end que você especifica para se comunicar com os back-ends. O balanceador de carga não vai usar um protocolo diferente se não conseguir se comunicar com os back-ends usando o protocolo de serviço de back-end especificado.

O protocolo do serviço de back-end não precisa corresponder ao protocolo usado pelos clientes para se comunicar com o balanceador de carga. Por exemplo, os clientes podem enviar solicitações para o balanceador de carga usando HTTP/2, mas o balanceador de carga pode se comunicar com back-ends usando HTTP/1.1 (HTTP ou HTTPS).

Buckets de back-end

Os buckets de back-end direcionam o tráfego recebido para os buckets do Cloud Storage. Para ver um exemplo de como adicionar um bucket a um balanceador de carga de aplicativo externo, consulte Como configurar um balanceador de carga com buckets de back-end. Para informações gerais sobre o Cloud Storage, consulte O que é o Cloud Storage?

Back-ends

A tabela a seguir especifica os back-ends e os recursos relacionados compatíveis com balanceadores de carga de aplicativo externos em cada modo.

Modo balanceador de carga	Back-ends compatíveis em um serviço de back-end^1						Compatível com buckets de back-end	Compatível com o Cloud Armor	Compatível com o Cloud CDN^2	Compatível com o IAP^2	Compatível com extensões de serviço
	Grupos de instâncias^3	NEGs por zona^4	NEGs na Internet	NEGs sem servidor	NEGs híbridos	NEGs do Private Service Connect
Balanceador de carga de aplicativo externo global
Balanceador de carga de aplicativo clássico									Nível Premium
Balanceador de carga de aplicativo externo regional

¹Os back-ends em um serviço de back-end precisam ser do mesmo tipo: todos os grupos de instâncias ou todos do mesmo tipo de NEG. Uma exceção a essa regra é que os NEGs zonais GCE_VM_IP_PORT e os NEGs híbridos podem ser usados no mesmo serviço de back-end para oferecer suporte a uma arquitetura híbrida.

² O IAP e o Cloud CDN são incompatíveis entre si. Elas não podem ser ativadas no mesmo serviço de back-end.

³ Combinações de grupos de instâncias não gerenciadas por zona, grupos gerenciados de instâncias por zona e grupos gerenciados de instâncias por região são compatíveis com o mesmo serviço de back-end. Ao usar o escalonamento automático em um grupo gerenciado de instâncias que é um back-end para dois ou mais serviços de back-end, configure a política de escalonamento automático do grupo de instâncias para usar vários indicadores.

⁴ As NEGs zonais precisam usar endpoints GCE_VM_IP_PORT.

Back-ends e redes VPC

As restrições de onde os back-ends podem estar localizados dependem do tipo de balanceador de carga.

Para back-ends do balanceador de carga de aplicativo externo global, o seguinte se aplica:

• As instâncias de back-end (para back-ends de grupo de instâncias) e os endpoints de back-end (para back-ends de NEG) podem estar localizados em qualquer rede VPC na mesma organização. As diferentes redes VPC não precisam estar conectadas usando o peering de rede VPC, porque os GFEs se comunicam diretamente com back-ends nas respectivas redes VPC.

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

  Os balanceadores de carga de aplicativo externos globais também são compatíveis com ambientes de VPC compartilhada, em que é possível compartilhar redes VPC e os recursos associados entre projetos. No entanto, para balanceadores de carga de aplicativo externos globais, não é necessário configurar a VPC compartilhada para poder referenciar serviços de back-end ou buckets de back-end de outros projetos na sua organização.

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

• Todas as instâncias de back-end dos back-ends de grupos de instâncias e todos os endpoints de back-end dos back-ends de NEG precisam 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. As diferentes redes VPC não precisam estar conectadas usando o peering de rede VPC, porque os GFEs se comunicam diretamente com back-ends nas respectivas redes VPC.

• Os buckets do Cloud Storage não estão associados a uma rede VPC. No entanto, eles precisam estar localizados no mesmo projeto que o balanceador de carga.

Para back-ends do balanceador de carga de aplicativo externo regional, o seguinte se aplica:

• Para grupos de instâncias, NEGs zonais e NEGs de conectividade híbrida, todos os back-ends precisam estar localizados no mesmo projeto e região do serviço de back-end. No entanto, um balanceador de carga pode referenciar um back-end que usa outra rede VPC no mesmo projeto que o serviço de back-end. A conectividade entre a rede VPC do balanceador de carga e a rede VPC de back-end pode ser configurada usando o peering de rede VPC, túneis do Cloud VPN, anexos da VLAN do Cloud Interconnect ou um framework do Network Connectivity Center.

  Definição de rede de back-end

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

  Requisitos de rede de back-end

  A rede do seu back-end precisa atender a um dos requisitos de rede a seguir:

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

  • A rede VPC do back-end precisa estar conectada à rede VPC da regra de encaminhamento usando o peering de rede VPC. É necessário configurar as trocas de rotas de sub-rede para permitir a comunicação entre a sub-rede somente proxy na rede VPC da regra de encaminhamento e as sub-redes usadas pelas instâncias de back-end ou endpoints.

  Requisitos de sub-rede IPv6 de back-end

  Pré-lançamento — Os balanceadores de carga de aplicativo entre regiões, externos regionais e internos regionais oferecem suporte ao encerramento do tráfego IPv6

  Este recurso está sujeito aos Termos das Soluções Pré-GA na seção Termos Gerais de Serviço dos Termos Específicos de Serviço. Os recursos pré-GA estão disponíveis "no estado em que se encontram" e podem ter suporte limitado. Para mais informações, consulte as descrições da fase de lançamento.

  A versão do IP usada para a conexão de front-end é independente da conexão de back-end. Como a sub-rede somente proxy é de pilha dupla (IPV4_IPV6), ela pode se comunicar com back-ends usando IPv4 ou IPv6.

  Se as instâncias de back-end estiverem processando o tráfego IPv6, a sub-rede de back-end poderá ser configurada com um tipo de pilha de IPV4_ONLY ou IPV4_IPV6 (pilha dupla). Se o tipo de pilha da sub-rede de back-end incluir IPv6, defina explicitamente o ipv6-access-type da sub-rede como EXTERNAL.

• A rede VPC do back-end e a rede VPC da regra de encaminhamento precisam ser spokes VPC conectados ao mesmo hub do NCC. Os filtros de importação e exportação precisam permitir a comunicação entre a sub-rede somente proxy na rede VPC da regra de encaminhamento e as sub-redes usadas por instâncias de back-end ou endpoints.

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

  Os balanceadores de carga de aplicativo externos regionais também são compatíveis com ambientes de VPC compartilhada, em que é possível compartilhar redes VPC e os recursos associados entre projetos. Se você quiser que o serviço de back-end e os back-ends do balanceador de carga de aplicativo externo regional estejam em um projeto diferente da regra de encaminhamento, configure o balanceador de carga em um ambiente de VPC compartilhada com referência de serviço entre projetos.

Back-ends e interfaces de rede

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

Se você usar back-ends de NEG zonal, os pacotes serão enviados para qualquer interface de rede representada pelo endpoint no NEG. Os endpoints do NEG precisam estar na mesma rede VPC que a rede VPC definida explicitamente do NEG.

Verificações de integridade

Cada serviço de back-end especifica uma verificação de integridade que monitora periodicamente a prontidão dos back-ends para receber uma conexão do balanceador de carga. Isso reduz o risco de as solicitações serem enviadas para back-ends que não possam atender à solicitação. As verificações de integridade não conferem se o aplicativo está funcionando.

Para as sondagens de verificação de integridade, é necessário criar uma regra de firewall de permissão de entrada que permita que as sondagens de verificação de integridade alcancem as instâncias de back-end. Normalmente, as sondagens de verificação de integridade são originadas do mecanismo centralizado de verificação de integridade do Google.

Os balanceadores de carga de aplicativo externos regionais que usam back-ends de NEG híbridos são uma exceção a essa regra, porque as verificações de integridade são originadas da sub-rede somente proxy. Para mais detalhes, consulte a Visão geral de NEGs híbridos.

Protocolo de verificação de integridade

Embora não seja obrigatório e nem sempre possível, é recomendável usar uma verificação de integridade que tenha um protocolo que corresponda ao protocolo do serviço de back-end. Por exemplo, uma verificação de integridade HTTP/2 testa com mais precisão a conectividade HTTP/2 aos back-ends. Por outro lado, os balanceadores de carga de aplicativo externos regionais que usam back-ends de NEG híbridos não são compatíveis com verificações de integridade do gRPC. Para ver a lista de protocolos de verificação de integridade compatíveis, consulte Recursos de balanceamento de carga.

A tabela a seguir especifica o escopo das verificações de integridade compatíveis com balanceadores de carga de aplicativo externos em cada modo.

Modo balanceador de carga	Tipo de verificação de integridade
Balanceador de carga de aplicativo externo global	Global
Balanceador de carga de aplicativo clássico	Global
Balanceador de carga de aplicativo externo regional	Regional

Para saber mais sobre verificações de integridade, consulte:

• Visão geral das verificações de integridade
• Como criar verificações de integridade

Regras de firewall

O balanceador de carga requer as seguintes regras de firewall:

• Para os balanceadores de carga de aplicativo externos globais, uma regra de permissão de entrada para permitir que o tráfego dos Google Front Ends (GFEs) alcance os back-ends. Para o balanceador de carga de aplicativo externo regional, uma regra de permissão de entrada para permitir que o tráfego da sub-rede somente proxy alcance seus back-ends.
• Uma regra de permissão de entrada para permitir o tráfego dos intervalos de verificação de integridade Saiba mais sobre sondagens de verificação de integridade e por que é necessário permitir tráfego delas em Intervalos de IP de sondagem e regras de firewall.

As regras de firewall são implementadas no nível da instância de VM, não nos proxies do GFE. Não é possível usar regras de firewall do Google Cloud para impedir que o tráfego chegue ao balanceador de carga. Para o balanceador de carga de aplicativo externo global e o balanceador de carga de aplicativo clássico, use o Google Cloud Armor para fazer isso.

As portas dessas regras de firewall precisam ser configuradas da seguinte maneira:

• Permite o tráfego para a porta de destino da verificação de integridade de cada serviço de back-end.

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

• Para back-ends NEG de GCE_VM_IP_PORT: permite tráfego para os números de portas dos endpoints.

A tabela a seguir resume os intervalos de endereços IP de origem obrigatórios para as regras de firewall:

Modo balanceador de carga	Intervalos de origem da verificação de integridade	Solicitar intervalos de origem
Balanceador de carga de aplicativo externo global	Para verificações de integridade IPv4 nos back-ends: 35.191.0.0/16 Para verificações de integridade IPv6 nos 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 tráfego IPv6 para os back-ends: 2600:2d00:1:1::/64 NEGs de conectividade 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): Intervalos de endereços IP listados no registro TXT do DNS _cloud-eoips.googleusercontent.com. É possível extrair os endereços IP de origem para back-ends de NEG de Internet globais usando o seguinte comando de exemplo em um sistema Linux: dig TXT _cloud-eoips.googleusercontent.com | grep -Eo 'ip4:[^ ]+' | cut -d':' -f2 NEGs sem servidor e buckets de back-end: a rede de produção do Google processa o roteamento de pacotes.
Balanceador de carga de aplicativo clássico	Para verificações de integridade IPv4 nos back-ends: 35.191.0.0/16	A origem do tráfego do GFE depende do tipo de back-end: Grupos de instâncias, NEGs por zona (GCE_VM_IP_PORT) e NEGs de conectividade 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): Intervalos de endereços IP listados no registro TXT do DNS _cloud-eoips.googleusercontent.com. É possível extrair os endereços IP de origem para back-ends de NEG de Internet globais usando o seguinte comando de exemplo em um sistema Linux: dig TXT _cloud-eoips.googleusercontent.com | grep -Eo 'ip4:[^ ]+' | cut -d':' -f2 NEGs sem servidor e buckets de back-end: a rede de produção do Google processa o roteamento de pacotes.
Balanceador de carga de aplicativo externo regional	Para verificações de integridade IPv4 nos back-ends: 35.191.0.0/16 Para verificações de integridade IPv6 nos back-ends: 2600:2d00:1:b029::/64 Não é necessário permitir o tráfego de intervalos de sondagem de verificação de integridade do Google para NEGs híbridos. No entanto, se você estiver usando uma combinação de NEGs híbridos e zonais em um único serviço de back-end, será necessário permitir o tráfego dos intervalos de sondagem de verificação de integridade do Google para os NEGs zonais.	A sub-rede somente proxy que você configura. Se você estiver usando uma sub-rede somente proxy de pilha dupla para o tráfego IPv6, sua regra de firewall precisará definir explicitamente o intervalo de origem IPv6 para garantir que o tráfego chegue aos back-ends. Por exemplo, usando --source-ranges ::/0 ou o intervalo IPv6 específico da sub-rede somente proxy (pré-lançamento).

Importante:permita pacotes dos intervalos completos de verificação de integridade. Se a regra de firewall permitir pacotes de apenas um subconjunto dos intervalos, poderão ocorrer falhas na verificação de integridade porque o balanceador de carga não pode se comunicar com os back-ends. Isso gera respostas de código de status HTTP 502.

Front-end global

Observação :um Global Front End é diferente de um Google Front End (GFE). O GFE é um proxy reverso que encerra conexões TCP, enquanto um front-end global é uma solução que ajuda a entregar, escalonar e proteger seus aplicativos voltados para a Internet. O Global Front End Enterprise consolida os preços de diferentes produtos de rede Google Cloud em um único nível de preço por pacote.

O Global Front End, disponível em prévia, combina balanceadores de carga de aplicativo externos globais, Google Cloud Armor, Cloud CDN e Service Extensions em uma solução para ajudar a entregar, escalonar e proteger seus aplicativos voltados para a Internet. É possível ativar o nível de faturamento Global Front End Enterprise no seu projeto do Google Cloud. Com o Global Front End Enterprise, os preços dos produtos mencionados são consolidados em um único plano de preços. Para mais informações sobre como ativar o nível de faturamento Global Front End Enterprise no seu projeto, consulte Ativar e gerenciar o Global Front End Enterprise no seu projetoGoogle Cloud .

Ao ativar o Global Front End Enterprise em um projeto, todos os balanceadores de carga de aplicativo externos globais desse projeto têm acesso a recursos específicos do Cloud Armor Enterprise.

Em uma arquitetura de front-end global, um balanceador de carga de aplicativo externo global distribui o tráfego HTTP e HTTPS entre as instâncias de back-end de um aplicativo em várias regiões. O Cloud CDN acelera aplicativos voltados à Internet usando os pontos de presença (PoPs) de borda do Google e trabalha com o balanceador de carga de aplicativo externo global para fornecer conteúdo aos usuários. As políticas de segurança do Google Cloud Armor protegem as instâncias de back-end. Essas políticas fornecem filtragem da Camada 7 ao inspecionar solicitações recebidas para ataques comuns da Web ou outros atributos da Camada 7, bloqueando o tráfego antes de alcançar os serviços de back-end com carga balanceada. Com as extensões de serviço, é possível personalizar o processamento de dados do balanceador de carga para atender aos requisitos específicos do seu aplicativo ou negócio.

Observação :se um balanceador de carga de aplicativo externo global rotear o tráfego para back-ends em outros projetos, os preços do Global Front End Enterprise serão aplicados apenas ao projeto em que os componentes de front-end do balanceador de carga residem. O uso e as cobranças em projetos que contêm os componentes de back-end seguem os preços de cada produto.

Suporte do GKE

O GKE usa balanceadores de carga de aplicativo externos das seguintes maneiras:

• Os gateways externos criados usando o controlador de gateway do GKE podem usar qualquer modo de um balanceador de carga de aplicativo externo. Você controla o modo do balanceador de carga escolhendo uma GatewayClass. O controlador de gateway do GKE sempre usa back-ends de NEG zonal GCE_VM_IP_PORT.

  Quando o Cloud CDN é ativado para back-ends gerenciados pelo Gateway do GKE, o armazenamento em cache é configurado usando os filtros GCPHTTPFilter do GKE anexados aos recursos HTTPRoute. Para saber como configurar o armazenamento em cache, consulte Configurar o Cloud CDN para o Gateway.

• As entradas externas criadas com o controlador de Entrada do GKE são sempre balanceadores de carga de aplicativo clássicos. O controlador de Entrada do GKE prefere usar back-ends de NEG zonal GCE_VM_IP_PORT, embora back-ends de grupo de instâncias também sejam compatíveis.

• É possível usar o NEG zonal GCE_VM_IP_PORT criado e gerenciado pelos serviços do GKE como back-ends para qualquer balanceador de carga de aplicativo ou balanceador de carga de rede de proxy. Para mais informações, consulte Balanceamento de carga nativo de contêiner por meio de NEGs zonais independentes.

Arquitetura da VPC compartilhada

Os balanceadores de carga de aplicativo externos são compatíveis com redes que usam a VPC compartilhada. A VPC compartilhada permite que as organizações conectem recursos de vários projetos a uma rede VPC comum para comunicarem-se umas com as outras de maneira segura e eficiente usando os endereços IP internos dessa rede. Se você ainda não tiver familiaridade com a VPC compartilhada, leia a visão geral da VPC compartilhada.

Há muitas maneiras de configurar um balanceador de carga de aplicativo externo em uma rede VPC compartilhada. Independentemente do tipo de implantação, todos os componentes do balanceador de carga precisam estar na mesma organização.

Balanceador de carga	Componentes de front-end	Componentes de back-end
Balanceador de carga de aplicativo externo global	Se você estiver usando uma rede VPC compartilhada para seus back-ends, crie a rede necessária no projeto host da VPC compartilhada. O endereço IP externo global, a regra de encaminhamento, o proxy HTTP(S) de destino e o mapa de URL associado precisam ser definidos no mesmo projeto. Esse projeto pode ser o projeto host ou um projeto de serviços.	Você tem estas opções: Crie serviços de back-end, buckets de back-end e back-ends (grupos de instâncias, NEGs sem servidor ou qualquer outro tipo de back-end compatível) no mesmo projeto de serviço que os componentes de front-end. Crie serviços de back-end, buckets de back-end e back-ends (grupos de instâncias, NEGs sem servidor ou qualquer outro tipo de back-end compatível) em projetos de serviço. Um único mapa de URL pode referenciar serviços de back-end em diferentes projetos. Esse tipo de implantação é conhecido como referência de serviço entre projetos. Cada serviço de back-end precisa ser definido no mesmo projeto que os back-ends a que ele faz referência. As verificações de integridade associadas aos serviços de back-end precisam ser definidas no mesmo projeto que o serviço de back-end. Os back-ends podem ser parte de uma rede VPC compartilhada do projeto host ou de uma rede VPC independente, ou seja, uma rede VPC não compartilhada no projeto de serviços.
Balanceador de carga de aplicativo clássico	O endereço IP externo global, a regra de encaminhamento, o proxy HTTP(S) de destino e o mapa de URL associado precisam ser definidos no mesmo projeto host ou de serviço dos back-ends.	Um serviço de back-end global precisa ser definido no mesmo projeto host ou de serviço que os back-ends (grupos de instâncias ou NEGs). As verificações de integridade associadas aos serviços de back-end também precisam ser definidas no mesmo projeto que o serviço de back-end.
Balanceador de carga de aplicativo externo regional	Crie a rede e a sub-rede somente proxy necessárias no projeto host da VPC compartilhada. O endereço IP externo regional, a regra de encaminhamento, o proxy HTTP(S) de destino e o mapa de URL associado precisam ser definidos no mesmo projeto. Esse projeto pode ser o projeto host ou de serviços.	Você tem estas opções: Crie serviços de back-end e back-ends (grupos de instâncias, NEGs sem servidor ou qualquer outro tipo de back-end compatível) 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 compatíveis) em quantos projetos de serviço forem necessários. Um único mapa de URL pode referenciar serviços de back-end em diferentes projetos. Esse tipo de implantação é conhecido como referência de serviço entre projetos. Cada serviço de back-end precisa ser definido no mesmo projeto que os back-ends a que ele faz referência. As verificações de integridade associadas aos serviços de back-end também precisam ser definidas no mesmo projeto que o serviço de back-end.

Embora seja possível criar todos os componentes e back-ends de balanceamento de carga no projeto host da VPC compartilhada, esse tipo de implantação não separa as responsabilidades de administração da rede e desenvolvimento de serviços.

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

O diagrama de arquitetura a seguir mostra uma implantação de VPC compartilhada padrão em que todos os componentes e back-ends do balanceador de carga estão em um projeto de serviço. Todos os balanceadores de carga de aplicativo oferecem suporte a esse tipo de implantação.

Os componentes e os back-ends do balanceador de carga precisam usar a mesma rede VPC.

Balanceador de carga de aplicativo externo regional em rede VPC compartilhada (clique para ampliar).

Back-ends sem servidor em um ambiente de VPC compartilhada

Para um balanceador de carga que usa um back-end NEG sem servidor, o serviço de back-end do Cloud Run ou das funções do Cloud Run precisa estar no mesmo projeto que o NEG sem servidor.

Além disso, para o balanceador de carga de aplicativo externo regional que aceita referência de serviço entre projetos, o serviço de back-end, o NEG sem servidor e o serviço do Cloud Run precisam estar sempre no mesmo projeto de serviço.

Referência de serviço entre projetos

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

Com a referência de serviços entre projetos, as organizações podem configurar um balanceador de carga central e direcionar o tráfego para centenas de serviços distribuídos em vários projetos diferentes. É possível gerenciar de maneira centralizada todas as regras e políticas de roteamento de tráfego em um mapa de URL. Também é possível associar o balanceador de carga a um único conjunto de nomes de host e certificados SSL. Portanto, é possível otimizar o número de balanceadores de carga necessários para implantar o aplicativo e reduzir os gerenciamentos, os custos operacionais e os requisitos de cota.

Com projetos diferentes para cada uma das equipes funcionais, também é possível alcançar a separação de papéis dentro da organização. Os proprietários de serviço podem se concentrar na criação de serviços em projetos de serviço, enquanto as equipes de rede podem provisionar e manter os balanceadores de carga em outro projeto. Ambos podem ser conectados por referência de serviço entre projetos.

Os proprietários de serviços podem manter a autonomia sobre a exposição dos próprios serviços e controlar quais usuários podem acessá-los pelo balanceador de carga. Isso é alcançado por um papel especial do IAM chamado função do usuário dos serviços do balanceador de carga do Compute (roles/compute.loadBalancerServiceUser).

O suporte à referência de serviço entre projetos varia de acordo com o tipo de balanceador de carga:

• Para balanceadores de carga de aplicativo externos globais: o front-end e o mapa de URL do balanceador de carga podem fazer referência a serviços ou buckets de back-end de qualquer projeto na mesma organização. Nenhuma restrição de rede VPC se aplica. Embora seja possível usar um ambiente de VPC compartilhada para configurar uma implantação entre projetos, conforme mostrado neste exemplo, isso não é um requisito.

• Para balanceadores de carga de aplicativo externos regionais: é necessário criar o balanceador de carga em um ambiente de VPC compartilhada. O front-end e o mapa de URL do balanceador de carga precisam estar em um projeto host ou de serviço, e os serviços de back-end e back-ends do balanceador de carga podem ser distribuídos entre projetos host ou de serviço no mesmo ambiente de VPC compartilhada.

Para saber como configurar a VPC compartilhada para um balanceador de carga de aplicativo externo global, com e sem referência de serviço entre projetos, consulte Configurar um balanceador de carga de aplicativo externo global com VPC compartilhada.

Para saber como configurar a VPC compartilhada para um balanceador de carga de aplicativo externo regional, com e sem a referência de serviço entre projetos, consulte Configurar um balanceador de carga de aplicativo externo regional com VPC compartilhada.

Observações de uso para referência de serviço entre projetos

• A referência de serviço entre projetos pode ser usada com grupos de instâncias, NEGs sem servidor e a maioria dos outros tipos de back-ends compatíveis. No entanto, as seguintes limitações se aplicam:

  • Com os balanceadores de carga de aplicativo globais externos, não é possível referenciar um serviço de back-end entre projetos se ele tiver back-ends NEG sem servidor com o App Engine.

  • Com balanceadores de carga de aplicativo externos regionais, não é possível referenciar um serviço de back-end entre projetos se o serviço de back-end tiver back-ends NEG da Internet regionais.
• A referência de serviço entre projetos não é compatível com o balanceador de carga de aplicativo clássico.
• OGoogle Cloud não diferencia recursos (por exemplo, serviços de back-end) que usam o mesmo nome em vários projetos. Portanto, ao usar a referência de serviços entre projetos, recomendamos o uso de nomes exclusivos de serviço de back-end em todos os projetos da organização.
• Se você encontrar um erro como "Não são permitidas referências entre projetos para esse recurso", verifique se você tem permissão para usar o recurso. Um administrador do projeto proprietário do recurso precisa conceder a você o papel de usuário dos serviços do balanceador de carga do Compute (roles/compute.loadBalancerServiceUser). Esse papel pode ser concedido no nível do projeto ou do recurso. Por exemplo, consulte Conceder permissões ao administrador do balanceador de carga do Compute para usar o serviço de back-end ou o bucket de back-end.

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

Veja um exemplo de uma implantação de VPC compartilhada em que o mapa de URL e o front-end do balanceador de carga são criados no projeto de serviço A e o mapa de URL faz referência a um serviço de back-end no projeto de serviço B.

Nesse caso, os administradores de rede ou administradores do balanceador de carga no projeto de serviço A precisarão de acesso aos serviços de back-end no projeto de serviço B. Os administradores do projeto de serviço B concedem o papel de usuário de serviços do balanceador de carga do Compute (roles/compute.loadBalancerServiceUser) aos administradores do balanceador de carga no projeto de serviço A que querem referenciar o serviço de back-end no projeto de serviço B.

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

Exemplo 2: front-end do balanceador de carga no projeto host e back-ends em projetos de serviço

Confira um exemplo de implantação de VPC compartilhada em que o front-end e o mapa de URL do balanceador de carga são criados no projeto host, e os serviços de back-end (e back-ends) são criados em projetos de serviço.

Nesse caso, os administradores de rede ou de balanceador de carga no projeto host precisam de acesso aos serviços de back-end no projeto de serviço. Os administradores do projeto de serviço concedem o papel de usuário de serviços do balanceador de carga do Compute (roles/compute.loadBalancerServiceUser) aos administradores do balanceador de carga no projeto host A que querem referenciar o serviço de back-end no projeto de serviço.

Front-end do balanceador de carga e mapa de URL no projeto host (clique para ampliar).

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

Confira um exemplo de implantação em que o front-end e o mapa de URL do balanceador de carga de aplicativo externo global são criados em um projeto diferente do serviço de back-end e dos back-ends do balanceador de carga. Esse tipo de implantação não usa VPC compartilhada e é compatível apenas com balanceadores de carga de aplicativo externos globais.

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

Para saber mais sobre essa configuração, consulte Configurar a referência de serviço entre projetos com um serviço de back-end e um bucket de back-end.

Alta disponibilidade e failover

A alta disponibilidade e o failover em balanceadores de carga de aplicativo externos podem ser configurados no nível do balanceador de carga. Para isso, crie balanceadores de carga de aplicativo externos regionais de backup em qualquer região em que você precise de backup.

A tabela a seguir descreve o comportamento de failover.

Modo balanceador de carga	Métodos de failover
Balanceador de carga de aplicativo externo global Balanceador de carga de aplicativo clássico	É possível definir uma configuração de failover ativo-passivo em que o tráfego passa para um balanceador de carga de aplicativo externo regional de backup. Use as verificações de integridade para detectar falhas e as políticas de roteamento do Cloud DNS para rotear o tráfego quando o failover for acionado.
Balanceador de carga de aplicativo externo regional	Use um dos seguintes métodos para garantir uma implantação altamente disponível: É possível definir uma configuração de failover ativo-passivo, em que o tráfego passa para um balanceador de carga de aplicativo externo regional de backup. Use as verificações de integridade para detectar interrupções e uma política de roteamento de failover do Cloud DNS para rotear o tráfego quando o failover for acionado por verificações de integridade com falha. Para mais detalhes, consulte Failover para balanceadores de carga de aplicativo externos. É possível definir uma configuração de failover ativo-ativo, em que você implanta vários balanceadores de carga de aplicativo externos regionais individuais nas regiões que você determinar que suportarão melhor o tráfego para seu aplicativo. Use uma política de roteamento de geolocalização do Cloud DNS para rotear o tráfego para a região apropriada com base na origem da solicitação do cliente. Também é possível usar verificações de integridade para detectar interrupções e rotear o tráfego apenas para os balanceadores de carga íntegros. Para mais detalhes, consulte Alta disponibilidade para balanceadores de carga de aplicativo externos regionais.

Suporte a HTTP/2

HTTP/2 é uma revisão importante do protocolo HTTP/1. Há dois modos de suporte ao HTTP/2:

• HTTP/2 sobre TLS
• HTTP/2 de texto não criptografado sobre TCP

HTTP/2 por TLS

O HTTP/2 por TLS é compatível com conexões entre clientes e o balanceador de carga de aplicativo externo e para conexões entre o balanceador de carga e os back-ends dele.

O balanceador de carga negocia o HTTP/2 com clientes como parte do handshake de TLS usando a extensão ALPN TLS. Mesmo que um balanceador de carga esteja configurado para usar HTTPS, os clientes modernos usam HTTP/2 como padrão. Isso é controlado no cliente, não no balanceador de carga.

Se um cliente não oferecer suporte a 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 ainda poderá negociar uma conexão HTTPS ou aceitar solicitações HTTP não seguras. Essas solicitações HTTPS ou HTTP são transformadas pelo balanceador de carga para fazer proxy das solicitações por HTTP/2 para as instâncias de back-end.

Para usar HTTP/2 por TLS, ative o TLS nos seus back-ends e defina o protocolo do serviço de back-end como HTTP2. Saiba mais em Criptografia do balanceador de carga nos back-ends.

Máximo de streams simultâneos HTTP/2

A configuração HTTP/2 SETTINGS_MAX_CONCURRENT_STREAMS descreve o número máximo de streams aceitos por um endpoint, iniciado pelo par. O valor divulgado por um cliente HTTP/2 para um balanceador de carga doGoogle Cloud é efetivamente insignificante, porque o balanceador de carga não inicia streams para o cliente.

Nos casos em que o balanceador de carga usa HTTP/2 para se comunicar com um servidor em execução em uma 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 da solicitação (Google Cloud balanceador de carga → servidor gRPC), o balanceador de carga usa o frame SETTINGS inicial do servidor gRPC para determinar quantos streams por conexão podem ser usados simultaneamente. Se o servidor anunciar um valor maior que 100, o balanceador de carga usará 100 como o número máximo de streams simultâneos. Se um valor igual a zero for anunciado, o balanceador de carga não poderá encaminhar solicitações para o servidor. Isso poderá gerar erros.

Tamanho da tabela de cabeçalho dinâmico HTTP/2

O HTTP/2 melhora significativamente o HTTP/1.1 com recursos como multiplexação e compactação de cabeçalho HPACK. O HPACK usa uma tabela dinâmica que melhora a compressão de cabeçalho, tornando tudo mais rápido. Para entender o impacto das mudanças dinâmicas no tamanho da tabela de cabeçalho no HTTP/2, como esse recurso pode melhorar o desempenho e como um bug específico em várias bibliotecas de cliente HTTP pode causar problemas na compactação de cabeçalho 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 conexões TCP com a instância do que o HTTP ou o HTTPS. O pool de conexões, uma otimização que reduz o número dessas conexões com HTTP ou HTTPS, não está disponível com o HTTP/2. Como resultado, talvez você veja altas latências de back-end porque as conexões de back-end são feitas com mais frequência.
• O HTTP/2 entre o balanceador de carga e o back-end não é compatível com push do servidor.
• A taxa de erros do gRPC e o volume da solicitação não são visíveis na API doGoogle Cloud ou no console do Google Cloud . Se o endpoint do gRPC retornar um erro, os registros do balanceador de carga e os dados de monitoramento reportarão o código de status HTTP 200 OK.

HTTP/2 sobre TCP de texto não criptografado

O HTTP/2 em TCP de texto não criptografado, representado pela string "h2c" de acordo com a RFC 7540, permite usar o HTTP/2 sem criptografia TLS. Ele é compatível com as seguintes conexões:

• Cliente para balanceador de carga: compatível automaticamente com balanceadores de carga de aplicativo externos regionais. Nenhuma configuração especial é necessária.

  Importante: para a conexão do cliente com o balanceador de carga, o H2C não é compatível com balanceadores de carga de aplicativo externos globais ou clássicos.

• Balanceador de carga para os back-ends: compatível ao definir o protocolo de serviço de back-end como H2C.

  Importante: para a conexão do balanceador de carga com o back-end, o H2C não é compatível com balanceadores de carga de aplicativo clássicos.

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

Suporte a HTTP/3

O HTTP/3 é um protocolo de Internet de última geração. Ele é baseado no IETF QUIC, um protocolo desenvolvido com base no protocolo Google QUIC original. O HTTP/3 é compatível entre o balanceador de carga de aplicativo externo, o Cloud CDN e os clientes.

A compatibilidade com o Google QUIC (também conhecido como gQUIC) foi removido em abril de 2023 e foi substituído pelo HTTP/3 em vez do IETF QUIC, que é um padrão IETF e tem desempenho melhor que o gQUIC.

Especificamente:

• O IETF QUIC é um protocolo de camada de transporte que oferece controle de congestionamento e confiabilidade semelhantes ao TCP, usa TLS 1.3 para segurança e melhor desempenho.
• O HTTP/3 é uma camada do aplicativo criada com base no IETF QUIC e depende do QUIC para lidar com a multiplexação, o controle de congestionamento, a detecção de perdas e a retransmissão.
• O HTTP/3 permite uma inicialização mais rápida da conexão do cliente, elimina o bloqueio "head-of-line" em fluxos multiplexados e aceita a migração da conexão quando o endereço IP de um cliente é alterado.
• O HTTP/3 é compatível com conexões entre clientes e o balanceador de carga, e não com conexões entre o balanceador de carga e os back-ends dele.
• As conexões HTTP/3 usam o algoritmo de controle de congestionamento BBR.

O HTTP/3 no balanceador de carga pode melhorar os tempos de carregamento da página da Web, reduzir o armazenamento em buffer de vídeo e melhorar a capacidade de processamento em conexões de maior latência.

A tabela a seguir especifica o suporte HTTP/3 para balanceadores de carga de aplicativo externos em cada modo.

Modo balanceador de carga	Suporte a HTTP/3
Balanceador de carga de aplicativo externo global (sempre nível Premium)
Balanceador de carga de aplicativo clássico no nível Premium
Balanceador de carga de aplicativo clássico no nível Standard
Balanceador de carga de aplicativo externo regional (nível Premium ou Standard)

Como o HTTP/3 é negociado

Quando o HTTP/3 está ativado, o balanceador de carga anuncia essa compatibilidade para os clientes, permitindo que clientes que aceitam HTTP/3 tentem estabelecer conexões HTTP/3 com o balanceador de carga HTTPS.

• Os clientes implementados corretamente sempre recorrem a HTTPS ou HTTP/2 quando não conseguem estabelecer uma conexão HTTP/3.
• Os clientes que aceitam HTTP/3 usam o conhecimento prévio em cache dessa compatibilidade para salvar viagens de ida e volta desnecessárias no futuro.
• Por isso, ativar ou desativar o HTTP/3 no balanceador de carga não afeta a capacidade do balanceador de carga de se conectar com os clientes.

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

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

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

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

Quando o HTTP/3 está ativado no balanceador de carga HTTPS, algumas circunstâncias podem fazer com que o cliente recorra a HTTPS ou HTTP/2 em vez de negociar o HTTP/3. Isso inclui o seguinte:

• Quando um cliente aceita versões do HTTP/3 que não são compatíveis com as versões do HTTP/3 compatíveis com o balanceador de carga HTTPS.
• Quando o balanceador de carga detecta que o tráfego UDP está bloqueado ou tem limitação de taxa de modo a impedir o funcionamento do HTTP/3.
• O cliente não é compatível com HTTP/3 e, portanto, não tenta negociar uma conexão HTTP/3.

Quando uma conexão retorna para HTTPS ou HTTP/2, isso não é considerado uma falha do balanceador de carga.

Antes de ativar o HTTP/3, verifique se os comportamentos descritos acima são aceitáveis para suas cargas de trabalho.

Configurar HTTP/3

Tanto NONE (o padrão) quanto ENABLE ativam suporte a HTTP/3 para o balanceador de carga.

Quando o HTTP/3 está ativado, o balanceador de carga o anuncia para os clientes, o que permite que os clientes compatíveis com ele negociem uma versão HTTP/3 com o balanceador de carga. Clientes que não são compatíveis com HTTP/3 não negociam uma conexão HTTP/3. Não é necessário desativar o HTTP/3 explicitamente, a menos que você tenha identificado implementações de cliente corrompidas.

Os balanceadores de carga de aplicativo externos oferecem três maneiras de configurar o HTTP/3, conforme mostrado na tabela a seguir.

Valor quicOverride	Comportamento
NONE	A compatibilidade com HTTP/3 é anunciada para os clientes.
ENABLE	A compatibilidade com HTTP/3 é anunciada para os clientes.
DISABLE	Desativa explicitamente a divulgação de HTTP/3 e do Google QUIC para clientes.

Para ativar (ou desativar) o HTTP/3 explicitamente, siga estas etapas.

Console: HTTPS

Observação :no momento, a configuração da negociação HTTP/3 não é compatível com a página de proxies de destino e precisa ser definida editando a configuração do balanceador de carga.

1. No console do Google Cloud , acesse a página Balanceamento de carga.

   Acessar o "Balanceamento de carga"

2. Selecione o balanceador de carga que você quer editar.

3. Clique em Configuração de front-end.

4. Selecione o endereço IP do front-end e a porta que você quer editar. Para editar uma configuração HTTP/3, o protocolo precisa ser HTTPS.

Ativar HTTP/3

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

Desativar HTTP/3

1. Selecione o menu Negociação QUIC.
2. Para desativar explicitamente o HTTP/3 para este front-end, selecione Desativado.
3. Se você tiver várias regras de front-end representando IPv4 e IPv6, desative o HTTP/3 para cada regra.

gcloud: HTTPS

Antes de executar este comando, é necessário 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 um dos seguintes:

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

  Quando você seleciona NONE, o HTTP/3 é anunciado para os clientes, mas o Google QUIC não. No console Google Cloud , essa opção é chamada de Automática (padrão).

• ENABLE: divulga o HTTP/3 para os clientes.

• DISABLE: não anuncia HTTP/3 para os 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 um dos seguintes:

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

  Quando você seleciona NONE, o HTTP/3 é anunciado para os clientes, mas o Google QUIC não. No console Google Cloud , essa opção é chamada de Automática (padrão).

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

• DISABLE: não divulga HTTP/3 ou Google QUIC para os clientes.

Suporte a WebSocket

Google Cloud Os balanceadores de carga baseados em HTTP(S) são compatíveis com o protocolo WebSocket ao usar HTTP/1.1 (HTTP ou HTTPS) ou HTTP/2 como protocolo para o back-end. O balanceador de carga não precisa de configuração para representar conexões WebSocket.

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

Para conexões HTTP/1.1, o protocolo WebSocket usa o mecanismo Upgrade HTTP/1.1 para fazer a transição de uma conexão TCP de HTTP para WebSocket. O protocolo WebSocket sobre HTTP/1.1 funciona da seguinte maneira:

1. O balanceador de carga reconhece uma solicitação Upgrade WebSocket de um cliente HTTP ou HTTPS. A solicitação contém os cabeçalhos Connection: Upgrade e Upgrade: websocket, seguidos por outros cabeçalhos da solicitação relevantes relacionados ao WebSocket.
2. O back-end envia uma resposta do WebSocket Upgrade. Isso consiste em uma resposta 101 Switching Protocols com cabeçalhos Connection: Upgrade e Upgrade: websocket e outros cabeçalhos de resposta relacionados ao WebSocket.
3. O balanceador de carga faz o proxy do tráfego bidirecional durante a conexão atual.

Se a instância de back-end retornar um código de status HTTP 426 ou HTTP 502, o balanceador de carga encerra a conexão.

Para conexões HTTP/2, o protocolo WebSocket usa o método CONNECT estendido com campos de pseudocabeçalho (como :protocol) para criar um túnel em um único stream HTTP/2 que pode transportar dados para WebSockets (RFC 8441). O protocolo WebSocket sobre HTTP/2 funciona da seguinte maneira:

1. O servidor de back-end envia um frame HTTP/2 SETTINGS que contém o parâmetro SETTINGS_ENABLE_CONNECT_PROTOCOL definido como 1. Isso anuncia ao balanceador de carga que o back-end aceita o método CONNECT estendido.

2. Ao receber essa configuração, o balanceador de carga a reconhece e pode encaminhar solicitações de upgrade do WebSocket. Ele envia a solicitação de upgrade para o back-end usando o método CONNECT estendido. A solicitação contém os pseudocabeçalhos :method: CONNECT e :protocol: websocket, juntamente com outros cabeçalhos da solicitação relevantes relacionados ao WebSocket.

3. O back-end envia uma resposta de sucesso do WebSocket. O servidor de back-end envia uma resposta 200 OK (em vez da resposta 101 Switching Protocols usada em HTTP/1.1) para estabelecer o túnel WebSocket em um único stream de uma conexão HTTP/2.

4. O balanceador de carga faz proxy do tráfego bidirecional pelo stream HTTP/2 estabelecido.

Se a instância de back-end retornar um código de status 426 ou 502, nenhum upgrade do WebSocket vai ocorrer, e o código de status será propagado para o cliente.

O tempo limite da conexão WebSocket depende do tipo de balanceador de carga (global, regional ou clássico). Para mais detalhes, consulte Tempo limite do serviço de back-end.

A afinidade de sessão para WebSockets funciona da mesma forma que qualquer outra solicitação. Para mais informações, consulte Afinidade de sessão.

Suporte ao gRPC

O gRPC é um framework de código aberto para chamadas de procedimento remoto. Ele é baseado no padrão HTTP/2. Veja alguns casos de uso do gRPC:

• Sistemas distribuídos de baixa latência e altamente escalonáveis.
• Desenvolvimento de clientes de dispositivos móveis que se comunicam com um servidor em nuvem.
• Criação de novos protocolos que ofereçam precisão, eficiência e não dependam de linguagem.
• design em camadas que permita extensão, autenticação e geração de registros

Para usar o gRPC com seus aplicativos do Google Cloud , é preciso fazer proxy de solicitações de ponta a ponta por HTTP/2. Para fazer isso, crie um balanceador de carga de aplicativo com uma das seguintes configurações:

• HTTP/2 por TLS entre o cliente e o balanceador de carga e H2C entre o balanceador de carga e o back-end: crie um balanceador de carga HTTPS (configurado com um proxy de destino HTTPS e um certificado SSL). Além disso, configure o balanceador de carga para usar HTTP/2 em conexões não criptografadas entre o balanceador de carga e os back-ends dele definindo o protocolo do serviço de back-end como H2C.

• Tráfego criptografado de ponta a ponta usando HTTP/2 sobre TLS: você cria um balanceador de carga HTTPS (configurado com um proxy HTTPS de destino e um certificado SSL). O balanceador de carga negocia o HTTP/2 com clientes como parte do handshake SSL usando a extensão ALPN TLS.

  Além disso, é preciso garantir que os back-ends possam processar o tráfego TLS e configurar o balanceador de carga para usar HTTP/2 em conexões criptografadas entre o balanceador de carga e os back-ends. Para isso, defina o protocolo de serviço de back-end como HTTP2.

  O balanceador de carga ainda pode negociar HTTPS com alguns clientes ou aceitar solicitações HTTP não seguras em um balanceador de carga configurado para usar HTTP/2 entre o balanceador de carga e as instâncias de back-end. Essas solicitações HTTP ou HTTPS são transformadas pelo balanceador de carga para fazer proxy das solicitações por HTTP/2 para as instâncias de back-end.

Se quiser configurar um balanceador de carga de aplicativo usando o HTTP/2 com a Entrada do Google Kubernetes Engine ou usando o gRPC e o HTTP/2 com a Entrada, consulte HTTP/2 para balanceamento de carga com Entrada.

Se quiser configurar um balanceador de carga de aplicativo externo usando HTTP/2 com o Cloud Run, consulte Usar HTTP/2 protegido por um balanceador de carga.

Saiba mais sobre a solução de problemas com o HTTP/2 em Como resolver problemas com o HTTP/2 para os back-ends.

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

Se você estiver usando streaming gRPC bidirecional e o cliente se conectar a um balanceador de carga de aplicativo externo global, o servidor de back-end poderá ficar travado se um cliente realizar um fechamento parcial imediato (enviar uma flag END_STREAM imediatamente após a criação do fluxo sem enviar dados). Isso ocorre devido a um conflito entre a otimização do HTTP/2 e as especificações de enquadramento do gRPC. Para saber mais, consulte Resolver problemas do gRPC.

Suporte TLS

Por padrão, um proxy de destino HTTPS só aceita TLS 1.0, 1.1 e 1.2 e 1.3 ao encerrar solicitações SSL do cliente.

Quando o balanceador de carga de aplicativo externo global ou regional usa HTTPS como o protocolo de serviço de back-end, ele pode negociar TLS 1.2 ou 1.3 para o back-end.

Quando o balanceador de carga de aplicativo clássico usa HTTPS como o protocolo de serviço de back-end, ele pode negociar TLS 1.0, 1.1, 1.2 ou 1.3 para o back-end.

Suporte a TLS mútuo

O TLS mútuo, ou mTLS, é um protocolo padrão do setor para autenticação mútua entre um cliente e um servidor. O mTLS ajuda a garantir que o cliente e o servidor autentiquem um ao outro, verificando se cada um tem um certificado válido emitido por uma autoridade certificadora (CA) confiável. Ao contrário do TLS padrão, em que apenas o servidor é autenticado, o mTLS exige que o cliente e o servidor apresentem certificados, confirmando as identidades de ambas as partes antes que a comunicação seja estabelecida.

Todos os balanceadores de carga de aplicativo são compatíveis com mTLS. Com o mTLS, o balanceador de carga solicita que o cliente envie um certificado para se autenticar durante o handshake de TLS com o balanceador de carga. É possível configurar um repositório de confiança do Gerenciador de certificados que o balanceador de carga usa para validar a cadeia de confiança do certificado do cliente.

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

Suporte a dados iniciais do TLS 1.3

Observação :os dados iniciais do TLS 1.3 ou 0-RTT só são compatíveis com a retomada de sessões anteriores entre os clientes e o Cloud CDN ou o balanceador de carga. O Cloud CDN ou o balanceador de carga não podem usar dados iniciais do TLS ao encaminhar solicitações para os servidores de origem.

Os dados antecipados do TLS 1.3 são compatíveis com o proxy HTTPS de destino dos seguintes balanceadores de carga de aplicativo externos para HTTPS sobre TCP (HTTP/1.1, HTTP/2) e HTTP/3 sobre QUIC:

• Balanceadores de carga de aplicativos externos globais
• Balanceadores de carga de aplicativo 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 retorno zero (0-RTT), que podem melhorar o desempenho do aplicativo para conexões retomadas em 30 a 50%.

Com o TLS 1.2, são necessárias duas idas e voltas antes que os dados possam ser transmitidos com segurança. O TLS 1.3 reduz isso para uma viagem de ida e volta (1-RTT) para novas conexões, permitindo que os clientes enviem dados de aplicativos imediatamente após a primeira resposta do servidor. Além disso, o TLS 1.3 introduz o conceito de dados antecipados para sessões retomadas, permitindo que os clientes enviem dados de aplicativos com o ClientHello inicial, reduzindo o tempo de ida e volta efetivo para zero (0-RTT). Os dados iniciais do TLS 1.3 permitem que o servidor de back-end comece a processar os dados do cliente antes que o processo de handshake com o cliente seja concluído, reduzindo assim a latência. No entanto, é preciso tomar cuidado para mitigar os riscos de repetição.

Como os dados iniciais são enviados antes da conclusão do handshake, um invasor pode tentar capturar e repetir solicitações. Para mitigar isso, o servidor de back-end precisa controlar cuidadosamente o uso de dados antecipados, limitando o uso a solicitações idempotentes. Os métodos HTTP que devem ser idempotentes, mas que podem acionar mudanças não idempotentes, como uma solicitação GET que modifica um banco de dados, não podem aceitar dados iniciais. Nesses casos, o servidor de back-end precisa rejeitar solicitações com o cabeçalho HTTP Early-Data: 1 retornando um código de status HTTP 425 Too Early.

As solicitações com dados iniciais têm o cabeçalho HTTP Early-Data definido como um valor de 1, o que indica ao servidor de back-end que a solicitação foi transmitida em dados iniciais de TLS. Ele também indica que o cliente entende o código de status HTTP 425 Too Early.

Modos de dados iniciais do TLS (0-RTT)

É possível configurar os dados iniciais do TLS usando um dos seguintes modos no recurso de proxy HTTPS de destino do balanceador de carga.

• STRICT. Isso permite dados iniciais do TLS 1.3 para solicitações com métodos HTTP seguros (GET, HEAD, OPTIONS, TRACE) e solicitações HTTP que não têm parâmetros de consulta. As solicitações que enviam dados iniciais contendo métodos HTTP não idempotentes (como POST ou PUT) ou com parâmetros de consulta são rejeitadas com um código de status HTTP 425.

• PERMISSIVE. Isso ativa os dados iniciais do TLS 1.3 para solicitações com métodos HTTP seguros (GET, HEAD, OPTIONS e TRACE). Esse modo não nega solicitações que incluem parâmetros de consulta. O proprietário do aplicativo precisa garantir que os dados iniciais sejam seguros para uso em cada caminho de solicitação, principalmente para endpoints em que a repetição de solicitações pode causar efeitos colaterais indesejados, como atualizações de registro ou de banco de dados acionadas por solicitações GET.

• DISABLED. Os dados iniciais do TLS 1.3 não são anunciados, e qualquer tentativa (inválida) de enviar dados iniciais é rejeitada. Se os aplicativos não estiverem equipados para processar solicitações de dados antecipados com segurança, desative os dados antecipados. Os dados iniciais do TLS 1.3 estão desativados por padrão.

• UNRESTRICTED (não recomendado para a maioria das cargas de trabalho). Isso ativa os dados iniciais do TLS 1.3 para solicitações com qualquer método HTTP, incluindo métodos não idempotentes, como POST. Esse modo não aplica outras limitações. Esse modo pode ser útil para casos de uso do gRPC. No entanto, não recomendamos esse método, a menos que você tenha avaliado sua postura de segurança e mitigado o risco de ataques de repetição usando outros mecanismos.

Configurar dados iniciais do TLS

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

Console

1. No console do Google Cloud , acesse a página Balanceamento de carga.

   Acessar o "Balanceamento de carga"

2. Selecione o balanceador de carga para ativar os dados iniciais.

3. Clique em Editar.

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

5. Selecione o endereço IP do front-end e a porta que você quer editar. Para ativar dados iniciais do TLS, o protocolo precisa ser HTTPS.

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

7. Clique em Concluído.

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

gcloud

1. Configure o modo de dados iniciais do TLS no proxy HTTPS de destino de um balanceador de carga de aplicativo.

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

   Substitua:

   • TARGET_HTTPS_PROXY: o proxy HTTPS de destino do 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:

• TARGET_HTTPS_PROXY: o proxy HTTPS de destino do balanceador de carga.
• TLS_EARLY_DATA_MODE: STRICT, PERMISSIVE, DISABLED ou UNRESTRICTED
• FINGERPRINT: uma string codificada em Base64. Uma impressão digital atualizada precisa ser fornecida para corrigir o proxy HTTPS de destino. Caso contrário, a solicitação vai falhar com um código de status HTTP 412 Precondition Failed.

Depois de configurar os dados iniciais do TLS, é possível emitir solicitações de um cliente HTTP que ofereça suporte a dados iniciais do TLS. É possível observar uma latência menor para solicitações retomadas.

Se um cliente não compatível com RFC enviar uma solicitação com um método não idempotente ou com parâmetros de consulta, a solicitação será negada. Você vê um código de status HTTP 425 Early nos registros 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>
  

Gateway da tag do Google para anunciantes

O gateway da tag do Google permite que os proprietários de sites hospedem e implantem tags do Google pelo Google Cloud. Essas tags do Google ajudam a analisar o tráfego no seu site. É possível usar um balanceador de carga de aplicativo externo global para rotear o tráfego de medição no seu site pelo domínio e melhorar a precisão dos dados de medição. Isso fornece dados mais confiáveis para a otimização de campanhas publicitárias.

O gateway da tag do Google só é compatível com balanceadores de carga de aplicativo externos globais. Se você usa um balanceador de carga de aplicativo clássico, migre seus recursos do balanceador de carga de aplicativo clássico para o balanceador de carga de aplicativo externo global.

A configuração e o gerenciamento do gateway da tag do Google são gerenciados fora do console do Google Cloud . É necessário configurar esse recurso usando a interface do Google Tag Manager.

• No console do Google Cloud , a página Detalhes do balanceador de carga mostra um indicador visual somente leitura que mostra que o gateway da tag do Google está ativado.
• Não é possível editar ou excluir a configuração do gateway da tag do Google no console doGoogle Cloud .

Para instruções completas sobre como configurar o gateway da tag do Google para anunciantes, consulte Configurar o gateway da tag do Google para anunciantes.

Embora a configuração seja gerenciada com o Google Ads, o processamento de solicitações e as injeções de tags do Google realizadas pelo gateway são registrados na geração de registros e no monitoramento do balanceador de carga de aplicativo externo global. Para mais informações, consulte Geração de registros e monitoramento do balanceador de carga de aplicativo externo global.

Para saber como resolver problemas com gateways da tag do Google, consulte Resolver problemas de injeção de gateway da tag do Google.

Se você tiver problemas durante a configuração que não podem ser resolvidos com a documentação, entre em contato com o suporte do Google Ads.

Limitações

• Os balanceadores de carga HTTPS não enviam um alerta de encerramento close_notify ao encerrar conexões SSL. Ou seja, o balanceador de carga fecha a conexão TCP em vez de realizar um encerramento de SSL.

• Os balanceadores de carga HTTPS aceitam apenas caracteres minúsculos em domínios em um atributo de nome comum (CN) ou um atributo de nome alternativo do assunto (SAN) do certificado. Os certificados com caracteres maiúsculos em domínios são retornados somente quando definidos como o certificado principal no proxy de destino.

• Os balanceadores de carga HTTPS não usam a extensão de indicação de nome do servidor (SNI, na sigla em inglês) ao se conectar ao back-end, exceto para balanceadores de carga com back-ends de NEG da Internet. Saiba mais em Criptografia do balanceador de carga nos back-ends.

• OGoogle Cloud não garante que uma conexão TCP subjacente possa permanecer aberta durante todo o valor do tempo limite do serviço de back-end. Os sistemas clientes precisam implementar a lógica de nova tentativa em vez de depender que uma conexão TCP permaneça aberta por períodos longos.

• Ao criar um balanceador de carga de aplicativo externo regional no nível Premium usando o console doGoogle Cloud , apenas regiões que aceitam o nível Standard estão disponíveis no console do Google Cloud . Para acessar outras regiões, use a CLI gcloud ou a API.

• Os proxies do GFE usados pelos balanceadores de carga de aplicativo globais e clássicos não são compatíveis com respostas antecipadas 200 OK enviadas antes que o payload POST da solicitação seja totalmente encaminhado por proxy para o back-end. O envio de uma resposta 200 OK antecipada faz com que o GFE feche a conexão com o back-end.

  O back-end precisa responder com respostas 100 Continue depois que os cabeçalhos da solicitação forem recebidos e, em seguida, aguardar até que o payload POST da solicitação tenha sido totalmente encaminhado por proxy antes de responder com o código de resposta 200 OK final.

• Ao usar balanceadores de carga de aplicativo externos regionais com o Cloud Run em um ambiente de VPC compartilhada, as redes VPC independentes em projetos de serviço podem enviar tráfego para qualquer outro serviço do Cloud Run implantado em qualquer outro projeto de serviço no mesmo ambiente de VPC compartilhada. Esse é um problema conhecido.

• O Cloud CDN permite forçar um objeto ou conjunto de objetos a ser ignorado pelo cache solicitando uma invalidação de cache. Por padrão, quando você usa um balanceador de carga de aplicativo externo global com a referência de serviço entre projetos da VPC compartilhada, os administradores do projeto de serviço não têm as permissões necessárias para solicitar invalidações de cache. Isso ocorre porque a invalidação de cache é configurada no projeto de front-end, ou seja, no projeto que tem a regra de encaminhamento, o proxy de destino e o mapa de URL do balanceador de carga. Assim, as invalidações de cache só podem ser emitidas por principais que tenham os papéis do IAM necessários para configurar os recursos relacionados ao balanceador de carga nos projetos de front-end (por exemplo, o papel de administrador de rede do Compute). Os administradores de serviços, que controlam o provisionamento dos serviços de back-end em um projeto separado, precisam trabalhar com o administrador do balanceador de carga do projeto de front-end para emitir a invalidação de cache para os serviços entre projetos.

• Ao usar um balanceador de carga de aplicativo clássico, o balanceador de carga adiciona automaticamente um cabeçalho HTTP Content-Length: 0 às solicitações DELETE por HTTP/1.1 e HTTP/2, mesmo que a solicitação original não tenha especificado um tamanho de conteúdo. Esse comportamento pode fazer com que as políticas de segurança do Cloud Armor bloqueiem essas solicitações se a política estiver configurada para filtrar ou rejeitar solicitações que contenham um cabeçalho "content-length". Esse problema é específico de um balanceador de carga de aplicativo clássico e não ocorre com solicitações GET ou HEAD.

A seguir

• Para saber como os balanceadores de carga de aplicativo externos processam conexões, roteiam o tráfego e mantêm a afinidade da sessão, consulte Distribuição de solicitações para balanceadores de carga de aplicativo externos.

• Para saber como implantar um balanceador de carga de aplicativo externo global, consulte Como configurar um balanceador de carga de aplicativo externo com um back-end do Compute Engine.

• Para saber como implantar um balanceador de carga de aplicativo externo regional, consulte Como configurar um balanceador de carga de aplicativo externo regional com um back-end do Compute Engine.

• Se você já for usuário do balanceador de carga de aplicativo clássico, revise a Visão geral de migração ao planejar uma nova implantação com o balanceador de carga de aplicativo externo global.

• Para saber como automatizar a configuração do balanceador de carga de aplicativo externo com o Terraform, consulte Exemplos de módulo do Terraform para balanceadores de carga de aplicativo externos.

• Para saber como configurar recursos avançados de gerenciamento de tráfego disponíveis com o balanceador de carga externo de aplicativos global, consulte Visão geral do gerenciamento de tráfego para balanceadores de carga de aplicativo externos globais.

• Para saber como configurar recursos avançados de gerenciamento de tráfego disponíveis com o balanceador de carga de aplicativo externo regional, consulte Visão geral do gerenciamento de tráfego para balanceadores de carga de aplicativo externos regionais.

• Saiba mais sobre como exibir sites em Como exibir sites.

• Para encontrar os locais dos PoPs do Google, consulte locais do GFE.

• Saiba mais sobre o gerenciamento de capacidade em Tutorial sobre gerenciamento de capacidade com balanceamento de carga e Otimizações de capacidade de aplicativo com balanceamento de carga global.

• Para saber como usar o Gerenciador de Certificados para provisionar e gerenciar certificados SSL, consulte a Visão geral do Gerenciador de Certificados.

• Para inserir lógica personalizada no caminho de dados de balanceamento de carga, configure plug-ins ou chamadas de Service Extensions.

• Somente para balanceadores de carga de aplicativo externos regionais, use a descoberta de APIs Shadow da Apigee para encontrar APIs Shadow (também conhecidas como APIs não documentadas) na sua infraestrutura doGoogle Cloud . Leia as limitações associadas antes de ativar a Descoberta de API Shadow.