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) air-gapped 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.

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.

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:

  • Internal Load Balancer (ILB): permite-lhe expor um serviço a outros clusters na organização.
  • Balanceador de carga externo (ELB): atribui um endereço VIP a partir de um intervalo que é 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 de GDCs. 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 recursos globais e zonais num universo do GDC, consulte o artigo 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 serviço Kubernetes 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.

Limitações

  • O recurso BackendService não pode ser configurado com um recurso HealthCheck para cargas de trabalho de pods. Tenha em atenção que 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 balanceador 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 recurso BackendService.

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

    O que se segue?

  • Configure balanceadores de carga internos

  • Configure balanceadores de carga externos