Resumo do Webinar: Considerações de Design e Arquitetura para VMware vSphere Kubernetes Service no VMware Cloud Foundation

Obtenha insights e considerações de design para o VMware vSphere Kubernetes Service no VMware Cloud Foundation (VCF) a partir deste resumo do nosso recente webinar.

Aplicações modernas exigem mais do que apenas um lugar para serem executadas; elas demandam um ecossistema completo para prosperar. As implementações atuais vão muito além de simples máquinas virtuais ou contêineres, necessitando de um amplo conjunto de serviços prontos para produção — como balanceadores de carga, storage persistente, registries e monitoramento integrado — para funcionar eficazmente. Construir uma verdadeira plataforma de cloud significa ir além da computação bruta para criar um ambiente unificado onde a infraestrutura e os serviços cloud-native são integrados de forma transparente. O VCF entrega essa plataforma abrangente, permitindo que as aplicações consumam os serviços de que precisam de forma consistente.

Recentemente, co-organizei um webinar com Caleb Washburn, CTO da MomentumAI, onde detalhamos como usar o VCF com o VMware vSphere Supervisor para estabelecer esse ambiente integrado. Ao convergir VMs, contêineres e clusters Kubernetes em um único painel de gerenciamento controlado por uma API declarativa, você pode automatizar o gerenciamento do ciclo de vida e focar nos resultados das workloads, em vez de se prender a tarefas manuais e imperativas.

A Fundação: Transformando Clusters VMware ESX em Clusters Kubernetes

Em sua essência, habilitar o vSphere Supervisor transforma um cluster ESX padrão em um cluster Kubernetes de alta funcionalidade. Essa mudança arquitetônica redefine as funções da sua infraestrutura existente:

• Worker Nodes: Cada host ESX se torna um worker node responsável por executar as workloads.
• The Control Plane: É implementado como um conjunto de VMs que gerenciam todas as operações do control plane e expõem uma API declarativa baseada em Kubernetes.
• Spherelet: Uma implementação customizada do Kubelet, nativa do ESX, é instalada em cada host ESX para gerenciar a comunicação.
• Unified Management: Essa arquitetura permite que os consumidores gerenciem a plataforma usando ferramentas familiares como o kubectl.

Uma vez habilitado, o vSphere Supervisor entrega um conjunto de serviços essenciais com ciclos de vida independentes. Isso inclui o vSphere Kubernetes Service (VKS) para gerenciar clusters conformes, um VM Service para gerenciar máquinas virtuais via um modelo de estado desejado, e add-ons essenciais como o Harbor Image Registry e secret stores.

Estratégia Arquitetural: Design de Zona de Disponibilidade

Um passo crítico na implantação do vSphere Supervisor é determinar o modelo correto de zona de disponibilidade (AZ). Uma zona de disponibilidade representa um constructo lógico de um domínio de falha físico independente — como uma sala de servidores ou rack específico — e geralmente mapeia diretamente para um único cluster vSphere. O webinar destacou quatro modelos de implantação distintos, variando de configurações simples de desenvolvimento a configurações empresariais de alta resiliência:

1. Zona de Gerenciamento Única com Zona de Workload Combinada Este é o modelo mais direto, onde o vSphere Supervisor é habilitado diretamente em uma zona vSphere.

• Melhor Uso: Ambientes de desenvolvimento, teste, não produção, ou workloads de produção que não exigem tolerância a falhas em nível de site.
• Vantagens: Rápido de implantar, requer hardware mínimo e usa menos licenças.
• Atenção: Uma falha em nível de cluster (energia, rede ou storage) afeta tanto o vSphere Supervisor quanto as workloads.

2. Zona de Gerenciamento Única com Zonas de Workload Isoladas Neste modelo, o control plane permanece em uma zona de gerenciamento dedicada, enquanto as workloads são distribuídas por uma ou mais zonas separadas.

• Melhor Uso: Ambientes de produção de médio porte que exigem uma clara separação entre os planos de gerenciamento e workload.
• Vantagens: As workloads podem ser distribuídas para maior disponibilidade, mantendo o control plane simples.
• Atenção: Há um aumento nos requisitos de hardware e maior esforço de configuração de rede em comparação com a zona de gerenciamento única com zona de workload combinada.

3. Três Zonas de Gerenciamento com Zonas de Workload Combinadas Este modelo distribui as VMs do control plane do vSphere Supervisor por três zonas vSphere para garantir alta disponibilidade e quorum.

• Melhor Uso: Ambientes de produção que exigem forte resiliência e a capacidade de tolerar uma única falha de cluster.
• Vantagens: Maior variabilidade do control plane e melhor disponibilidade para workloads distribuídas por três zonas.
• Atenção: Há menos isolamento entre o control plane e as workloads e custos mais altos.

4. Três Zonas de Gerenciamento com Zonas de Workload Isoladas O modelo mais robusto apresenta um control plane de alta disponibilidade em três zonas de gerenciamento dedicadas e workloads em zonas isoladas adicionais.

• Melhor Uso: Implantações de produção de missão crítica que exigem os mais altos níveis de segurança, isolamento e disponibilidade.
• Vantagens: Resiliência máxima e suporte total para recursos avançados de Kubernetes com reconhecimento de zona.
• Atenção: Este modelo de implantação possui requisitos significativos de hardware e licenciamento.

Rede: Uma Escolha Crítica de Design Inicial

As decisões de rede são fundamentais; escolher um stack durante a habilitação do vSphere Supervisor é uma decisão crítica, pois alterá-lo posteriormente geralmente exige a desativação e reconstrução do vSphere Supervisor.

• VDS Networking: O Virtual Distributed Switch (VDS) representa a abordagem de rede tradicional. Ele segmenta o tráfego de gerenciamento e workload usando grupos de portas e fornece um espaço de rede plano e roteável. É a escolha ideal para ambientes existentes onde as equipes ainda não estão prontas para um stack de rede totalmente definido por software.
• VMware NSX Virtual Private Cloud: A abordagem "mais recente e avançada", o NSX Virtual Private Cloud (VPC) networking, espelha a experiência de ambientes de cloud pública. Ele oferece isolamento de alto nível entre tenants e é profundamente integrado à automação do VMware Cloud Foundation para provisionamento self-service. Este é o caminho inicial recomendado para qualquer nova implantação de Kubernetes no VCF.
• NSX Segment Networking: Isso fornece isolamento semelhante ao modelo VPC, mas é gerenciado por meio de interações tradicionais de segmento NSX, em vez do portal self-service de automação do VCF. É tipicamente preferido por organizações que já estão profundamente familiarizadas com o gerenciamento de segmentos NSX em seus ambientes existentes.

Opções de Load Balancing Quando consideramos as opções de load balancing dentro do VCF, as categorizamos com base no seu stack de rede escolhido para fornecer o ajuste certo para seus requisitos de tráfego específicos:

• Foundation Load Balancer: Um balanceador Layer 4 "tudo incluído" para VDS networking que substitui as soluções HA Proxy mais antigas.
• VMware Avi Load Balancer: A opção premium que oferece recursos de Layer 4-7, incluindo web application firewall (WAF), gerenciamento de certificados e DNS avançado.
• NSX Classic Load Balancer: Um stack Layer 4 virtualizado fornecido pronto para uso em ambientes NSX.

Opções de CNI No provisionamento de clusters Kubernetes, a seleção de uma Container Network Interface (CNI) é uma decisão por cluster que oferece flexibilidade em comparação com o stack de rede subjacente mais rígido. O padrão recomendado é o Antrea, que é favorecido por sua profunda integração com o stack NSX via Antrea-NSX Adapter, permitindo recursos avançados e compatibilidade com a solução de segurança vDefend. Alternativamente, o Project Calico está disponível como uma opção suportada para usuários que priorizam uma experiência CNI consistente em diversos ambientes de cloud pública ou privada. Embora a escolha da CNI possa ser adiada ou decidida cluster por cluster, ela é distinta das decisões fundamentais de rede do vSphere Supervisor — como VDS ou NSX VPC — que são permanentes uma vez habilitadas e exigem uma desativação e reconstrução completas para serem alteradas.

Storage e Multi-Tenancy

Finalmente, revisamos os limites lógicos usados para gerenciar recursos: vSphere Namespaces. Um namespace atua como uma extensão de um vSphere resource pool e mapeia diretamente para um Kubernetes namespace. É através dessa construção que os administradores alcançam a multi-tenancy, atribuindo cotas para storage, load balancers e image registries a equipes ou produtos específicos.

Quando se trata de storage, o vSphere Supervisor utiliza storage policies para impor cotas e determinar quais datastores são acessíveis às workloads.

• Read-Write-Once (RWO): Suportado pela maioria dos datastores e usado para aplicações stateful padrão.
• Read-Write-Many (RWX): Atualmente requer serviços de arquivo vSAN e é necessário para pods que precisam gravar no mesmo file store simultaneamente.

Ao considerar cuidadosamente esses elementos de design — zonas de disponibilidade, pilares de rede e storage policies — você pode construir uma cloud privada que não é apenas resiliente, mas também pronta para escalar com as demandas do desenvolvimento de aplicações modernas. E se precisar de assistência para projetar e construir sua solução, VCF Professional Services e MomentumAI podem ajudar. Basta entrar em contato com seu Broadcom Account Manager para saber mais.

Se você perdeu, assista à reprise do nosso webinar agora.

Descubra mais no Blog do VMware Cloud Foundation (VCF). Assine para receber as últimas postagens em seu e-mail.

Como parceiro certificado, a VirtuAllIT pode auxiliar sua empresa na implementação e otimização de soluções VMware Cloud Foundation, garantindo que sua infraestrutura esteja alinhada às necessidades de suas aplicações modernas. Entre em contato conosco para uma consultoria especializada.