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 global da camada 7 baseado em proxy que permite executar e escalonar 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 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.
• 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 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.

Identificar o modo

   gcloud compute forwarding-rules describe FORWARDING_RULE_NAME
   

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 URLs para tomar decisões de roteamento de tráfego. O proxy também pode autenticar comunicações usando certificados SSL.

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

• O proxy HTTP(S) usa um mapa de URLs para fazer a determinação do roteamento com base em atributos HTTP, como caminho de solicitação, cookies ou cabeçalhos. Com base na decisão de roteamento, o proxy encaminha as solicitações do cliente para serviços ou buckets de back-end específicos. O mapa de URLs pode especificar outras ações, como o envio de redirecionamentos para 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 de seus back-ends. Isso reduz o risco de que solicitações sejam enviadas para back-ends que não podem 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.

Regional

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

Sub-rede somente proxy

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

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 regional externo do aplicativo 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.

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

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 proxy de destino, mapa de URL e um ou mais serviços de back-end.

Especificação de endereço IP. Cada regra de encaminhamento fornece um único endereço IP que pode ser usado em registros DNS do aplicativo. Não é necessário nenhum balanceamento de carga baseado no DNS. É possível especificar o endereço IP 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 de endereço IP, porta e protocolo seja exclusiva 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á.

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.

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 URLs para determinar como rotear o tráfego para os back-ends.

Não espere que o proxy mantenha a capitalização dos nomes de cabeçalho de solicitação ou resposta. Por exemplo, um cabeçalho de resposta Server: Apache/1.0 pode aparecer no cliente como server: Apache/1.0.

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

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 solicitação e resposta 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 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 existente:

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

Remover valores de cabeçalho atuais 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 cliente e o endereço IP do balanceador de carga.

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

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 HTTP reverso, ele poderá anexar um ou os dois endereços IP a seguir ao final do cabeçalho X-Forwarded-For:

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

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

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

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

Suporte do Cloud Trace

O rastreamento 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 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 qualquer solicitação que não corresponda a uma regra de host ou de correspondência de caminho especificada.

Em algumas situações, como o exemplo de balanceamento de carga entre regiões, é possível não definir nenhuma regra de URL e depender apenas do serviço padrão.

Os mapas de URL oferecem suporte a vários recursos avançados de gerenciamento de tráfego, como direcionamento de tráfego com base em cabeçalho, divisão de tráfego com base em peso e espelhamento de solicitações. 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.

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 destinos de HTTPS: certificados SSL do Compute Engine e Gerenciador de certificados. Para uma descrição de cada configuração, consulte Métodos de configuração de certificado nas informações gerais dos certificados SSL.

• Google 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 na visão geral 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.

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 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 do serviço de back-end são usados pelos balanceadores de carga de aplicativo externos:

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 não usa TLS
• HTTPS, que usa HTTP/1.1 e TLS
• HTTP/2, que usa HTTP/2 e TLS (o HTTP/2 sem criptografia não é compatível).
• 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 do serviço de back-end especificado para se comunicar com os back-ends. O balanceador de carga não vai recorrer a 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 ao 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 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 os balanceadores de carga de aplicativo externos em cada modo.

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 de balanceador de carga de aplicativo externo global, o seguinte se aplica:

• As instâncias de back-end (para back-ends de grupos 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 ser 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 ser 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 no mesmo projeto que o balanceador de carga.

Para back-ends de balanceadores de carga de aplicativo regionais externos, 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 da 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 ou endpoints de back-end.

• A rede VPC do back-end e a rede VPC da regra de encaminhamento precisam ser spokes VPC conectados ao mesmo hub do Network Connectivity Center. 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 ou endpoints de back-end.

• 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 não nic0 (vNICs ou interfaces de rede dinâmicas), use back-ends 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 em vez disso. 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.

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 os 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 da 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:

Suporte do GKE

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

• Os gateways externos criados com 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.

• As entradas externas criadas usando o controlador de Entrada do GKE são sempre balanceadores de carga de aplicativo clássicos. O controlador de Ingress do GKE prefere usar back-ends de NEG zonal GCE_VM_IP_PORT, mas também aceita back-ends de grupo de instâncias.

• É 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 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 estiver familiarizado 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.

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 de 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.

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 referenciar serviços de back-end ou buckets de back-end de qualquer projeto na mesma organização. Não há restrições de rede VPC. Embora seja possível usar um ambiente de VPC compartilhada para configurar uma implantação entre projetos como 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 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 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 de 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 front-end e o mapa de URL 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 precisam 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.

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.

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 a VPC compartilhada e é compatível apenas com balanceadores de carga de aplicativo globais externos.

Para saber mais sobre essa configuração, consulte Configurar referências 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. Isso é feito criando 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.

Suporte a HTTP/2

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

• HTTP/2 por TLS
• Texto não criptografado HTTP/2 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 SSL 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. Para mais informações, consulte 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 cargaGoogle 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. 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.

Limitações do HTTP/2

• O HTTP/2 entre o balanceador de carga e a instância pode exigir muito mais conexões TCP com a instância do que o HTTP ou 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 a execução do protocolo WebSocket em um único stream de uma conexão HTTP/2 (RFC 8441).
• 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 Google Cloud API ou no console Google Cloud . Se o endpoint do gRPC retornar um erro, os registros do balanceador de carga e os dados de monitoramento vão reportar o código de status HTTP 200 OK.

Texto não criptografado HTTP/2 sobre TCP (H2C)

O HTTP/2 em texto simples via TCP, também conhecido como H2C, permite usar o HTTP/2 sem TLS. O H2C é compatível com as seguintes conexões:

• Conexões entre clientes e o balanceador de carga. Nenhuma configuração especial é necessária.

• Conexões entre o balanceador de carga e os back-ends.

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

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

O H2C não é compatível com balanceadores de carga de aplicativo clássicos.

Suporte a HTTP/3

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

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 de aplicativo criada com base no IETF QUIC e depende do QUIC para lidar com multiplexação, controle de congestionamento, detecção de perdas e 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 de páginas da Web, reduzir o armazenamento em buffer de vídeo e melhorar a capacidade 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.

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"

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 aceitas pelo 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 o 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 nã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.

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

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

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

{
  "quicOverride": QUIC_SETTING
}

Suporte a WebSocket

Google Cloud Os balanceadores de carga baseados em HTTP(S) oferecem suporte ao protocolo WebSocket quando você usa HTTP ou HTTPS como protocolo para o back-end. O balanceador de carga não exige 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 a RFC 6455.

O protocolo WebSocket funciona da seguinte maneira:

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

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

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 Google Cloud , é necessário enviar solicitações de proxy completas pelo HTTP/2. Para fazer isso, crie um balanceador de carga de aplicativo com uma das seguintes configurações:

• Para tráfego não criptografado de ponta a ponta (sem TLS): crie um balanceador de carga HTTP (configurado com um proxy HTTP de destino). 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.

• Para tráfego criptografado de ponta a ponta (com TLS): crie 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, verifique se os back-ends podem processar o tráfego TLS e configure o balanceador de carga para usar HTTP/2 em conexões criptografadas entre o balanceador de carga e os back-ends definindo o protocolo do 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 representar as 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 o HTTP/2 com o Cloud Run, consulte Usar HTTP/2 por trás de 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 saber mais sobre as limitações do HTTP/2, consulte Limitações do HTTP/2.

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 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 para 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 se autentiquem mutuamente, verificando se cada um tem um certificado válido emitido por uma autoridade de certificação (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 oferecem suporte a 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 para dados iniciais do TLS 1.3

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 ida e volta zero (0-RTT), que podem melhorar o desempenho do aplicativo em 30 a 50% para conexões retomadas.

Com o TLS 1.2, são necessárias duas viagens de ida e volta 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 retorno 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 reduzir os riscos de repetição.

Como os dados iniciais são enviados antes da conclusão do handshake, um invasor pode tentar capturar e reproduzir solicitações. Para mitigar isso, o servidor de back-end precisa controlar cuidadosamente o uso de dados iniciais, limitando-o a solicitações idempotentes. Os métodos HTTP que devem ser idempotentes, mas 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 de dados iniciais HTTP 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 antecipados do TLS 1.3 para solicitações com métodos HTTP seguros (GET, HEAD, OPTIONS e 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 permite dados iniciais do TLS 1.3 para solicitações com métodos HTTP seguros (GET, HEAD, OPTIONS, 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 não intencionais, 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 envio é rejeitada. Se os aplicativos não estiverem equipados para processar solicitações de dados antecipados com segurança, desative os dados antecipados. O TLS 1.3 Early Data está desativado 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 antecipados do TLS, faça o seguinte:

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

Depois de configurar os dados iniciais do TLS, você pode emitir solicitações de um cliente HTTP que ofereça suporte a esses dados. Você pode 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>
  

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 executar um encerramento SSL.

• Os balanceadores de carga HTTPS são compatíveis apenas com 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 para os back-ends.

• Google 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 consoleGoogle Cloud , apenas regiões que aceitam o nível Standard estão disponíveis no console 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 encerre a conexão com o back-end.

  Seu back-end precisa responder com respostas 100 Continue depois que os cabeçalhos da solicitação forem recebidos e aguardar até que o payload POST da solicitação seja totalmente transmitido 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 para configurar 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.

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, consulte Visão geral da 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 frases de destaque das extensões de serviço.

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