Faça a gestão dos equilibradores de carga

Esta página de vista geral explica como pode configurar balanceadores de carga internos e externos no Google Distributed Cloud (GDC) isolado para configurações de rede zonais e globais.

O equilíbrio de carga para o GDC garante uma distribuição eficiente do tráfego pelas cargas de trabalho de back-end, melhorando a disponibilidade e o desempenho das aplicações. O algoritmo usado para distribuir o tráfego é o Maglev. Para mais detalhes, consulte o artigo Algoritmo de balanceamento de carga.

Esta página destina-se aos administradores de rede no grupo de administradores da plataforma ou aos programadores no grupo de operadores da aplicação, que são responsáveis pela gestão do tráfego de rede da respetiva organização. Para mais informações, consulte a documentação sobre públicos-alvo para GDC com isolamento de ar.

Arquitetura de balanceamento de carga

O GDC fornece balanceadores de carga que permitem que as aplicações exponham serviços entre si. Os balanceadores de carga atribuem um endereço IP virtual (VIP) estável que equilibra o tráfego num conjunto de cargas de trabalho de back-end. Os balanceadores de carga no GDC realizam o balanceamento de carga de camada quatro (L4), o que significa que mapeiam um conjunto de portas TCP ou UDP de front-end configuradas para portas de back-end correspondentes. Os equilibradores de carga são configurados ao nível do projeto.

Os equilibradores de carga estão configurados para os seguintes tipos de cargas de trabalho:

  • Cargas de trabalho executadas em VMs.
  • Cargas de trabalho em contentores no cluster do Kubernetes.

Existem três formas de configurar equilibradores de carga no GDC:

  • Use a API Networking Kubernetes Resource Model (KRM). Pode usar esta API para criar balanceadores de carga globais ou zonais.
  • Use a CLI gcloud. Pode usar esta API para criar balanceadores de carga globais ou zonais.
  • Use o serviço Kubernetes diretamente a partir do cluster Kubernetes. Este método apenas cria balanceadores de carga zonais.

Componentes do balanceador de carga

Quando usa a API KRM ou a CLI gdcloud para configurar o equilibrador de carga, usa um equilibrador de carga de passagem L4:

  • L4 significa que o protocolo é TCP ou UDP.
  • A passagem direta significa que não existe nenhum proxy entre a carga de trabalho e o cliente.

O balanceador de carga é composto pelos seguintes componentes configuráveis:

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

    • Consiste em 3 tuplos, CIDR, porta e protocolo, para o cliente aceder.
    • Suporta protocolos TCP e UDP.
    • Oferece regras de encaminhamento internas e externas. Os clientes podem aceder a regras de encaminhamento interno a partir da nuvem virtual privada (VPC). Os clientes podem aceder a regras de encaminhamento externas a partir do exterior da plataforma GDC ou a partir do interior através de cargas de trabalho com o valor EgressNAT definido.
    • As regras de encaminhamento ligam-se a um serviço de back-end. Pode fazer com que várias regras de encaminhamento apontem para o mesmo serviço de back-end.

  • Serviços de back-end: são o hub de balanceamento de carga que associa regras de encaminhamento, verificações de funcionamento 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. Existem limitações quanto aos back-ends que 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. Não é possível misturar isto com os back-ends do projeto.

  • Back-ends: um objeto zonal que especifica os pontos finais que funcionam como back-ends para os serviços de back-end criados. Os recursos de back-end têm de estar no âmbito de uma zona. Selecione pontos finais através de etiquetas. Restrinja o âmbito do seletor a um projeto ou um cluster:

    • Um back-end de projeto é um back-end que não tem o campo ClusterName especificado. Neste caso, as etiquetas especificadas aplicam-se a todas as cargas de trabalho no projeto específico, na VPC específica de uma zona. As etiquetas são aplicadas a cargas de trabalho de VMs e pods em vários clusters. Quando um serviço de back-end usa um back-end de projeto, não pode fazer referência a 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. Neste caso, as etiquetas especificadas aplicam-se a todas as cargas de trabalho no cluster com nome no projeto especificado. Pode especificar, no máximo, um back-end por zona por cluster num único serviço de back-end.

  • Verificações de funcionamento: especifique as sondas para determinar se um determinado ponto final de carga de trabalho no back-end está em bom estado. O ponto final não saudável é removido do balanceador de carga até ficar novamente saudável. As verificações de estado de funcionamento só são aplicáveis a cargas de trabalho de VMs. As cargas de trabalho de pods podem usar o mecanismo de sondagem do Kubernetes integrado para determinar se um ponto final específico está em bom estado. Consulte as verificações de estado para mais informações.

Quando usa o Kubernetes Service diretamente a partir do cluster de utilizadores do Kubernetes, usa o objeto Service em vez dos componentes indicados anteriormente. Só pode segmentar cargas de trabalho no cluster onde o objeto Service é criado.

Balanceamento de carga externo e interno

As aplicações 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.
  • Equilibrador de carga externo (ELB): atribui um endereço IP virtual (VIP) a partir de um intervalo encaminhável a partir 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 de sessão para ELBs para garantir que os pedidos de um cliente são encaminhados de forma consistente para o mesmo back-end.

Balanceadores de carga globais e zonais

Pode criar balanceadores de carga globais ou zonais. O âmbito 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 interligadas e que partilham um plano de controlo. Por exemplo, um universo composto por duas regiões com três zonas cada pode ter o seguinte aspeto: us-virginia1-a, us-virginia1-b, us-virginia1-c e eu-ams1-a, eu-ams1-b, eu-ams1-c.

O âmbito dos balanceadores de carga zonais está limitado às zonas especificadas no momento da criação. Cada zona é um domínio de desastre independente. Uma zona gere a infraestrutura, os serviços, as APIs e as ferramentas que usam um plano de controlo local.

Para mais informações sobre os recursos globais e zonais num universo da GDC, consulte a vista geral de várias zonas.

Pode criar balanceadores de carga globais através dos seguintes métodos:

Pode criar balanceadores de carga zonais através dos seguintes métodos:

  • Use a API Networking Kubernetes Resource Model (KRM). Use a versão networking.gdc.goog da API para criar recursos zonais.
  • Use a CLI gcloud. Use a flag --zone quando usar os comandos da CLI gdcloud para especificar para que zonas criar balanceadores de carga.
  • Use o Kubernetes Service diretamente a partir do cluster Kubernetes.

Endereços IP virtuais de serviço

Os ILBs atribuem endereços VIP que são apenas internos à organização. Estes endereços VIP não são acessíveis a partir do exterior da organização. Por conseguinte, só os pode usar para expor serviços a outras aplicações numa organização. Estes endereços IP podem sobrepor-se entre organizações na mesma instância.

Por outro lado, os ELBs atribuem endereços VIP acessíveis externamente a partir de fora da organização. Por este motivo, os endereços VIP do ELB têm de ser únicos entre todas as organizações. Normalmente, estão disponíveis menos endereços VIP do ELB para utilização pela organização.

Algoritmo de balanceamento de carga

O nosso equilibrador de carga usa o Maglev, um algoritmo de hash consistente, para distribuir o tráfego recebido para destinos de back-end. Este algoritmo foi concebido para um desempenho e uma capacidade de recuperação elevados, garantindo que o tráfego é distribuído de forma uniforme e previsível, ao mesmo tempo que maximiza a localidade dos dados nos back-ends.

Como funciona o Maglev: o mecanismo de hash

O Maglev toma decisões de encaminhamento ao aplicar hash às propriedades de cada pacote recebido. Isto garante que todos os pacotes de uma determinada ligação são enviados de forma consistente para o mesmo back-end para maximizar a localidade dos dados.

  • Entrada de hash (5 tuplos): o algoritmo usa um 5 tuplos padrão do cabeçalho do pacote para gerar um hash. Esta 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 deste hash mapeia deterministicamente a ligação para um dos back-ends em bom estado no conjunto de equilíbrio de carga. Durante a duração dessa ligação, todos os respetivos pacotes são encaminhados para o mesmo back-end.
  • Entropia para o equilíbrio: ao usar todos os cinco elementos da tupla, o Maglev gera entropia suficiente para garantir que as diferentes ligações são distribuídas uniformemente por todos os back-ends disponíveis.

Gerir o estado de funcionamento e as falhas do back-end

O Maglev foi concebido para ser resiliente e minimizar as interrupções quando o conjunto de back-ends disponíveis muda.

  • Falha no back-end: quando um back-end falha nas verificações de estado, é removido da lista de destinos disponíveis. As ligações que foram encaminhadas anteriormente para o back-end com falhas são terminadas. As novas ligações são redistribuídas automaticamente pelos back-ends em bom estado restantes com base no algoritmo de hash. É importante referir que as ligações a outros backends em bom estado não são afetadas nem reencaminhadas.
  • Recuperação do back-end: quando o back-end em mau estado de funcionamento volta a funcionar corretamente e é adicionado novamente ao conjunto, a natureza consistente do hash garante que este back-end é adicionado ao conjunto com a mínima interrupção, e o LB volta a equilibrar a carga tendo em conta este back-end que voltou a funcionar corretamente. Esta abordagem de "interrupção mínima" evita uma reorganização em massa de todas as associações existentes, o que, de outra forma, poderia sobrecarregar as caches ou o estado das aplicações.

Comportamento em implementações de várias zonas

É fundamental compreender que o Maglev não tem em conta a topologia. Distribui o tráfego com base puramente no resultado matemático do hash, sem considerar a localização física ou o caminho de rede para os back-ends.

  • Distribuição igual independentemente da localização: o Maglev trata todos os back-ends no respetivo conjunto como alvos iguais. Se tiver back-ends distribuídos por diferentes zonas, o tráfego é distribuído uniformemente entre todos eles. O algoritmo não prefere back-ends numa zona "local" nem tem em conta a latência da rede entre zonas.
  • Garantir a capacidade de interligação de várias zonas:uma vez que os back-ends podem abranger várias zonas, é essencial que o administrador de rede garanta que a interligação de várias zonas tem capacidade de rede suficiente para processar o tráfego entre zonas entre os nós do equilibrador 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 pods. O elemento HealthCheckName na especificação BackendService é opcional e tem de ser omitido quando configurar um equilibrador de carga com pods.

  • Uma configuração do equilibrador de carga não pode segmentar cargas de trabalho mistas que envolvam pods e VMs. Por conseguinte, não são permitidos backends mistos que envolvam pods e VMs num único recurso BackendService.

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

  • Uma organização pode definir um máximo de 500 regras de encaminhamento por zona na qual reside. As regras de encaminhamento globais são contabilizadas para este limite para todas as zonas.

Limitações para clusters padrão

As seguintes limitações aplicam-se ao equilíbrio de carga para clusters padrão:

Âmbito de cluster único

  • Âmbito de cluster único: qualquer equilibrador de carga (ILB ou ELB) aprovisionado para um cluster padrão que use um recurso Service type=LoadBalancer tem de segmentar pontos finais de back-end que sejam pods localizados exclusivamente nesse cluster padrão único. Não é suportada uma única definição de Load Balancer que tente distribuir o tráfego para pods em execução em vários clusters padrão diferentes ou numa combinação de clusters padrão e clusters partilhados.

  • A CLI gdcloud e a API Networking Kubernetes Resource Model não são suportadas para clusters padrão. Use o recurso padrão do Kubernetes Service com type=LoadBalancer e anotações associadas para gerir o equilíbrio de carga para clusters padrão.

  • Os equilibradores de carga com âmbito do projeto ignoram os clusters padrão. Se for criada uma configuração do equilibrador de carga ao nível do projeto através do comando gdcloud CLI ou da API Networking Kubernetes Resource Model, esta ignora todos os clusters padrão no projeto.

  • O equilíbrio de carga global não é suportado. Os recursos ILB e ELB aprovisionados para clusters padrão são recursos zonais com âmbito numa única zona. O equilíbrio de carga global não é suportado para equilibradores de carga de cluster padrão.

  • A conetividade ILB entre zonas não é suportada. A conetividade de um pod de cluster padrão para um ILB global ou um ILB zonal numa zona diferente não é suportada.

O que se segue?