Gerenciar balanceadores de carga

Nesta página de visão geral, explicamos como configurar balanceadores de carga internos e externos no Google Distributed Cloud (GDC) isolado por ar para configurações de rede zonais e globais.

O balanceamento de carga para o GDC garante uma distribuição eficiente do tráfego entre as cargas de trabalho de back-end, melhorando a disponibilidade e o desempenho do aplicativo.

Esta página é destinada a administradores de rede no grupo de administradores de plataforma ou a desenvolvedores no grupo de operadores de aplicativos, que são responsáveis por gerenciar o tráfego de rede da organização. Para mais informações, consulte Públicos-alvo para a documentação de air-gap do GDC.

Arquitetura de balanceamento de carga

O GDC fornece balanceadores de carga que permitem que aplicativos exponham serviços uns aos outros. Os balanceadores de carga alocam um endereço IP virtual (VIP) estável que equilibra o tráfego em um conjunto de cargas de trabalho de back-end. Os balanceadores de carga no GDC realizam o balanceamento de carga da camada quatro (L4), o que significa que eles mapeiam um conjunto de portas TCP ou UDP de front-end configuradas para as portas de back-end correspondentes. Os balanceadores de carga são configurados no nível do projeto.

Os balanceadores de carga são configurados para os seguintes tipos de carga de trabalho:

  • Cargas de trabalho em execução em VMs.
  • Cargas de trabalho conteinerizadas dentro do cluster do Kubernetes.

Há três maneiras de configurar balanceadores de carga no GDC:

  • Use a API Networking Kubernetes Resource Model (KRM). Use essa API para criar balanceadores de carga globais ou zonais.
  • Use a CLI gdcloud. É possível usar essa API para criar balanceadores de carga globais ou zonais.
  • Use o serviço do Kubernetes diretamente do cluster do Kubernetes. Esse método cria apenas balanceadores de carga zonais.

Componentes do balanceador de carga

Ao usar a API KRM ou a CLI gdcloud para configurar o balanceador de carga, você usa um balanceador de carga de encaminhamento direto de camada 4:

  • L4 significa que o protocolo é TCP ou UDP.
  • Passagem direta significa que não há proxy entre a carga de trabalho e o cliente.

O balanceador de carga consiste nos seguintes componentes configuráveis:

  • Regras de encaminhamento: especificam qual tráfego é encaminhado e para qual serviço de back-end. As regras de encaminhamento têm as seguintes especificações:

    • Consiste em três tuplas, CIDR, porta e protocolo, para o acesso do cliente.
    • Compatível com protocolos TCP e UDP.
    • Oferece regras de encaminhamento interno e externo. Os clientes podem acessar regras de encaminhamento interno na nuvem privada virtual (VPC). Os clientes podem acessar regras de encaminhamento externo de fora da plataforma GDC ou de dentro dela por cargas de trabalho que têm o valor EgressNAT definido.
    • As regras de encaminhamento se conectam a um serviço de back-end. É possível apontar várias regras de encaminhamento para o mesmo serviço de back-end.

  • Serviços de back-end: são o hub de balanceamento de carga que vincula regras de encaminhamento, verificações de integridade e back-ends. Um serviço de back-end faz referência a um objeto de back-end que identifica as cargas de trabalho para as quais o balanceador de carga encaminha o tráfego. Há limitações sobre quais back-ends um único serviço de back-end pode referenciar:

    • Um recurso de back-end zonal por zona.
    • Um recurso de back-end de cluster por cluster. Isso não pode ser misturado com os back-ends do projeto.

  • Back-ends: um objeto zonal que especifica os endpoints que servem como back-ends para os serviços de back-end criados. Os recursos de back-end precisam ser definidos para uma zona. Selecione endpoints usando rótulos. Defina o escopo do seletor para um projeto ou cluster:

    • Um back-end de projeto é um back-end que não tem o campo ClusterName especificado. Nesse caso, os rótulos especificados se aplicam a todas as cargas de trabalho no projeto específico, na VPC específica de uma zona. Os rótulos são aplicados a cargas de trabalho de VM e pod em vários clusters. Quando um serviço de back-end usa um back-end de projeto, não é possível referenciar outro back-end para essa zona no mesmo serviço.

    • Um back-end de cluster é um back-end que tem o campo ClusterName especificado. Nesse caso, os rótulos especificados se aplicam a todas as cargas de trabalho no cluster nomeado no projeto especificado. É possível especificar, no máximo, um back-end por zona por cluster em um único serviço de back-end.

  • Verificações de integridade: especifique as sondagens para determinar se um determinado endpoint de carga de trabalho no back-end está íntegro. O endpoint não íntegro é removido do balanceador de carga até que fique íntegro novamente. As verificações de integridade só são aplicáveis a cargas de trabalho de VM. As cargas de trabalho de pod podem usar o mecanismo de sondagem integrado do Kubernetes para determinar se um endpoint específico está íntegro.

Ao usar o Serviço do Kubernetes diretamente do cluster de usuário do Kubernetes, você usa o objeto Service em vez dos componentes listados anteriormente. Só é possível segmentar cargas de trabalho no cluster em que o objeto Service foi criado.

Balanceamento de carga externo e interno

Os aplicativos do GDC têm acesso aos seguintes tipos de serviços de rede:

  • Balanceador de carga interno (ILB): permite expor um serviço a outros clusters na organização.
  • Balanceador de carga externo (ELB): aloca um endereço VIP de um intervalo que pode ser roteado de cargas de trabalho externas e expõe serviços fora da organização do GDC, como outras organizações dentro ou fora da instância do GDC. Use afinidade da sessão para ELBs e garanta que as solicitações de um cliente sejam sempre encaminhadas para o mesmo back-end.

Balanceadores de carga globais e zonais

É possível criar balanceadores de carga globais ou zonais. O escopo dos balanceadores de carga globais abrange um universo do GDC. Cada universo do GDC pode consistir em várias zonas do GDC organizadas em regiões interconectadas e que compartilham um plano de controle. Por exemplo, um universo com duas regiões e três zonas cada pode ser assim: us-virginia1-a, us-virginia1-b, us-virginia1-c e eu-ams1-a, eu-ams1-b, eu-ams1-c.

O escopo dos balanceadores de carga zonais é limitado às zonas especificadas no momento da criação. Cada zona é um domínio de desastre independente. Uma zona gerencia infraestrutura, serviços, APIs e ferramentas que usam um plano de controle local.

Para mais informações sobre recursos globais e zonais em um universo do GDC, consulte Visão geral de várias zonas.

É possível criar balanceadores de carga globais usando os seguintes métodos:

É possível criar balanceadores de carga zonais usando os seguintes métodos:

  • Use a API Networking Kubernetes Resource Model (KRM). Use a versão da API networking.gdc.goog para criar recursos zonais.
  • Use a CLI gdcloud. Use a flag --zone ao usar os comandos da CLI gdcloud para especificar em quais zonas criar balanceadores de carga.
  • Use o serviço do Kubernetes diretamente do cluster do Kubernetes.

Endereços IP virtuais de serviço

Os ILBs alocam endereços VIP que são internos apenas à organização. Esses endereços VIP não podem ser acessados de fora da organização. Portanto, só é possível usá-los para expor serviços a outros aplicativos dentro de uma organização. Esses endereços IP podem se sobrepor entre organizações na mesma instância.

Por outro lado, os ELBs alocam endereços VIP que podem ser acessados externamente de fora da organização. Por isso, os endereços VIP do ELB precisam ser exclusivos entre todas as organizações. Normalmente, há menos endereços VIP do ELB disponíveis para uso pela organização.

Limitações

  • O recurso BackendService não pode ser configurado com um recurso HealthCheck para cargas de trabalho de pod. O HealthCheckName na especificação BackendService é opcional e precisa ser omitido ao configurar um balanceador de carga com pods.

  • Uma configuração de balanceador de carga não pode segmentar cargas de trabalho mistas que envolvem pods e VMs. Portanto, não é permitido usar back-ends mistos que envolvem pods e VMs em um recurso BackendService.

  • Um recurso personalizado de balanceador de carga global (ForwardingRuleExternal, ForwardingRuleInternal, BackendService ou HealthCheck) não pode ter o mesmo nome desses recursos personalizados de balanceador de carga zonal.

    A seguir

  • Configurar balanceadores de carga internos

  • Configurar balanceadores de carga externos