Gerenciar balanceadores de carga

O dispositivo com isolamento físico do Google Distributed Cloud (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:

  • Use a API Networking Kubernetes Resource Model (KRM). É possível usar essa API para criar balanceadores de carga.
  • Use a CLI gdcloud. Você pode usar essa API para criar balanceadores de carga.
  • 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.

Ao usar o Kubernetes Service diretamente, 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.

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, menos endereços VIP do ELB estarão disponíveis para uso pela organização.

A seguir