Revise as possíveis topologias que você pode implementar para o balanceador de carga do HAProxy para um Supervisor configurado com a rede VDS. Ao usar vSphere with Tanzu com a rede VDS, o HAProxy fornece balanceamento de carga para desenvolvedores que acessam o plano de controle Tanzu Kubernetes Grid e para Serviços Kubernetes do tipo Balanceador de carga.

Redes de carga de trabalho no Supervisor

Para configurar um Supervisor com rede VDS, você deve conectar todos os hosts do cluster a um VDS. Dependendo da topologia que você implementa para o Supervisor Workload Networks, você cria um ou mais grupos de portas distribuídos. Você designa os grupos de portas como Redes de Carga de Trabalho para vSphere Namespaces.

As Redes de Carga de Trabalho fornecem conectividade aos nós de clusters Tanzu Kubernetes Grid e às VMs do plano de controle Supervisor. A Rede de Carga de Trabalho que fornece conectividade a VMs do plano de controle do Kubernetes é chamada de Rede de Carga de Trabalho Primária. Cada Supervisor deve ter uma Rede de Carga de Trabalho Primária. Você deve designar um do grupo de portas distribuído como a Rede de Carga de Trabalho Primária para o Supervisor.
Observação: As redes de carga de trabalho só são adicionadas quando você ativa o Supervisor e não podem ser adicionadas posteriormente.

As VMs do plano de controle do Kubernetes no Supervisor usam três endereços IP do intervalo de endereços IP atribuído à Rede de Carga de Trabalho Primária. Cada nó de um cluster Tanzu Kubernetes Grid tem um endereço IP separado designado do intervalo de endereços da Workload Network que está configurado com o namespace no qual o cluster Tanzu Kubernetes Grid é executado.

Alocação de intervalos de IP

Ao planejar a topologia de rede do Supervisor com o balanceador de carga do Proxy de alta disponibilidade, planeje ter dois tipos de intervalos de IP:
  • Um intervalo para alocar IPs virtuais para o HAProxy. O intervalo de IP que você configura para os servidores virtuais do HAProxy é reservado pelo dispositivo do balanceador de carga. Por exemplo, se o intervalo de IP virtual for 192.168.1.0/24, todos os hosts nesse intervalo não poderão ser acessados pelo tráfego que não seja o tráfego de IP virtual.
    Observação: Você não deve configurar um gateway dentro do intervalo de IPs virtuais do HAProxy, pois todas as rotas para esse gateway falharão.
  • Um intervalo de IP para os nós dos clusters Supervisor e Tanzu Kubernetes Grid. Cada VM do plano de controle do Kubernetes no Supervisor tem um endereço IP atribuído, o que perfaz três endereços IP no total. Cada nó de um cluster Tanzu Kubernetes Grid também tem um IP separado atribuído. Você deve atribuir um intervalo de IP exclusivo a cada Rede de Carga de Trabalho no Supervisor que você configura para um namespace.

Um exemplo de configuração com uma rede /24:

  • Rede: 192.168.120.0/24
  • VIPs do HAProxy: 192.168.120.128/25
  • 1 endereço IP para a interface de carga de trabalho do HAProxy: 192.168.120.5

Dependendo dos IPs que estão livres nos primeiros 128 endereços, você pode definir intervalos de IPs para Redes de Carga de Trabalho no Supervisor, por exemplo:

  • 192.168.120.31-192.168.120.40 para a rede de carga de trabalho primária
  • 192.168.120.51-192.168.120.60 para outra rede de carga de trabalho
Observação: Os intervalos definidos para Workload Networks não devem se sobrepor ao intervalo VIP do HAProxy.

Topologia de rede do HAProxy

Há duas opções de configuração de rede para a implantação do HAProxy: Padrão (Default) e Frontend. A rede padrão tem 2 NICs: uma para a rede de gerenciamento e outra para a rede de carga de trabalho. A rede Front-end tem 3 NICs: Rede de gerenciamento, Rede de carga de trabalho e a rede Front-end para clientes. A tabela lista e descreve as características de cada rede.

Para instalações de produção, é recomendável implantar o balanceador de carga do HAProxy usando a configuração de Rede Front-end (Frontend Network). Se você implantar o balanceador de carga do HAProxy usando a configuração Padrão (Default), é recomendável atribuir um tamanho de bloco de endereço IP /24 à rede de carga de trabalho. Para ambas as opções de configuração, o DHCP não é recomendado.
Rede Características
Gerenciamento (Management)
O Supervisor Cluster usa a rede de Gerenciamento para se conectar e programar o balanceador de carga do HAProxy.
  • O endpoint da API do Plano de Dados do HAProxy está associado à interface de rede conectada à rede de Gerenciamento.
  • O endereço IP de gerenciamento atribuído à VM do plano de controle do HAProxy deve ser um IP estático na rede de gerenciamento para que o Supervisor Cluster possa se conectar de forma confiável à API do balanceador de carga.
  • O gateway padrão para a VM do HAProxy deve estar nessa rede.
  • As consultas DNS devem ocorrer nesta rede.
Carga de trabalho (Workload)
A VM do plano de controle do HAProxy usa a rede Workload para acessar os serviços no Supervisor Cluster e nos nós do cluster Tanzu Kubernetes.
  • A VM do plano de controle do HAProxy encaminha o tráfego para os nós de cluster Supervisor e Tanzu Kubernetes nesta rede.
  • Se a VM do plano de controle do HAProxy for implantada no modo Padrão (duas NICs), a rede de carga de trabalho deverá fornecer as redes lógicas usadas para acessar os serviços do balanceador de carga.
  • Na configuração Padrão (Default), os IPs virtuais do balanceador de carga e os IPs do nó de cluster Kubernetes virão dessa rede. Eles serão definidos como intervalos separados e não sobrepostos dentro da rede.
Observação: A rede de carga de trabalho deve estar em uma sub-rede diferente da rede de gerenciamento. Consulte os requisitos do sistema.
Frontend (opcional)

Clientes externos (como usuários ou aplicativos) que acessam cargas de trabalho de cluster usam a rede Front-end para acessar serviços de balanceamento de carga de back-end usando endereços IP virtuais.

  • A rede Front-end só é usada quando a VM do plano de controle do HAProxy é implantada com três NICs.
  • Recomendado para instalações de produção.
  • A rede Front-end é onde você expõe o endereço IP virtual (VIP). O HAProxy balanceará e encaminhará o tráfego para o back-end apropriado.

O diagrama abaixo ilustra uma implantação do HAProxy usando uma topologia de Rede de Front-end (Frontend Network). O diagrama indica onde os campos de configuração são esperados durante o processo de instalação e configuração.

""

Supervisor Topologia com uma rede de carga de trabalho e HAProxy com duas NICs virtuais

Nesta topologia, você configura um Supervisor com uma Workload Network para os seguintes componentes:

  • VMs do plano de controle do Kubernetes
  • Os nós de clusters Tanzu Kubernetes Grid.
  • O intervalo de IP virtual do HAProxy ao qual serviços externos e usuários de DevOps se conectam. Nessa configuração, o HAProxy é implementado com duas NICs virtuais (configuração Padrão (Default)), uma conectada à rede de gerenciamento e outra conectada à rede de carga de trabalho primária. Você deve planejar a alocação de IPs Virtuais em uma sub-rede separada da Rede de Carga de Trabalho Primária.
Você designa um grupo de portas como a Rede de Carga de Trabalho Primária para o Supervisor e, em seguida, usa o mesmo grupo de portas que a Rede de Carga de Trabalho para vSphere Namespaces. Supervisor, Tanzu Kubernetes Grid clusters, HAProxy, usuários de DevOps e serviços externos se conectam ao mesmo grupo de portas distribuídas que está definido como a Rede de Carga de Trabalho Primária.
Figura 1. Supervisor Suportado por uma rede

O diagrama mostra um Supervisor com um grupo de portas distribuído servindo para a carga de trabalho e o tráfego de gerenciamento.
O caminho de tráfego para usuários de DevOps ou aplicativos externos é o seguinte:
  1. O usuário do DevOps ou o serviço externo envia o tráfego para um IP virtual na sub-rede Workload Network do grupo de portas distribuídas.
  2. O HAProxy balanceia a carga do tráfego de IP virtual para o IP do nó de cluster Tanzu Kubernetes Grid ou o IP da VM do plano de controle. O HAProxy reivindica o endereço IP virtual para que ele possa balancear a carga do tráfego proveniente desse IP.
  3. A VM do plano de controle ou o nó de cluster Tanzu Kubernetes Grid entrega o tráfego para os pods de destino em execução dentro do cluster Supervisor ou Tanzu Kubernetes Grid, respectivamente.

Supervisor Topologia com uma rede de carga de trabalho isolada e um proxy de alta disponibilidade com duas NICs virtuais

Nesta topologia, você configura redes para os seguintes componentes:
  • VMs do plano de controle do Kubernetes. Uma rede de carga de trabalho primária para manipular o tráfego para VMs do plano de controle do Kubernetes.
  • Tanzu Kubernetes Grid nós de cluster. Uma rede de carga de trabalho. que você atribui a todos os namespaces no Supervisor. Essa rede conecta os nós de cluster Tanzu Kubernetes Grid.
  • IPs virtuais do HAProxy. Nessa configuração, a VM do HAProxy é implantada com duas NICs virtuais (configuração Padrão (Default)). Você pode conectar a VM do HAProxy à Rede de Carga de Trabalho Primária ou à Rede de Carga de Trabalho que você usa para namespaces. Você também pode conectar o HAProxy a uma rede de VMs que já existe em vSphere e é roteável para as redes Primária e de Carga de Trabalho.
O Supervisor está conectado ao grupo de portas distribuídas que suporta a Rede de Carga de Trabalho Primária e os clusters Tanzu Kubernetes Grid estão conectados a um grupo de portas distribuídas que suporta a Rede de Carga de Trabalho. Os dois grupos de portas devem ser roteáveis de camada 3. Você pode implementar o isolamento da camada 2 por meio de VLANs. A filtragem de tráfego de camada 3 é possível por meio de firewalls IP e gateways.
Figura 2. Supervisor com uma rede de carga de trabalho isolada

""
O caminho de tráfego para usuários de DevOps ou serviço externo é o seguinte:
  1. O usuário do DevOps ou o serviço externo envia o tráfego para um IP virtual. O tráfego é roteado para a rede à qual o HAProxy está conectado.
  2. O HAProxy equilibra a carga do tráfego de IP virtual para o IP do nó Tanzu Kubernetes Grid ou para a VM do plano de controle. O HAProxy está reivindicando o endereço IP virtual para que ele possa balancear a carga do tráfego proveniente desse IP.
  3. A VM do plano de controle ou o nó de cluster Tanzu Kubernetes Grid entrega o tráfego para os pods de destino em execução dentro do cluster Tanzu Kubernetes Grid.

Supervisor Topologia com várias redes de carga de trabalho e proxy de alta disponibilidade com duas NICs virtuais

Nessa topologia, você pode configurar um grupo de portas para atuar como a Rede de Carga de Trabalho Primária e um grupo de portas dedicado para servir como a Rede de Carga de Trabalho para cada namespace. O HAProxy é implementado com duas NICs virtuais (configuração Padrão (Default)) e você pode conectá-lo à Rede de Carga de Trabalho Primária ou a qualquer uma das Redes de Carga de Trabalho. Você também pode usar uma rede de VMs existente que é roteável para as redes primária e de carga de trabalho.

O caminho do tráfego para os usuários de DevOps e os serviços externos nessa topologia é o mesmo da topologia de Rede de Carga de Trabalho isolada.
Figura 3. Supervisor Suportado por várias redes de carga de trabalho isoladas

""

Supervisor Topologia com várias redes de carga de trabalho e proxy de alta disponibilidade com três NICs virtuais

Nessa configuração, você implanta a VM do HAProxy com três NICs virtuais, conectando o HAProxy a uma rede Front-end. Os usuários de DevOps e os serviços externos podem acessar o HAProxy por meio de IPs virtuais na rede Front-end. A implantação do proxy de alta disponibilidade com três NICs virtuais é recomendada para ambientes de produção.
Figura 4. HAProxy implantado com três NICs virtuais

""

Selecionando entre as possíveis topologias

Antes de selecionar entre cada uma das topologias possíveis, avalie as necessidades do seu ambiente:

  1. Você precisa de isolamento de camada 2 entre os clusters Supervisor e Tanzu Kubernetes Grid?
    1. Não: a topologia mais simples com uma Workload Network atendendo a todos os componentes.
    2. Sim: a topologia de Rede de Carga de Trabalho isolada com uma Rede Primária e uma Rede de Carga de Trabalho separadas.
  2. Você precisa de mais isolamento de camada 2 entre seus clusters Tanzu Kubernetes Grid?
    1. Não: topologia de rede de carga de trabalho isolada com Redes Primária e de Carga de Trabalho separadas.
    2. Sim: topologia de várias redes de carga de trabalho com uma Rede de Carga de Trabalho separada para cada namespace e uma Rede de Carga de Trabalho Primária dedicada.
  3. Deseja impedir que seus usuários de DevOps e serviços externos roteiem diretamente para VMs do plano de controle do Kubernetes e Tanzu Kubernetes Grid nós de cluster?
    1. Não: duas configurações de NIC HAProxy.
    2. Sim: configuração de três NICs HAProxy. Essa configuração é recomendada para ambientes de produção

Considerações sobre o uso do balanceador de carga do HAProxy com o vSphere with Tanzu

Lembre-se das seguintes considerações ao planejar um vSphere with Tanzu com o balanceador de carga do HAProxy.

  • É necessário um contrato de suporte com o HAProxy para obter suporte técnico para o balanceador de carga do HAProxy. VMware O GSS não pode fornecer suporte para o dispositivo HAProxy.
  • O dispositivo HAProxy é um singleton sem possibilidade de uma topologia de alta disponibilidade. Para ambientes altamente disponíveis, VMware recomenda que você use uma instalação completa do NSX ou do NSX Advanced Load Balancer.
  • Não é possível expandir o intervalo de endereços IP usado para o front-end posteriormente, o que significa que a rede deve ser dimensionada para todo o crescimento futuro.