Visão geral do balanceador de carga interno do aplicativo

Neste documento, apresentamos os conceitos que você precisa entender para configurar balanceadores de carga de aplicativo internos.

Um balanceador de carga de aplicativo interno do Google Cloud é um balanceador de carga de camada 7 baseado em proxy que permite a execução e o escalonamento dos serviços protegidos por um endereço IP interno. O balanceador de carga de aplicativo interno distribui o tráfego HTTP e HTTPS aos back-ends hospedados em várias plataformas do Google Cloud, como o Compute Engine, o Google Kubernetes Engine (GKE) e o Cloud Run. Veja detalhes em Casos de uso.

Modos de operação

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

  • Balanceador de carga de aplicativo interno entre regiões. Trata-se de um balanceador de carga multirregional que é implementado como um serviço gerenciado, baseado no proxy Envoy de código aberto. O modo entre regiões permite balancear a carga do tráfego para serviços de back-end distribuídos globalmente, incluindo o gerenciamento de tráfego, que garante que o tráfego seja direcionado para o back-end mais próximo. Esse balanceador de carga também possibilita a alta disponibilidade. Colocar back-ends em várias regiões ajuda a evitar falhas em uma única região. Se os back-ends de uma região estiverem inativos, o tráfego poderá fazer failover para outra região.

  • Balanceador de carga de aplicativo interno regional. Esse é um balanceador de carga regional que é implementado como um serviço gerenciado no proxy Envoy de código aberto. O modo regional garante que todos os clientes e back-ends sejam de uma região específica, o que ajuda quando você precisa de conformidade regional. Esse balanceador de carga é ativado com recursos avançados de controle de tráfego com base em parâmetros HTTP(S). Depois que o balanceador de carga é configurado, ele aloca proxies Envoy automaticamente para atender às suas necessidades de tráfego.

    A seguinte tabela descreve diferenças importantes entre os modos regional e entre regiões:

    Engenharia de Balanceador de carga de aplicativo interno entre regiões Balanceador de carga de aplicativo interno regional
    Endereço IP virtual (VIP) do balanceador de carga. Alocação por meio de uma sub-rede em uma região específica do Google Cloud.

    Endereços VIP de várias regiões podem compartilhar o mesmo serviço de back-end global. É possível configurar o balanceamento de carga global baseado em DNS usando políticas de roteamento de DNS a fim de encaminhar solicitações de clientes para o endereço VIP mais próximo.

    		 Alocação por meio de uma sub-rede em uma região específica do Google Cloud.
    Acesso de cliente Sempre acessível globalmente. Clientes de qualquer região do Google Cloud em uma VPC podem enviar tráfego para o balanceador de carga. Por padrão, não é acessível globalmente.
    Como opção, é possível ativar o acesso global.
    Back-ends com carga balanceada Back-ends globais.
    O balanceador de carga pode enviar tráfego para back-ends em qualquer região.    		 Back-ends regionais.
    O balanceador de carga só pode enviar tráfego para back-ends que estejam na mesma região que o proxy associado a ele.
    Alta disponibilidade e failover Failover automático em back-ends íntegros na mesma região ou em regiões diferentes. Failover automático em back-ends íntegros na mesma região.

Identificar o modo

console do Cloud

  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 tipo do balanceador de carga, o protocolo e a região. Se a região estiver em branco, o balanceador de carga estará no modo entre regiões. Veja 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 interno regional Aplicativo Internos Especifica uma região
    Balanceador de carga de aplicativo interno entre regiões Aplicativo Internos

gcloud

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

    gcloud compute forwarding-rules describe FORWARDING_RULE_NAME

    Na saída do comando, verifique o esquema de balanceamento de carga, a região e o nível 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
    Balanceador de carga de aplicativo interno entre regiões INTERNAL_MANAGED Global
    Balanceador de carga de aplicativo interno regional INTERNAL_MANAGED Regional

Arquitetura e recursos

O diagrama a seguir mostra os recursos do Google Cloud necessários para balanceadores de carga de aplicativo internos:

Entre regiões

Este diagrama mostra os componentes de uma implantação de balanceador de carga de aplicativo interno entre regiões no nível Premium na mesma rede VPC. Cada regra de encaminhamento global conta com um endereço IP regional que os clientes usam para se conectar.

Componentes de um balanceador de carga de aplicativo interno entre regiões.
Componentes de um balanceador de carga de aplicativo interno entre regiões (clique para ampliar).

Regional

Este diagrama mostra os componentes de uma implantação de balanceador de carga de aplicativo interno regional no nível Premium.

Componentes de um balanceador de carga de aplicativo interno regional.
Componentes de um balanceador de carga de aplicativo interno regional (clique para ampliar).

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

Sub-rede somente proxy

No diagrama acima, 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 HTTP(S) internos.

A seguinte tabela descreve as diferenças entre as sub-redes somente proxy nos modos regional e entre regiões:

Modo balanceador de carga Valor da flag de sub-rede somente proxy --purpose
Balanceador de carga de aplicativo interno entre regiões

GLOBAL_MANAGED_PROXY

Balanceadores de carga regionais e entre regiões não podem compartilhar as mesmas sub-redes

O balanceador de carga entre regiões baseado no Envoy precisa ter uma sub-rede somente proxy em cada região em que está configurado. Os proxies do balanceador de carga entre regiões na mesma região e rede compartilham a mesma sub-rede somente proxy.
Balanceador de carga de aplicativo interno regional

REGIONAL_MANAGED_PROXY

Balanceadores de carga regionais e entre regiões não podem compartilhar as mesmas sub-redes

Todos os balanceadores de carga regionais baseados no Envoy em uma região e rede VPC compartilham a 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 interno em uma região e rede VPC recebem conexões da sub-rede somente proxy.
  • O endereço IP virtual de um balanceador de carga de aplicativo interno não está localizado na sub-rede somente proxy. O endereço IP do balanceador de carga é definido pela regra de encaminhamento gerenciada interna, descrita abaixo.

Regra de encaminhamento e endereço 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 e serviço de back-end.

Especificação de endereço IP. Cada regra de encaminhamento referencia um endereço IP regional único que pode ser usado nos registros DNS do aplicativo. É possível reservar um endereço IP estático que possa ser usado ou permitir que o Cloud Load Balancing atribua um para você. Recomendamos reservar um endereço IP estático. Caso contrário, será necessário atualizar o registro DNS com o endereço IP temporário recém-atribuído sempre que uma regra de encaminhamento for excluída e uma nova for criada.

Os clientes usam o endereço IP e a porta para se conectar aos proxies do Envoy relativos ao balanceador de carga. O endereço IP da regra de encaminhamento é o endereço IP do balanceador de carga, que é chamado frequentemente de endereço IP virtual ou VIP. Os clientes que se conectam a um balanceador de carga precisam usar a versão 1.1 ou posterior do HTTP. Para ver a lista completa dos protocolos compatíveis, consulte Recursos do balanceador de carga.

O endereço IP interno associado à regra de encaminhamento pode ser proveniente de uma sub-rede na mesma rede e região que os back-ends.

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 interno (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 usados por balanceadores de carga de aplicativo internos dependem do modo do balanceador de carga.

Modo balanceador de carga Regra de encaminhamento, endereço IP e sub-rede somente proxy --purpose Roteamento do cliente para o front-end do balanceador de carga
Balanceador de carga de aplicativo interno entre regiões

Regra de encaminhamento global

Endereços IP regionais

Esquema de balanceamento de carga:

INTERNAL_MANAGED

Sub-rede somente proxy --purpose:

GLOBAL_MANAGED_PROXY

Endereço IP --purpose:

SHARED_LOADBALANCER_VIP

O acesso global é ativado por padrão para permitir que clientes de qualquer região em uma VPC acessem o balanceador de carga. Os back-ends podem estar em várias regiões.
Balanceador de carga de aplicativo interno regional

Regra de encaminhamento regional

Endereço IP regional

Esquema de balanceamento de carga:

INTERNAL_MANAGED

Sub-rede somente proxy --purpose:

REGIONAL_MANAGED_PROXY

Endereço IP --purpose:

SHARED_LOADBALANCER_VIP

É possível ativar o acesso global para permitir que clientes de qualquer região em uma VPC acessem o balanceador de carga. Os back-ends também precisam estar na mesma região que o 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 interno entre regiões

Balanceador de carga de aplicativo interno regional

Os endereços IPv4 internos regionais sempre existem dentro das redes VPC. Ao criar a regra de encaminhamento, é necessário especificar a sub-rede de onde o endereço IP interno é 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.

Proxy de destino

Um proxy HTTP(S) de destino encerra as conexões HTTP(S) dos clientes. O proxy HTTP(S) consulta o mapa de URLs para determinar como rotear o tráfego para os back-ends. Um proxy HTTPS de destino usa um certificado SSL para fazer a autenticação para os clientes.

O balanceador de carga preserva o cabeçalho Host da solicitação original do cliente. O balanceador de carga também anexa dois endereços IP ao cabeçalho X-Forwarded-For:

  • O endereço IP do cliente que se conecta ao balanceador de carga
  • O endereço IP da regra de encaminhamento do balanceador de carga

Se não houver nenhum cabeçalho X-Forwarded-For na solicitação recebida, esses dois endereços IP serão o valor inteiro do cabeçalho. Se a solicitação tiver um cabeçalho X-Forwarded-For, outras informações, como os endereços IP registrados por proxies no caminho até o balanceador de carga, serão preservadas antes dos dois endereços IP. O balanceador de carga não verifica endereços IP que precedem os dois últimos endereços IP nesse cabeçalho.

Se você estiver executando um proxy como servidor de back-end, esse proxy normalmente anexará mais informações ao cabeçalho X-Forwarded-For, e o software poderá precisar considerar isso. As solicitações por proxy do balanceador de carga vêm de um endereço IP na sub-rede somente proxy, e seu proxy na instância de back-end pode registrar esse endereço e o endereço IP da própria instância.

Dependendo do tipo de tráfego que o aplicativo precisa processar, é possível configurar um balanceador de carga com um proxy HTTP ou HTTPS de destino.

A tabela a seguir mostra as APIs de proxy de destino exigidas pelos balanceadores de carga de aplicativo internos:

Modo balanceador de carga Proxy de destino
Balanceador de carga de aplicativo interno entre regiões
Balanceador de carga de aplicativo interno regional

Certificados SSL

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

A seguinte tabela especifica o tipo de certificados SSL exigidos pelos balanceadores de carga de aplicativo internos em cada modo:

Modo balanceador de carga Tipo de certificado SSL
Balanceador de carga de aplicativo interno regional

Certificados SSL regionais do Compute Engine

Certificados gerenciados pelo Google e certificados autogerenciados regionais do gerenciador de certificados.

Os seguintes tipos de certificados gerenciados pelo Google são compatíveis com o gerenciador de certificados:

Não há suporte para certificados gerenciados pelo Google com autorização do balanceador de carga.
Balanceador de carga de aplicativo interno entre regiões

Certificados gerenciados pelo Google e certificados autogerenciados do gerenciador de certificados.

Os seguintes tipos de certificados gerenciados pelo Google são compatíveis com o gerenciador de certificados:

Não há suporte para certificados gerenciados pelo Google com autorização do balanceador de carga.

Os certificados SSL do Compute Engine não são compatíveis.

Mapas de URL

O proxy HTTP(S) de destino usa mapas 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 regionais específicos. O mapa de URL pode especificar outras ações a serem tomadas, como regravar cabeçalhos, enviar redirecionamentos a clientes e configurar políticas de tempo limite, entre outras.

A seguinte tabela especifica o tipo de mapa de URL exigido pelos balanceadores de carga de aplicativo internos em cada modo:

Modo balanceador de carga Tipo de mapa de URL
Balanceador de carga de aplicativo interno entre regiões Mapas de URLs globais
Balanceador de carga de aplicativo interno regional Mapas de URLs regionais

Serviço de back-end

Um serviço de back-end fornece informações de configuração ao balanceador de carga para 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.

Escopo do serviço de back-end

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

Modo balanceador de carga Recurso de serviço de back-end
Balanceador de carga de aplicativo interno entre regiões backendServices (global)
Balanceador de carga de aplicativo interno 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 não 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.

O balanceador de carga só usa o protocolo de serviço de back-end especificado para se comunicar com os back-ends. O balanceador de carga não recorre 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 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).

Back-ends

A tabela a seguir especifica os recursos de back-end compatíveis com os balanceadores de carga de aplicativo internos em cada modo.


Modo do balanceador de carga 		Back-ends compatíveis em um serviço de back-end* Compatível com intervalos de back-end Compatível com o Google Cloud Armor Compatível com Cloud CDN. Compatível com o IAP Compatível com extensões de serviço
Grupos de instâncias† NEGs por zona‡ NEGs na Internet NEGs sem servidor NEGs híbridos NEGs do Private Service Connect
Balanceador de carga de aplicativo interno entre regiões
Cloud Run
Balanceador de carga de aplicativo interno regional
Cloud Run

* 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 e híbridos GCE_VM_IP_PORT podem ser usados no mesmo serviço de back-end para oferecer suporte a uma arquitetura híbrida.

† Combinações de grupos de instâncias não gerenciadas, gerenciadas por zona e gerenciadas por região são compatíveis com o mesmo serviço de back-end. Ao usar o escalonamento automático para 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.

‡ Os 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 back-end.

  • 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. Esse recurso está em Pré-lançamento. 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 no 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.

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 várias placas de rede (NIC), 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.

Subconfiguração de back-ends

A subconfiguração de back-end é um recurso opcional compatível com balanceadores de carga de aplicativo internos regionais que melhora o desempenho e a escalonabilidade por meio da atribuição de um subconjunto de back-ends a cada uma das instâncias de proxy.

Por padrão, a subconfiguração de back-end fica desativada. Para informações sobre como ativar esse recurso, consulte Subagrupamento de back-end para o balanceador de carga interno do aplicativo.

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 em si está funcionando.

Para realizar sondagens de verificação de integridade com sucesso, é necessário criar uma regra de firewall de permissão do Ingress que permita que as sondagens de verificação de integridade acessem 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. No entanto, para NEGs híbridos, as verificações de integridade são originadas na sub-rede somente proxy. Para detalhes, consulte as verificações de integridade distribuídas do Envoy na 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 internos 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 internos:

Modo balanceador de carga Tipo de verificação de integridade
Balanceador de carga de aplicativo interno entre regiões Global
Balanceador de carga de aplicativo interno regional Regional

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

Regras de firewall

Um balanceador de carga de aplicativo interno requer as seguintes regras de firewall:

Há algumas exceções aos requisitos de regras de firewall para esses intervalos:

  • Não é necessário adicionar intervalos de sondagem de verificação de integridade do Google à lista de permissões 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 usar lista de permissões dos intervalos de sondagem de verificação de integridade do Google para NEGs zonais.
  • Para NEGs regionais da Internet, as verificações de integridade são opcionais. O tráfego de balanceadores de carga que usam NEGs regionais da Internet é proveniente da sub-rede somente proxy e, em seguida, é convertido por NAT (usando o Cloud NAT) para endereços IP NAT alocados automaticamente ou manualmente. Esse tráfego inclui sondagens de verificação de integridade e solicitações de usuários do balanceador de carga aos back-ends. Para detalhes, consulte NEGs regionais: usar o Cloud NAT para saída.

Acesso de cliente

Os clientes podem estar na mesma rede ou em uma rede VPC conectada usando o peering de rede VPC.

Para balanceadores de carga de aplicativo internos entre regiões, o acesso global é ativado por padrão. Clientes de qualquer região em uma VPC podem acessar seu balanceador de carga.

Para balanceadores de carga de aplicativo internos regionais, os clientes precisam estar, por padrão, na mesma região que o balanceador de carga. É possível ativar o acesso global para permitir que clientes de qualquer região em uma VPC acessem o balanceador de carga.

A seguinte tabela resume o acesso do cliente para balanceadores de carga de aplicativo internos regionais:

Acesso global desativado Acesso global ativado
Os clientes precisam estar na mesma região que o balanceador de carga. Também precisam estar na mesma rede VPC do balanceador de carga ou em uma conectada à do balanceador usando o peering da rede VPC. Os clientes podem estar em qualquer região. Ainda precisam estar na mesma rede VPC do balanceador de carga ou em uma conectada à do balanceador usando peering da rede VPC.
Os clientes locais podem acessar o balanceador de carga por meio de túneis VPN do Cloud ou anexos da VLAN. Esses túneis ou anexos precisam estar na mesma região do balanceador de carga. Os clientes locais podem acessar o balanceador de carga por meio de túneis VPN do Cloud ou anexos da VLAN. Esses túneis ou anexos podem estar em qualquer região.

Suporte ao GKE

O GKE usa balanceadores de carga de aplicativo internos da seguinte maneira:

  • As gateways internas criadas usando o controlador de gateway do GKE podem usar qualquer modo de um balanceador de carga de aplicativo interno. Você controla o modo do balanceador de carga escolhendo uma GatewayClass. O controlador do Gateway do GKE sempre usa back-ends de NEG zonal GCE_VM_IP_PORT.

  • As entradas internas criadas usando o controlador de Entrada do GKE são sempre balanceadores de carga de aplicativo internos regionais. O controlador de Ingress do GKE sempre usa back-ends de NEG zonal GCE_VM_IP_PORT.

Arquiteturas de VPC compartilhada

Os balanceadores de carga de aplicativo internos 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 que eles possam se comunicar uns com os outros com segurança e eficiência usando IPs internos dessa rede. Se você ainda não estiver familiarizado com a VPC compartilhada, leia a documentação de visão geral da VPC compartilhada.

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

Sub-redes e endereço IP Componentes de front-end Componentes de back-end

Crie a rede e as sub-redes necessárias (incluindo a sub-rede somente proxy) no projeto host da VPC compartilhada.

O endereço IP interno do balanceador de carga pode ser definido no projeto host ou em um projeto de serviço, mas precisa usar uma sub-rede na rede VPC compartilhada desejada no host projeto. O endereço vem do intervalo de IP principal da sub-rede referenciada.

 O endereço IP interno 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 dex 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 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 dão suporte a esse tipo de implantação.

O balanceador de carga usa endereços IP e sub-redes a partir do projeto host. Os clientes poderão acessar um balanceador de carga de aplicativo interno se estiverem na mesma região e rede VPC compartilhada que ele. Os clientes podem estar no projeto host, em um projeto de serviço anexado ou em qualquer rede conectada.

Balanceador de carga de aplicativo interno na rede VPC compartilhada
Balanceador de carga de aplicativo interno na rede VPC compartilhada

Back-ends sem servidor em um ambiente de VPC compartilhada

Para um balanceador de carga de aplicativo interno que esteja usando um back-end NEG sem servidor, o serviço de backup do Cloud Run precisa estar no mesmo projeto de serviço que o serviço de back-end e o NEG sem servidor. Os componentes do front-end do balanceador de carga (regra de encaminhamento, proxy de destino, mapa de URL) podem ser criados no projeto host, no mesmo projeto de serviço dos componentes de back-end ou em qualquer outro projeto de serviço no mesmo ambiente de VPC compartilhada.

Referência de serviço entre projetos

A referência de serviços 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 um projeto diferente.

A referência de serviços entre projetos permite que as organizações configurem um balanceador de carga central e direcionem 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).

Para balanceadores de carga de aplicativo internos, a referência de serviço entre projetos só é possível em ambientes de VPC compartilhada.

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

Limitações conhecidas com referências a serviços entre projetos

  • Não será possível referenciar um serviço de back-end entre projetos se ele tiver back-ends de NEG da Internet regionais. Há suporte para todos os outros tipos de back-end.
  • O Google 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.

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

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 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 compute.loadBalancerServiceUser do IAM 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 do balanceador de carga e mapa de URL no projeto de serviço
Front-end e balanceador de carga do balanceador de carga em projetos de serviço diferentes

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 precisarão de acesso aos serviços de back-end nos projetos de serviço. Os administradores do projeto de serviço concedem o papel compute.loadBalancerServiceUser do IAM 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.
Front-end do balanceador de carga e mapa de URL no projeto host (clique para ampliar).

Tempo limite e tentativas

Os balanceadores de carga de aplicativo interno são compatíveis com os seguintes tipos de tempo limite:

Tipo e descrição de tempo limite Valores padrão Compatível com valores personalizados
Entre regiões Regional
Tempo limite do serviço de back-end

Tempo limite de solicitação e resposta. Representa o tempo máximo permitido entre o balanceador de carga enviando o primeiro byte de uma solicitação para o back-end e o back-end retornando o último byte da resposta HTTP para o balanceador de carga. Se o back-end não retornar toda a resposta HTTP ao balanceador de carga dentro desse limite de tempo, os dados de resposta restantes serão descartados.
  • Para NEGs sem servidor em um serviço de back-end: 60 minutos
  • Para todos os outros tipos de back-end em um serviço de back-end: 30 segundos
Tempo limite do sinal de atividade HTTP do cliente

O tempo máximo que a conexão TCP entre um cliente e o proxy Envoy gerenciado do balanceador de carga pode ficar inativa. A mesma conexão TCP pode ser usada para várias solicitações HTTP.

 10 minutos (600 segundos)
Tempo limite do sinal de atividade HTTP do back-end

O tempo máximo que a conexão TCP entre o proxy Envoy gerenciado do balanceador de carga e um back-end pode ficar inativa. A mesma conexão TCP pode ser usada para várias solicitações HTTP.

 10 minutos (600 segundos)

Tempo limite do serviço de back-end

O tempo limite do serviço de back-end configurável representa o tempo máximo que o balanceador de carga aguarda até o back-end processar uma solicitação HTTP e retornar a resposta HTTP correspondente. Exceto para NEGs sem servidor, o valor padrão do tempo limite do serviço de back-end é de 30 segundos.

Por exemplo, se você quiser fazer o download de um arquivo de 500 MB e o valor do tempo limite do serviço de back-end for de 90 segundos, o balanceador de carga aguardará o back-end enviar todo o arquivo de 500 MB em até 90 segundos. É possível configurar o tempo limite do serviço de back-end como insuficiente para que o back-end envie a resposta HTTP completa. Nessa situação, se o balanceador de carga tiver recebido do back-end pelo menos os cabeçalhos de resposta HTTP, ele retornará os cabeçalhos completos e o máximo possível do corpo de resposta dentro do tempo limite do serviço de back-end.

Exceto para WebSockets, defina o tempo limite do serviço de back-end como o período mais longo que você espera ser necessário para o back-end processar uma resposta HTTP. Aumente o tempo limite do serviço de back-end se o software em execução no back-end precisar de mais tempo para processar uma solicitação HTTP e retornar toda a resposta.

O tempo limite do serviço de back-end aceita valores entre 1 e 2,147,483,647 segundos. Valores maiores não são opções de configuração possíveis. O Google Cloud também 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.

Para conexões WebSocket usadas com balanceadores de carga de aplicativo internos, as conexões WebSocket ativas não seguem o tempo limite do serviço de back-end. As conexões WebSocket inativas são fechadas após o tempo limite do serviço de back-end.

Periodicamente, o Google Cloud reinicia ou altera o número de tarefas de software do Envoy em atendimento. Quanto maior o valor do tempo limite do serviço de back-end, maiores as chances de conexões TCP serem encerradas por reiniciações ou substituições de tarefas do Envoy.

Para configurar o tempo limite do serviço de back-end, use um dos seguintes métodos:

Console

Modifique o campo Tempo limite do serviço de back-end do balanceador de carga.

gcloud

Use o comando gcloud compute backend-services update para modificar o parâmetro --timeout do recurso de serviço de back-end.

API

Modifique o parâmetro timeoutSec para o recurso regionBackendServices

Tempo limite do sinal de atividade HTTP do cliente

O tempo limite do sinal de atividade HTTP do cliente representa o tempo máximo em que uma conexão TCP pode ficar inativa entre o cliente (downstream) e um proxy Envoy. O valor padrão do tempo limite de sinal de atividade HTTP do cliente é de 600 segundos. É possível configurar o tempo limite com um valor entre 5 e 600 segundos.

Um tempo limite do sinal de atividade HTTP também é chamado de tempo limite de inatividade do TCP.

O tempo limite do sinal de atividade do cliente HTTP do balanceador de carga precisa ser maior que o tempo limite do sinal de atividade HTTP (TCP inativo) usado por clientes downstream ou proxies. Se um cliente downstream tiver o tempo limite do sinal de atividade HTTP (TCP inativo) maior do que o tempo limite do sinal de atividade HTTP do cliente do balanceador de carga, ocorrerá uma possível disputa. Da perspectiva de um cliente downstream, uma conexão TCP estabelecida pode ficar inativa por mais tempo do que o balanceador de carga permite. Isso significa que o cliente downstream pode enviar pacotes depois que o balanceador de carga considerar a conexão TCP encerrada. Quando isso acontece, o balanceador de carga responde com um pacote de redefinição (RST) TCP.

Tempo limite do sinal de atividade HTTP do back-end

Os balanceadores de carga de aplicativo internos são proxies que usam uma primeira conexão TCP entre o cliente (downstream) e um proxy Envoy e uma segunda conexão TCP entre o proxy Envoy e os back-ends.

As conexões TCP secundárias do balanceador de carga talvez não sejam encerradas após cada solicitação. Elas podem permanecer abertas para lidar com várias solicitações e respostas HTTP. O tempo limite do sinal de atividade HTTP do back-end define o tempo limite de inatividade do TCP entre o balanceador de carga e os back-ends. O tempo limite do sinal de atividade HTTP do back-end não se aplica a WebSockets.

O tempo limite do sinal de atividade do back-end é fixado em 10 minutos (600 segundos) e não pode ser alterado. O tempo limite do sinal de atividade do back-end do balanceador de carga precisa ser menor que o tempo limite do sinal de atividade usado pelo software em execução nos back-ends. Isso evita uma disputa em que o sistema operacional dos back-ends pode encerrar conexões TCP com uma redefinição (RST) TCP. Como o tempo limite do sinal de atividade do back-end do balanceador de carga não é configurável, é necessário configurar o software do back-end para que o valor de tempo limite do sinal de atividade HTTP (TCP inativo) seja maior que 600 segundos.

A tabela a seguir lista as alterações necessárias para modificar os valores de tempo limite do sinal de atividade para software servidor da Web comum.

Software servidor da Web Parâmetro Configuração padrão Configuração recomendada
Apache KeepAliveTimeout KeepAliveTimeout 5 KeepAliveTimeout 620
nginx keepalive_timeout keepalive_timeout 75s; keepalive_timeout 620s;

Novas tentativas

Para configurar novas tentativas, use uma política de nova tentativa no mapa de URL. O número padrão de novas tentativas (numRetries) é 1. O perTryTimeout máximo configurável é de 24 horas.

Sem uma política de nova tentativa, solicitações malsucedidas sem um corpo HTTP (por exemplo, solicitações GET) que resultarem em respostas HTTP 502, 503 ou 504 serão repetidas uma vez.

As solicitações HTTP POST não são repetidas.

As solicitações repetidas geram apenas uma entrada de registro para a resposta final.

Para mais informações, consulte Geração de registros e monitoramento do balanceador de carga interno do aplicativo.

Como acessar redes conectadas

Os clientes podem acessar um balanceador de carga de aplicativo interno na rede VPC de uma rede conectada usando o seguinte:

  • Peering de rede VPC
  • Cloud VPN e Cloud Interconnect

Para exemplos detalhados, consulte Balanceadores de carga de aplicativos internos e redes conectadas.

Failover

Se um back-end não estiver íntegro, o tráfego será redirecionado automaticamente para back-ends íntegros.

A seguinte tabela descreve o comportamento de failover em cada modo:

Modo balanceador de carga Comportamento de failover Comportamento quando nenhum back-end estiver íntegro
Balanceador de carga de aplicativo interno entre regiões

Failover automático para back-ends íntegros na mesma região ou em outras regiões.

O tráfego é distribuído entre back-ends íntegros que abrangem várias regiões com base na distribuição de tráfego configurada.

 Retorna HTTP 503
Balanceador de carga de aplicativo interno regional

Failover automático em back-ends íntegros na mesma região.

O proxy do Envoy envia o tráfego para back-ends íntegros em uma região com base na distribuição de tráfego configurada.

 Retorna HTTP 503

Alta disponibilidade e failover entre regiões

Para balanceadores de carga de aplicativo internos regionais

Para ter alta disponibilidade, implante vários balanceadores de carga de aplicativo internos regionais individuais nas regiões que melhor oferecem suporte ao tráfego do aplicativo. Em seguida, use uma política de roteamento de geolocalização do Cloud DNS para detectar se um balanceador de carga está respondendo durante uma falha regional. Uma política de geolocalização encaminha o tráfego para a próxima região disponível mais próxima com base na origem da solicitação do cliente. A verificação de integridade está disponível por padrão para balanceadores de carga de aplicativo internos.

Para balanceadores de carga de aplicativo internos entre regiões

É possível configurar um balanceador de carga de aplicativo interno entre regiões em várias regiões para ter os seguintes benefícios:

  1. Se o balanceador de carga de aplicativo interno entre regiões falhar em uma região, as políticas de roteamento de DNS vão encaminhar o tráfego para um balanceador de carga de aplicativo interno entre regiões em outra região.

    O exemplo de implantação de alta disponibilidade mostra o seguinte:

    • Um balanceador de carga de aplicativo interno entre regiões com endereço IP virtual (VIP, na sigla em inglês) de front-end nas regiões RegionA e RegionB da rede VPC. Seus clientes estão localizados na região RegionA.
    • É possível tornar o balanceador de carga acessível usando VIPs de front-end de duas regiões e usar políticas de roteamento de DNS para retornar o VIP ideal aos seus clientes. Use as políticas de roteamento de geolocalização se quiser que seus clientes usem o VIP geograficamente mais próximo.
    • As políticas de roteamento de DNS podem detectar se um VIP está ou não respondendo durante uma interrupção regional e retornar o próximo VIP mais ideal aos clientes, garantindo que o aplicativo permaneça ativo mesmo durante interrupções regionais.
    Balanceador de carga de aplicativo interno entre regiões com implantação de alta disponibilidade.
    Balanceador de carga de aplicativo interno entre regiões com uma implantação de alta disponibilidade (clique para ampliar).

  2. Se os back-ends de uma determinada região estiverem inativos, o tráfego do balanceador de carga de aplicativo interno entre regiões fará o failover para os back-ends de outra região normalmente.

    O exemplo de implantação do failover entre regiões mostra o seguinte:

    • Um balanceador de carga de aplicativo interno entre regiões com um endereço VIP de front-end na região RegionA da sua rede VPC. Seus clientes também estão localizados na região RegionA.
    • Um serviço de back-end global que faz referência aos back-ends nas regiões do Google Cloud RegionA e RegionB.
    • Quando os back-ends da região RegionA estão inativos, o tráfego faz o failover para a região RegionB.
    Balanceador de carga de aplicativo interno entre regiões com uma implantação de failover entre regiões.
    Balanceador de carga de aplicativo interno entre regiões com uma implantação de failover entre regiões (clique para ampliar).

Suporte a WebSocket

Os balanceadores de carga baseados em HTTP(S) do Google Cloud oferecem suporte ao protocolo WebSocket quando você usa HTTP ou HTTPS 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 a RFC 6455.

O protocolo WebSocket funciona da seguinte maneira:

  1. O balanceador de carga reconhece uma solicitação Upgrade do WebSocket de um cliente HTTP(S). 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, Upgrade: websocket e outros cabeçalhos de resposta relacionados ao WebSocket.
  3. O balanceador de carga encaminha o tráfego bidirecional durante a duração da conexão atual.

Se a instância de back-end retornar uma resposta de erro com o código de resposta 426 ou 502, o balanceador de carga fechará 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 do Google Cloud, é necessário enviar solicitações de proxy completas pelo HTTP/2. Para fazer isso:

  1. Configure um balanceador de carga HTTPS.
  2. Ative o HTTP/2 como o protocolo do balanceador de carga para os back-ends.

O balanceador de carga negocia o HTTP/2 com clientes como parte do handshake SSL usando a extensão ALPN TLS.

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.

Ative o TLS nos back-ends. Saiba mais em Criptografia do balanceador de carga nos back-ends.

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 usa HTTPS como 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. Ele garante que o cliente e o servidor se autenticam verificando se cada um deles tem um certificado válido emitido por uma autoridade certificadora (AC) 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 mTLS, consulte Autenticação TLS mútua.

Limitações

  • Não há garantia de que uma solicitação de um cliente em uma zona da região seja enviada para um back-end que esteja na mesma zona que o cliente. A afinidade da sessão não reduz a comunicação entre as zonas.

  • Os balanceadores de carga de aplicativo interno não são compatíveis com os seguintes recursos:

  • Um balanceador de carga de aplicativo interno é compatível com HTTP/2 somente por TLS.

  • Os clientes que se conectam a um balanceador de carga interno de aplicativo precisam usar a versão 1.1 ou posterior do HTTP. O HTTP 1.0 não é compatível.

  • O Google Cloud não alerta se os endereços IP da sub-rede apenas de proxy acabarem.

  • A regra de encaminhamento interno usada pelo balanceador de carga interno do aplicativo precisa ter exatamente uma porta.

  • Os balanceadores de carga de aplicativo internos não são compatíveis com o Cloud Trace.

  • Ao usar um balanceador de carga de aplicativo interno com o Cloud Run em um ambiente de VPC compartilhada, as redes VPC autônomas em projetos de serviço podem enviar tráfego para qualquer outro serviço do Cloud Run implantado em qualquer outro projetos de serviço no mesmo ambiente de VPC compartilhada. Esse é um problema conhecido e essa forma de acesso será bloqueada no futuro.

  • O 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.

A seguir