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) com isolamento físico 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. O algoritmo usado para distribuir o tráfego é o Maglev. Para mais detalhes, consulte Algoritmo de balanceamento de carga.

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 da documentação do GDC com isolamento físico.

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 distribuem 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. Use 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 é aquele 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. Consulte as verificações de integridade para mais informações.

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 é 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 IP virtual (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 em cada uma 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 a visão geral multizonal.

É 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 Service do Kubernetes diretamente do cluster do Kubernetes.

Endereços IP virtuais de serviço

Os ILBs distribuem 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 distribuem 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.

Algoritmo de balanceamento de carga

Nosso balanceador de carga usa o Maglev, um algoritmo hashing consistente, para distribuir o tráfego de entrada para destinos de back-end. Este algoritmo foi projetado para alto desempenho e resiliência, garantindo que o tráfego seja distribuído de maneira uniforme e previsível, além de maximizar a localidade dos dados nos back-ends.

Como o Maglev funciona: o mecanismo de hash

O Maglev toma decisões de encaminhamento fazendo hash das propriedades de cada pacote recebido. Isso garante que todos os pacotes de uma determinada conexão sejam enviados de forma consistente para o mesmo back-end, maximizando a localidade dos dados.

  • Entrada de hash (cinco tuplas): o algoritmo usa uma tupla padrão de cinco elementos do cabeçalho do pacote para gerar um hash. Essa tupla consiste em:
    1. Endereço IP de origem
    2. Porta de origem
    3. Endereço IP de destino
    4. Porta de destino
    5. Protocolo (por exemplo, TCP, UDP)
  • Decisão de encaminhamento: o resultado desse hash mapeia deterministicamente a conexão para um dos back-ends íntegros no pool de balanceamento de carga. Durante a vida útil dessa conexão, todos os pacotes serão encaminhados para o mesmo back-end.
  • Entropia para balanceamento: ao usar todos os cinco elementos da tupla, o Maglev gera entropia suficiente para garantir que diferentes conexões sejam distribuídas uniformemente em todos os back-ends disponíveis.

Como lidar com a integridade e as falhas do back-end

O Maglev foi projetado para ser resiliente e minimizar a interrupção quando o conjunto de back-ends disponíveis muda.

  • Falha no back-end: quando um back-end falha nas verificações de integridade, ele é removido da lista de destinos disponíveis. As conexões que foram roteadas anteriormente para o back-end com falha são encerradas. Novas conexões serão redistribuídas automaticamente entre os back-ends íntegros restantes com base no algoritmo de hash. É importante lembrar que as conexões com outros back-ends íntegros não são afetadas nem redirecionadas.
  • Recuperação de back-end: quando o back-end não íntegro volta a ficar íntegro e é adicionado novamente ao pool, a natureza consistente do hash garante que esse back-end seja adicionado ao pool com interrupção mínima, e o LB rebalanceará a carga usando esse back-end recém-íntegro. Essa abordagem de "interrupção mínima" evita uma reorganização em massa de todas as conexões atuais, o que poderia sobrecarregar os caches ou o estado do aplicativo.

Comportamento em implantações em várias zonas

É fundamental entender que o Maglev não considera a topologia. Ele distribui o tráfego com base apenas no resultado matemático do hash, sem considerar o local físico ou o caminho de rede para os back-ends.

  • Distribuição igual, independente da localização: o Maglev trata todos os back-ends no pool como destinos iguais. Se você tiver back-ends distribuídos em diferentes zonas, o tráfego será distribuído de maneira uniforme entre todos eles. O algoritmo não prefere back-ends em uma zona "local" nem considera a latência de rede entre zonas.
  • Garantir a capacidade do MultiZone Interconnect:como os back-ends podem abranger várias zonas, é essencial que o administrador da rede garanta que o MultiZone Interconnect tenha capacidade de rede suficiente para lidar com o tráfego entre zonas dos nós do balanceador de carga e os back-ends.

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 envolvam pods e VMs em um recurso BackendService.

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

  • Uma organização pode definir no máximo 500 regras de encaminhamento por zona em que reside. As regras de encaminhamento global contam para esse limite em todas as zonas.

Limitações para clusters padrão

As seguintes limitações se aplicam ao balanceamento de carga para clusters padrão:

Escopo de cluster único

  • Escopo de cluster único:qualquer balanceador de carga (ILB ou ELB) provisionado para um cluster padrão usando um recurso Service type=LoadBalancer precisa segmentar endpoints de back-end que são pods localizados exclusivamente nesse único cluster padrão. Não é possível usar uma única definição de balanceador de carga que tente distribuir o tráfego para pods executados em vários clusters padrão diferentes ou em uma combinação de clusters padrão e compartilhados.

  • A CLI gdcloud e a API Networking Kubernetes Resource Model não são compatíveis com clusters padrão. Use o recurso padrão do Kubernetes Service com type=LoadBalancer e as anotações associadas para gerenciar o balanceamento de carga em clusters padrão.

  • Os balanceadores de carga no escopo do projeto vão ignorar os clusters padrão. Se uma configuração de balanceador de carga no escopo do projeto for criada usando o comando gdcloud CLI ou a API Networking Kubernetes Resource Model, ela vai ignorar todos os clusters padrão no projeto.

  • O balanceamento de carga global está indisponível. Os recursos de ILB e ELB provisionados para clusters padrão são recursos zonais com escopo definido para uma única zona. O balanceamento de carga global está indisponível para balanceadores de carga de cluster padrão.

  • Conectividade ILB entre zonas indisponível. A conectividade de um pod de cluster padrão para um ILB global ou zonal em uma zona diferente não é compatível.

A seguir