Para configurar o vSphere with Tanzu com o NSX Advanced Load Balancer, também conhecido como Balanceador de Carga Avi, seu ambiente deve atender a certos requisitos. O vSphere with Tanzu oferece suporte a várias topologias para a rede Avi: uma única rede VDS para o Mecanismo de Serviço Avi e serviços de balanceador de carga e um VDS para o plano de gerenciamento Avi e outro VDS para o NSX Advanced Load Balancer.

Redes de carga de trabalho

Para configurar um Supervisor Cluster com a pilha de rede do vSphere, você deve conectar todos os hosts do cluster a um vSphere Distributed Switch. Dependendo da topologia que você implementar para o Supervisor Cluster, crie um ou mais grupos de portas distribuídas. Você designa os grupos de portas como Redes de Carga de Trabalho para vSphere Namespaces.

Antes de adicionar um host a um Supervisor Cluster, você deve adicioná-lo a todos os vSphere Distributed Switches que fazem parte do cluster.

As redes de carga de trabalho fornecem conectividade aos nós dos clusters Tanzu Kubernetes e às VMs de plano de controle do Supervisor Cluster. A rede de carga de trabalho que fornece conectividade às VMs do plano de controle do Kubernetes é chamada de rede de carga de trabalho primária. Cada Supervisor Cluster deve ter uma rede de carga de trabalho primária. Você deve designar um dos grupos de portas distribuídas como a rede de carga de trabalho primária para o Supervisor Cluster.
Observação: As redes de carga de trabalho só são adicionadas quando você ativa o Supervisor Cluster e não podem ser adicionadas mais tarde.

As VMs de plano de controle do Kubernetes no Supervisor Cluster usam três endereços IP do intervalo de endereços IP que é atribuído à rede de carga de trabalho primária. Cada nó de um cluster Tanzu Kubernetes tem um endereço IP separado atribuído do intervalo de endereços da Rede de Carga de Trabalho que é configurado com o namespace onde o cluster Tanzu Kubernetes é executado.

Requisitos de rede

O NSX Advanced Load Balancer requer duas sub-redes roteáveis:
  • A rede de gerenciamento. A rede de gerenciamento é onde o controlador Avi, também chamado de controlador, reside. A rede de gerenciamento fornece ao controlador conectividade com os hosts vCenter Server, ESXi e os nós do plano de controle Supervisor Cluster. Essa rede pode usar um vSphere Standard Switch (vSS) ou um vSphere Distributed Switch (VDS).
  • A rede de dados. Os Avi Service Engines, também chamados de Service Engines, são executados nesta rede. Essa rede requer um vSphere Distributed Switch (VDS) e um grupo de portas distribuído. Você deve configurar o VDS e os grupos de portas antes de instalar o balanceador de carga.

Alocação de endereços IP

O controlador e o mecanismo de serviço estão conectados à rede de gerenciamento. Ao instalar e configurar o NSX Advanced Load Balancer, forneça um endereço IP estático e roteável para cada VM do controlador.

Os Mecanismos de Serviço podem usar DHCP. Se o DHCP não estiver disponível, você poderá configurar um pool de endereços IP para os Mecanismos de Serviço.

Para obter mais informações, consulte Configurar rotas estáticas.

Requisitos mínimos de processamento

A tabela lista os requisitos mínimos de processamento para a rede vSphere com NSX Advanced Load Balancer.
Tabela 1. Requisitos mínimos de processamento
Sistema Tamanho mínimo de implantação CPU Memória Armazenamento
vCenter Server 7.0 7.0.2 Pequeno 2 16 GB 290 GB
ESXi hosts 7.0 3 ESXi hosts com 1 IP estático por host.

Se você estiver usando o vSAN: 3 hosts ESXi com pelo menos 2 NICs físicas é o mínimo; no entanto, 4 hosts ESXi são recomendados para resiliência durante a aplicação de patches e a atualização.

Os hosts devem ser unidos em um cluster com o vSphere DRS e HA habilitados. O vSphere DRS deve estar no modo Totalmente Automatizado ou Parcialmente Automatizado.
Observação: Certifique-se de que os nomes dos hosts que ingressam no cluster usem letras minúsculas. Caso contrário, a ativação do cluster para o Gerenciamento de Carga de Trabalho poderá falhar.
8 64 GB por host Não aplicável
VMs de plano de controle do Kubernetes 3 4 16 GB 16 GB

Requisitos mínimos de rede

A tabela lista os requisitos mínimos de rede para a rede vSphere com NSX Advanced Load Balancer.

Tabela 2. Requisitos mínimos de rede
Componente Quantidade Mínima Configuração necessária
IPs estáticos para VMs do plano de controle do Kubernetes Bloco de 5 Um bloco de 5 endereços IP estáticos consecutivos a serem atribuídos às VMs do plano de controle do Kubernetes no Supervisor Cluster.
Rede de tráfego de gerenciamento 1 Uma rede de gerenciamento que é roteável para os hosts ESXi, vCenter Server, o Supervisor Cluster e o balanceador de carga. A rede deve ser capaz de acessar um registro de imagem e ter conectividade com a Internet se o registro de imagem estiver na rede externa. O registro da imagem deve ser resolvido por meio do DNS.
vSphere Distributed Switch 1 Todos os hosts do cluster devem ser conectados a um vSphere Distributed Switch.
Redes de carga de trabalho 1 Pelo menos um grupo de portas distribuídas deve ser criado no vSphere Distributed Switch que você configura como a rede de carga de trabalho primária. Dependendo da topologia de escolha, você pode usar o mesmo grupo de portas distribuídas que a Rede de Carga de Trabalho de namespaces ou criar mais grupos de portas e configurá-los como Redes de Carga de Trabalho. As redes de carga de trabalho devem atender aos seguintes requisitos:
  • As Redes de Carga de Trabalho que são usadas para o tráfego de cluster do Tanzu Kubernetes devem ser roteáveis entre si e a Rede de Carga de Trabalho Primária Supervisor Cluster.
  • Capacidade de roteamento entre qualquer rede de carga de trabalho com a rede que o NSX Advanced Load Balancer usa para alocação de IP virtual.
  • Sem sobreposição de intervalos de endereços IP em todas as redes de carga de trabalho em um Supervisor Cluster.
Servidor NTP e DNS 1 Um servidor DNS e um servidor NTP que podem ser usados com o vCenter Server.
Observação: Configure o NTP em todos os hosts ESXi e vCenter Server.
Servidor DHCP 1 Opcional. Configure um servidor DHCP para adquirir automaticamente endereços IP para as redes de gerenciamento e carga de trabalho, bem como IPs flutuantes. O servidor DHCP deve oferecer suporte a identificadores de cliente e fornecer servidores DNS compatíveis, domínios de pesquisa DNS e um servidor NTP.

Para a rede de gerenciamento, todos os endereços IP, como IPs de VM de plano de controle, um IP flutuante, servidores DNS, DNS, domínios de pesquisa e servidor NTP são adquiridos automaticamente do servidor DHCP.

A configuração DHCP é usada pelo Supervisor Cluster. Os balanceadores de carga podem exigir endereços IP estáticos para gerenciamento. Os escopos DHCP não devem se sobrepor a esses IPs estáticos. O DHCP não é usado para IPs virtuais. (VIPs)
Sub-rede de gerenciamento 1
A rede de gerenciamento é onde o controlador Avi, também chamado de controlador, reside. A sub-rede usada para o tráfego de gerenciamento entre ESXi hosts e vCenter Server, e o plano de controle do Kubernetes. O tamanho da sub-rede deve ser o seguinte:
  • Um endereço IP por adaptador de kernel de VM do host.
  • Um endereço IP para o vCenter Server Appliance.
  • 5 endereços IP para o plano de controle do Kubernetes. 1 para cada um dos 3 nós, 1 para IP virtual e 1 para atualização contínua do cluster.
Observação: A rede de gerenciamento e a rede de carga de trabalho devem estar em sub-redes diferentes. A atribuição da mesma sub-rede às redes de gerenciamento e de carga de trabalho não tem suporte e pode levar a erros e problemas do sistema.
Sub-rede de dados 1 Os Avi Service Engines, também chamados de Service Engines, são executados nesta rede. Configure um pool de endereços IP para os Mecanismos de Serviço.
VLAN de rede de gerenciamento 1 A ID de VLAN da sub-rede da rede de gerenciamento.
Rede física MTU 1600 O tamanho da MTU deve ser 1600 ou maior em qualquer rede que transporte tráfego de sobreposição.
Intervalo CIDR de serviços do Kubernetes / 16 Endereços IP privados Um intervalo CIDR privado para atribuir endereços IP aos serviços do Kubernetes. Você deve especificar um intervalo de CIDR de serviços Kubernetes exclusivo para cada Supervisor Cluster.