O balanceador de carga de proxy TCP regional interno do Google Cloud é um balanceador de carga regional baseado em proxy com software de proxy Envoy de código aberto e a pilha de virtualização de rede do Andromeda.
Esse balanceador de carga fornece um único endereço IPv4 interno regional para hospedar os serviços TCP. Um balanceador de carga de proxy TCP regional interno primeiro encerra a conexão TCP entre o cliente e o balanceador de carga em um proxy Envoy. O proxy abre uma segunda conexão TCP com back-ends hospedados no Google Cloud, no local ou em outros ambientes de nuvem.
O balanceador de carga de proxy TCP regional interno usa o nível de serviço de rede Premium.
Benefícios
O balanceador de carga do proxy TCP regional interno é compatível com:
- Balanceamento de carga para back-ends no Google Cloud, no local ou em outros ambientes de nuvem. Isso é especialmente útil quando usado com o Private Service Connect para expor serviços de produtores de cargas de trabalho no local para consumidores no Google Cloud.
- Roteamento inteligente. O balanceador de carga encaminha solicitações para back-ends dentro de uma região com base em capacidades de destino configuráveis.
- Remapeamento de portas. A porta usada pela regra de encaminhamento do balanceador de carga não precisa corresponder à porta usada ao fazer conexões com os back-ends. Por exemplo, para a regra de encaminhamento, é possível usar a porta TCP 80 enquanto a conexão com os back-ends pode usar a porta TCP 8080.
- Ouvir em qualquer porta. É possível configurar a regra de encaminhamento do balanceador de carga para detectar em qualquer porta escolhida.
- Políticas de localidade. Em um grupo de instâncias de back-end ou de endpoint de rede, é possível configurar como as solicitações são distribuídas para instâncias ou endpoints de membro.
- Acesso global. Quando o acesso global está ativado, os clientes de qualquer região podem acessar o balanceador de carga e os back-ends.
Arquitetura
O diagrama a seguir mostra os recursos do Google Cloud necessários para um balanceador de carga de proxy TCP regional interno.
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. É preciso criar uma
sub-rede somente proxy em cada região de uma rede VPC em que você usa
um balanceador de carga baseado no Envoy (como o balanceador de carga de proxy TCP regional interno, o balanceador de carga HTTP(S) interno, etc.) Todos os balanceadores de carga baseados no Envoy em uma região e
rede VPC compartilham a mesma sub-rede somente proxy. A finalidade
da sub-rede somente proxy precisa ser definida como REGIONAL_MANAGED_PROXY. Além disso:
- As sub-redes somente proxy são usadas apenas para proxies Envoy, não para seus back-ends.
- VMs de back-end ou endpoints de todos os balanceadores de carga baseados no Envoy em uma região e rede VPC recebem conexões da mesma sub-rede somente proxy.
- O endereço IP do balanceador de carga 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.
Regras de encaminhamento e endereços IP
As regras de encaminhamento regionais 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.
Uma regra de encaminhamento gerenciado interno regional especifica um endereço IP interno, uma porta e um proxy TCP de destino regional. Os clientes usam o endereço IP e a porta para se conectar aos proxies Envoy do balanceador de carga. O endereço IP da regra de encaminhamento é o endereço IP do balanceador de carga, às vezes chamado de endereço IP virtual ou VIP.
O endereço IP interno associado à regra de encaminhamento pode vir de qualquer sub-rede na mesma rede e região. Observações:
- O endereço IP pode (mas não precisa) vir da mesma sub-rede que os grupos de instâncias de back-end.
- O endereço IP não pode vir da sub-rede somente proxy reservada que tem
a sinalização
--purposedefinida comoREGIONAL_MANAGED_PROXY. - Se você quiser compartilhar um endereço IP interno com várias regras de encaminhamento,
defina a sinalização
--purposecomoSHARED_LOADBALANCER_VIP.
As regras de encaminhamento gerenciadas internas são compatíveis com todas as portas possíveis, mas cada uma pode referenciar exatamente uma porta.
Regras de encaminhamento e acesso global
As regras de encaminhamento do balanceador de carga do proxy TCP regional interno são regionais, mesmo quando o acesso global
está ativado. Depois de ativar o acesso global, a sinalização allowGlobalAccess da regra de encaminhamento
interno regional é definida como true.
Proxies de destino
O balanceador de carga do proxy TCP regional interno encerra as conexões TCP do cliente e cria novas conexões com os back-ends. Por padrão, o endereço IP do cliente original e as informações da porta não são preservados. É possível preservar essas informações usando o protocolo PROXY. O proxy de destino encaminha solicitações recebidas diretamente para o serviço de back-end do balanceador de carga.
Serviço de back-end
Um serviço de back-end direciona o tráfego de entrada para um ou mais back-ends anexados. Um back-end é um grupo de instâncias ou um grupo de endpoints da rede. O back-end contém informações do modo de balanceamento para definir totalidade com base nas conexões (ou, para back-ends de grupos de instâncias, na utilização).
Cada balanceador de carga do proxy TCP regional interno tem um único recurso de serviço de back-end.
Back-ends compatíveis
O serviço de back-end é compatível com os seguintes tipos de back-ends:
- Todos os back-ends do grupo de instâncias: os grupos de instâncias podem ser não gerenciados por zona, gerenciados por zona ou gerenciados por região
- Todos os back-ends de grupos de endpoints de rede: NEGs zonais com endpoints
GCE_VM_IP_PORTe NEGs de conectividade híbrida com endpointsNON_GCP_PRIVATE_IP_PORTsão compatíveis.
Todos os back-ends precisam ser do mesmo tipo (grupos de instâncias ou NEGs). É possível usar simultaneamente diferentes tipos de back-ends de grupos de instâncias ou simultaneamente para diferentes tipos de back-ends de NEGs, mas não é possível usar grupos de instâncias e back-ends de NEG juntos no mesmo serviço de back-end.
É possível misturar NEGs zonais e híbridos no mesmo serviço de back-end.
Para garantir o mínimo possível de interrupções aos usuários, ative a diminuição das conexões nos serviços de back-end. Essas interrupções podem acontecer quando um back-end é encerrado, removido manualmente ou removido por um escalonador automático. Para saber mais sobre como usar a diminuição da conexão para minimizar as interrupções do serviço, consulte Ativar a diminuição da conexão.
Protocolo para comunicação com os back-ends
Ao configurar um serviço de back-end para um balanceador de carga de proxy TCP regional interno, defina o protocolo que o serviço usará para se comunicar com os back-ends. O balanceador de carga usa apenas o protocolo que você especifica e não tenta negociar uma conexão com o outro protocolo. O balanceador de carga do proxy TCP regional interno só é compatível com TCP para comunicação com os back-ends.
Verificação 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.
Regras de firewall
O balanceador de carga do proxy TCP regional interno requer as seguintes regras de firewall:
- Uma regra de permissão de entrada que permite o tráfego das sondagens de
verificação de integridade do Google.
35.191.0.0/16130.211.0.0/22
- Uma regra de permissão de entrada que permita o tráfego da sub-rede somente proxy.
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.
Acesso de cliente
Por padrão, os clientes precisam estar na mesma região do balanceador de carga. Os clientes podem estar na mesma rede ou em uma rede VPC conectada usando o peering de rede VPC. É possível ativar o acesso global para permitir que os clientes de qualquer região acessem o balanceador de carga.
Na tabela a seguir, é possível ver um resumo do acesso do cliente.
| 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. |
Arquitetura da VPC compartilhada
O balanceador de carga do proxy TCP regional interno suporta redes que usam VPC compartilhada. A VPC compartilhada permite manter uma separação clara de responsabilidades entre administradores de rede e desenvolvedores de serviços. Suas equipes de desenvolvimento podem se concentrar na criação de serviços em projetos de serviço, enquanto as equipes de infraestrutura de rede podem provisionar e administrar o balanceamento de carga. Se você ainda não estiver familiarizado com a VPC compartilhada, leia a documentação de visão geral da VPC compartilhada.
| Endereço IP | Regra de encaminhamento | Proxy de destino | Componentes de back-end |
|---|---|---|---|
Um endereço IP interno precisa ser definido no mesmo projeto que os back-ends. Para que o balanceador de carga esteja disponível em uma rede VPC compartilhada, o endereço IP interno precisa ser definido no mesmo projeto de serviço em que as VMs de back-end estão localizadas e precisa referenciar uma sub-rede na rede VPC compartilhada do projeto host. O endereço vem do intervalo de IP principal da sub-rede referenciada. |
Uma regra de encaminhamento interna precisa ser definida no mesmo projeto que os back-ends. Para que o balanceador de carga esteja disponível em uma rede VPC compartilhada, a regra de encaminhamento interno precisa ser definida no mesmo projeto de serviço das VMs de back-end, e precisa referenciar mesma sub-rede (na rede VPC compartilhada) que o endereço IP interno associado. |
O proxy de destino precisa ser definido no mesmo projeto que os back-ends. | Em um cenário de VPC compartilhada, as VMs de back-end costumam ficar localizadas em um projeto de serviço. Um serviço de back-end interno regional e uma verificação de integridade precisam ser definidos nesse projeto de serviço. |
Distribuição de tráfego
Um balanceador de carga de proxy TCP regional interno distribui o tráfego para os back-ends da seguinte maneira:
- As conexões originadas de um único cliente são enviadas para a mesma zona, desde que os back-ends íntegros (grupos de instâncias ou NEGs) nessa zona estejam disponíveis e tenham capacidade, conforme determinado pelo modo de balanceamento.
Para balanceadores de carga de proxy TCP regional interno, o modo de balanceamento pode ser
CONNECTION(back-ends de grupos de instâncias ou NEG) ouUTILIZATION(somente back-ends de grupos de instâncias). - As conexões de um cliente serão enviadas para o mesmo back-end se você tiver configurado a afinidade da sessão.
- Depois que um back-end é selecionado, o tráfego é distribuído entre instâncias
(em um grupo de instâncias) ou endpoints (em um NEG) de acordo com uma
política de balanceamento de carga. Para saber mais sobre os algoritmos de política de balanceamento de carga suportados, consulte a configuração
localityLbPolicyna documentação da API do serviço de back-end regional.
Afinidade da sessão
Afinidade da sessão permite configurar o serviço de back-end do balanceador de carga para enviar todas as solicitações do mesmo cliente ao mesmo back-end, desde que o back-end esteja íntegro e tenha capacidade.
O balanceador de carga de proxy TCP regional interno oferece afinidade de IP do cliente, que encaminha todas as solicitações do mesmo endereço IP do cliente para o mesmo back-end, desde que esse back-end tenha capacidade e se mantenha saudável.
Failover
Se um back-end se tornar não íntegro, o tráfego será redirecionado automaticamente para back-ends íntegros na mesma região. O balanceador de carga implementa um algoritmo suave de failover por zona. Em vez de aguardar a integridade de todos os back-ends de uma zona, o balanceador de carga começa a redirecionar o tráfego para uma zona diferente quando a proporção de back-ends íntegros ou não íntegros em qualquer zona estiver abaixo de um determinado limite de porcentagem (70%. Esse limite não é configurável). Se todos os back-ends em todas as zonas não estiverem íntegros, o balanceador de carga encerrará imediatamente a conexão do cliente.
Balanceamento de carga para aplicativos do GKE
Se você estiver criando aplicativos no Google Kubernetes Engine, poderá usar NEGs zonais independentes para balancear a carga do tráfego diretamente para contêineres. Com os NEGs independentes, você é responsável por criar o objeto Serviço que cria o NEG zonal e, em seguida, associar o NEG ao serviço de back-end para que o balanceador de carga possa conectar aos pods.
Documentação relacionada do GKE:
Cotas e limites
Para informações sobre cotas e limites, consulte Cotas para recursos de balanceamento de carga.
Limitações
- O balanceador de carga de proxy TCP regional interno não é compatível com o tráfego IPv6.
- O balanceador de carga do proxy TCP regional interno não oferece suporte a implantações de VPC compartilhada, em que o front-end do balanceador de carga está em um projeto host ou de serviço e o serviço de back-end e os back-ends estão em outro projeto de serviço (também conhecido como Referência do serviço do projeto).
A seguir
- Configure um balanceador de carga de proxy TCP regional interno com um back-end de grupo de instâncias
- Configure um balanceador de carga de proxy TCP regional interno com um back-end NEG zonal
- Configure um balanceador de carga de proxy TCP regional interno com um back-end NEG híbrido
- Veja métricas com o Cloud Monitoring