Gerenciar balanceadores de carga

Esta página de visão geral explica como configurar balanceadores de carga internos e externos no Google Distributed Cloud (GDC) com isolamento físico para configurações de rede globais e zonais.

O balanceamento de carga para o GDC garante a distribuição eficiente do tráfego entre 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 desenvolvedores no grupo de operadores de aplicativos, 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 oferece balanceadores de carga que permitem que os 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:

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 passagem L4:

  • L4 significa que o protocolo é TCP ou UDP.
  • Passagem 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 cliente acessar.
    • Oferece suporte a protocolos TCP e UDP.
    • Oferece regras de encaminhamento internas e externas. Os clientes podem acessar regras de encaminhamento internas na nuvem privada virtual (VPC). Os clientes podem acessar regras de encaminhamento externas de fora da plataforma do GDC ou de dentro de 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 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 nesse serviço de back-end.

    • 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: especificam as probes 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 probe 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ço de rede:

  • Balanceador de carga interno (ILB, na sigla em inglês): permite expor um serviço a outros clusters na organização.
  • Balanceador de carga externo (ELB, na sigla em inglês): 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 a afinidade da sessão para ELBs para garantir que as solicitações de um cliente sejam sempre roteadas 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 que consiste em duas regiões com 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:

Endereços IP virtuais de serviço

Os ILBs alocam endereços VIP que são internos apenas para a 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 em 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 esse motivo, os endereços VIP do ELB precisam ser exclusivos entre todas as organizações. Normalmente, menos endereços VIP do ELB estão 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. Esse algoritmo foi projetado para alto desempenho e resiliência, garantindo que o tráfego seja distribuído de maneira uniforme e previsível, maximizando a localidade dos dados nos back-ends.

Como o Maglev funciona: o mecanismo de hash

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

  • Entrada de hash (5 tuplas): o algoritmo usa uma tupla padrão de 5 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 conexões diferentes 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 de 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 ressaltar 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 fica íntegro novamente e é adicionado de volta ao pool, a natureza consistente do hash garante que esse back-end seja adicionado ao pool com interrupção mínima, e o LB vai reequilibrar a carga usando esse back-end recém-íntegro. Essa abordagem de "interrupção mínima" impede uma reorganização massiva de todas as conexões atuais, o que poderia sobrecarregar os caches ou o estado do aplicativo.

Comportamento em implantações de várias zonas

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

  • Distribuição igual, independentemente do local: 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 uniformemente entre todos eles. O algoritmo não prefere back-ends em uma zona "local" ou conta com a latência de rede entre zonas.
  • Garantir a capacidade de interconexão de várias zonas:como os back-ends podem abranger várias zonas, é essencial que o administrador de rede garanta que a interconexão de várias zonas tenha capacidade de rede suficiente para processar o tráfego entre zonas entre os 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, back-ends mistos que envolvem pods e VMs em um recurso BackendService não são permitidos.

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

  • Uma organização pode definir um máximo de 500 regras de encaminhamento por zona em que reside. As regras de encaminhamento globais 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 cluster padrão único. Uma única definição de balanceador de carga que tenta distribuir o tráfego para pods em execução em vários clusters padrão diferentes ou em uma combinação de clusters padrão e compartilhados não é compatível.

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

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

  • O balanceamento de carga global não é compatível. Os recursos ILB e ELB provisionados para clusters padrão são recursos zonais definidos para uma única zona. O balanceamento de carga global não é compatível com balanceadores de carga de cluster padrão.

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

A seguir