VCF 9 – Parte 5: Configuring vSphere Supervisor with NSX VPC Networking

INTRODUÇÃO

O VMware Cloud Foundation 9 (VCF 9) trouxe um modelo de rede mais moderno e alinhado à nuvem pública, adotando o NSX VPC Networking como base para os domínios de workload. Nesse modelo, cada VPC oferece um ambiente de rede isolado, com seus próprios segmentos, políticas e conectividade, mas ainda assim gerenciado de forma centralizada pelo time de infraestrutura.

Se olharmos para os principais provedores de nuvem pública, como AWS EKS, Google GKE e Azure AKS, o desenho é parecido do ponto de vista de consumo: o cliente cria um cluster Kubernetes, mas o control plane é totalmente gerenciado pelo provedor, rodando em VPCs/projetos controlados por eles, sem acesso direto às VMs de master ou aos componentes internos do cluster.

No VCF 9 com vSphere Supervisor, a experiência é diferente: você continua tendo uma experiência de Kubernetes gerenciado, porém o control plane roda dentro do seu próprio ambiente vSphere, em VMs que usam o seu storage, as suas redes e seguem as suas políticas de backup, segurança e observabilidade. É, na prática, trazer o modelo de “managed Kubernetes” para dentro da sua nuvem privada, sem abrir mão do controle sobre a infraestrutura.

Dentro desse contexto, o vSphere Supervisor é o componente que habilita o uso de Kubernetes de forma nativa no vSphere, permitindo que times de aplicação consumam namespaces, clusters e redes já preparadas pela equipe de infra, agora apoiadas no modelo de NSX VPC.

Nesta Parte 5 da série “VCF 9”, vamos ver como configurar o vSphere Supervisor utilizando NSX VPC Networking, conectando o cluster vSphere a uma VPC existente e preparando o ambiente para receber workloads Kubernetes com isolamento e governança de rede adequados.

REQUISITOS

Antes de ativar o Supervisor, confirme que:

• O cluster vSphere possui no mínimo 3 hosts ESXi e está com DRS em Fully Automated e vSphere HA habilitado.
• O NSX já está integrado ao vCenter que gerencia esse cluster.
• Você possui um NSX Project e uma VPC já criados, com:
  • VPC Connectivity Profile definido;
  • External IP Block e Private Transit Gateway IP Block;
  • CIDRs privados da VPC configurados;
  • T0 em modo Active/Standby (requisito para VPCs com NAT/LB).
• Você seguiu a parte 4 da série VCF 9.

Esses elementos serão consumidos automaticamente pelo wizard de ativação do Supervisor.

CONFIGURAÇÃO

Etapa 0 – Desabilitando o faillover capacity do admission control

Se o cluster vSphere no qual você deseja habilitar o vSphere Supervisor contiver apenas um hosts ESX conforme a parte 3 do VCF 9, você provavelmente encontrará um problema de verificação de admissão de alta disponibilidade do vSphere na Etapa 2. Para contornar isso, basta ajustar o Controle de Admissão de Alta Disponibilidade do vSphere (selecione Cluster vSphere em Configurar -> Disponibilidade do vSphere ) e desabilitar a configuração de failover de host padrão.

Etapa 1 – Desabilitando alertas vSAN skyline health

Nosso ambiente é stanalone copm vsan configurado, portanto, devemos desabilitar todos os alertas vsan se qusiermos que o supervisor prossiga com a instalação.

Deve ficar assim:

Etapa 2 – Iniciar o assistente de ativação do Supervisor

No vSphere Client:

1. Localize o seu cluster vSphere que será usado como Supervisor.
2. Clique com o botão direito do mouse sobre o cluster.
3. Selecione a opção Ativar Supervisor (Activate Supervisor).

Isso abre o assistente de configuração do Supervisor para esse cluster.

Etapa 3 – Selecionar a topologia “VCF Networking with VPC”

Assim que a janela Activate Supervisor for exibida, clique em Advanced Topologies, no canto superior direito. Em seguida, o assistente abrirá a tela vCenter Server and Network.

Nessa tela, confirme o seu vCenter Server e, em Select a networking stack, selecione a opção VCF Networking with VPC.

Essa escolha é fundamental, pois é ela que garante que todo o tráfego do Supervisor e dos workloads Kubernetes será provisionado utilizando o modelo de NSX VPC Networking, em vez do modo clássico de rede.

Etapa 4 – Definir o local do Supervisor (nome e cluster)

Na tela Supervisor location:

1. Selecione a opção Cluster Deployment (implantação em um único cluster vSphere).
2. Em Supervisor name, defina um nome amigável para o seu ambiente, por exemplo: SUPERVISOR-WARRIOR-01.
3. Em Cluster selection, marque o cluster compatível onde o Supervisor será ativado (no exemplo, VCF-Mgmt-Cluster).
4. Caso o cluster já esteja associado a uma vSphere Zone, o nome da zona será exibido e não poderá ser alterado.

Depois de revisar essas informações, clique em Next para seguir para a configuração de storage.

Etapa 5 – Selecionar a Storage Policy para o Supervisor

Na tela Storage, o assistente solicita a Storage Policy que será utilizada para armazenar as VMs de control plane do Supervisor.

1. Em Control Plane Storage Policy, selecione a política de storage desejada (no exemplo, VCF-Mgmt-Cluster – Optimal Datastore).
2. Dê preferência a uma policy já validada para o seu cluster, normalmente baseada em vSAN ou no datastore principal do ambiente.

Após escolher a política de storage, clique em Next para avançar para a configuração da Management Network.

Etapa 6 – Configurar a Management Network do Supervisor

Na tela Management Network, vamos definir a rede de gestão dos nós de control plane do Supervisor.

1. Em Network Mode, selecione Static.
2. Em Network, escolha o port group/segment que será usado para a gestão (no exemplo, DVPG_FOR_VM_MANAGEMENT).
3. Em IP Addresses, informe um range de IPs para os nós do Supervisor
   • Ex.: 192.168.79.180–192.168.79.200.
4. Preencha os demais campos de acordo com sua rede:
   • Subnet Mask: 255.255.255.0
   • Gateway: 192.168.79.254
   • DNS Server(s): 192.168.79.10
   • DNS Search Domain(s): virtualizandoaju.com.br
   • NTP Server(s): 192.168.79.10

Essa rede é responsável pela conectividade e resolução de nomes dos nós do Supervisor, por isso é importante usar IPs estáveis e serviços de DNS/NTP confiáveis.

Depois de preencher tudo, clique em Next para seguir para a configuração da Workload Network.

Etapa 7 – Configurar a Workload Network baseada em VPC

Na tela Workload Network é onde ligamos o Supervisor ao modelo de NSX VPC:

1. Em NSX Project, selecione o projeto que contém a sua VPC (no exemplo, Default).
2. Em VPC Connectivity Profile, escolha o profile associado a essa VPC (ex.: Default VPC Connectivity Profile).
3. Em External IP Blocks, selecione o bloco de IP público/externo que será usado para SNAT e Load Balancer dos workloads Kubernetes.
4. Em Private (Transit Gateway) IP Blocks, selecione o bloco privado usado no Transit Gateway da VPC.
5. Em Private (VPC) CIDRs, informe o(s) CIDR(s) que serão utilizados dentro da VPC para as redes dos workloads
   • Ex.: 172.26.0.0/16.
6. Em Service CIDR, defina o range usado internamente pelo Kubernetes para os ClusterIP Services
   • Ex.: 10.96.0.0/23.
7. Em DNS Server(s), informe o servidor DNS que será usado pelos workloads
   • Ex.: 192.168.79.10.

Revise os parâmetros e, em seguida, clique em Next para avançar para as configurações avançadas (Advanced Settings).

Etapa 8 – Ajustar as configurações avançadas do Supervisor

Na tela Advanced Settings, fazemos os últimos ajustes do deployment:

1. Em Supervisor Control Plane Size, selecione o tamanho do control plane.
   • Para ambientes de lab ou teste, o perfil Tiny (2 vCPUs, 8 GB RAM, 48 GB de disco) é suficiente.
   • Em produção, escolha o tamanho de acordo com o número esperado de namespaces e workloads.
2. Em API Server DNS Name(s), informe o FQDN que será utilizado para acessar a API do Supervisor via kubectl e outras ferramentas.
   • Ex.: supervisor-prod.virtualizandoaju.com.br.
   • Garanta que esse FQDN tenha um registro de DNS apontando para o IP do Supervisor.
3. Marque a opção Export configuration se quiser gerar um arquivo com todas as configurações do deployment.
   • Isso é útil para documentação, automação futura ou para repetir a mesma configuração em outro ambiente.

Concluída essa etapa, clique em Next para ir à tela Ready to complete, onde revisaremos todo o resumo antes de iniciar a ativação do Supervisor.

Etapa 9 – Resumo

Etapa 10 – Acompanhe a instalação em Supervisor Management.

Etapa 11 – Crie um contet libary para associar a um namespace

Selecione Subscribed content library e use a url: https://wp-content.vmware.com/supervisor/v1/latest/lib.json

Finish.

Etapa 12 – Validar a Content Library de imagens do Supervisor

Após a ativação do Supervisor, vale conferir se a Content Library usada para armazenar as imagens do Supervisor está corretamente associada.

No vSphere Client, acesse:

1. Menu → Workload Management → Content Distribution.
2. Em Supervisor Images Library, verifique o campo Assigned Library Name (no exemplo, vSphere Supervisor).
3. Confirme também o espaço disponível em Storage, garantindo que a datastore tem capacidade suficiente para receber futuras imagens e atualizações do Supervisor.

Se a Content Library correta estiver atribuída e com espaço livre adequado, sua infraestrutura está pronta para receber novas versões de componentes e imagens relacionadas ao Supervisor e aos serviços adicionais.

CONCLUSÃO

Ao habilitar o vSphere Supervisor utilizando o modelo de NSX VPC Networking no VCF 9, você dá um passo importante para aproximar a sua nuvem privada da experiência das grandes nuvens públicas – porém mantendo o control plane dentro do seu próprio vSphere, sob as suas políticas de segurança, backup e observabilidade. Em vez de depender de um control plane totalmente gerenciado por um provedor externo, como acontece em AWS EKS, GKE ou AKS, você passa a ter um Kubernetes “as a Service” rodando em cima da infraestrutura que você já domina.

O passo a passo que seguimos aqui – desde os pré-requisitos, passando pela escolha da topologia VCF Networking with VPC, configuração das redes de Management e Workload, até a validação da Content Library – entrega um Supervisor pronto para receber namespaces e clusters Kubernetes com isolamento de rede, endereçamento bem definido e integração nativa com o NSX. Isso simplifica a vida do time de infraestrutura e, ao mesmo tempo, oferece uma experiência mais padronizada e previsível para os times de desenvolvimento.

A partir desse ponto, o foco passa a ser o consumo do Supervisor: criação de namespaces, definição de quotas, publicação de imagens via Content Library e exposição de serviços de forma segura através da VPC. Nos próximos capítulos da série “VCF 9”, vamos explorar justamente esse lado “dia a dia”: como os times de aplicação podem consumir esse ambiente, e como o time de infraestrutura pode manter governança sem perder agilidade.

Mensagem do dia:

“Nunca imites ninguém. Que a tua produção seja como um novo fenômeno da natureza.”

Leonardo da Vinci