TL;DR: Este artigo apresenta o virtbench, um framework open-source da Portworx para benchmarking de VMs no KubeVirt. Diferente de ferramentas focadas em containers, ele mede métricas operacionais reais — tempo até o guest OS responder, saturação do CSI provisioner sob múltiplos discos e stun time em live migration via overlay de rede. Para empresas brasileiras migrando de hypervisors tradicionais, o virtbench permite detectar regressões antes da produção e validar SLAs de infraestrutura cloud-native.
Organizações que migram seus parques de VMs de hypervisors tradicionais para o KubeVirt frequentemente descobrem que muitas ferramentas de observabilidade do Kubernetes foram originalmente projetadas para cargas de trabalho de containers, e não para métricas operacionais centradas em VMs. Embora o KubeVirt agende VMs como pods, as variáveis de desempenho são fundamentalmente diferentes — a latência do scheduler do Kubernetes, a vazão do provisioner CSI e a sobrecarga da overlay SDN interagem de maneiras que as métricas padrão do kubectl e o monitoramento em nível de pod não revelam.
Os times de plataforma precisam de respostas quantificáveis e reproduzíveis para perguntas que benchmarks de containers ignoram:
- Time-to-Ready: tempo real (wall-clock) desde a chamada à API até a acessibilidade confirmada da rede do guest OS — não
pod/Running. - Burst Capacity: comportamento do plano de controle e do subsistema de armazenamento sob requisições concorrentes de criação de VMs (boot storm).
- Live Migration Stun Time: janela precisa de interrupção no nível de rede durante a live migration de uma VMI sobre a overlay de rede.
Para ajudar a medir essas características operacionais, desenvolvemos o KubeVirt Performance Benchmarking Toolkit (virtbench), um framework CLI open-source para executar testes de estresse reproduzíveis em clusters com KubeVirt habilitado, incluindo KubeVirt no OpenShift e outros ambientes que usam armazenamento compatível com CSI.
Como o KubeVirt exige uma abordagem de benchmarking diferente?
As ferramentas padrão de observabilidade do Kubernetes podem retornar um status saudável mesmo quando cargas de trabalho do tipo VM estão degradadas. Três incompatibilidades arquiteturais explicam o porquê:
Pod readiness ≠ VM readiness. A condição Ready do Kubernetes é satisfeita quando o processo do container inicia — geralmente em milissegundos. Uma VMI do KubeVirt não está operacionalmente pronta até que o kernel convidado inicialize, os serviços user-space sejam iniciados e o guest agent reporte um heartbeat. Benchmarks que param o cronômetro no pod/Running distorcem o tempo real de readiness em minutos em implantações típicas. O virtbench usa um ssh-test-pod dentro do cluster para sondar continuamente a pilha de rede da VMI; a medição só conclui quando a conectividade SSH é confirmada.
Carga do provisioner CSI sob VMs com múltiplos discos. VMs em produção geralmente exigem múltiplos PVCs por instância — um volume de boot, um volume de swap e um ou mais volumes de dados com alta IOPS. Benchmarks focados em containers não exercitam a capacidade do driver CSI de provisionar e anexar simultaneamente múltiplos block devices a uma única VMI. O virtbench simula essas configurações, exercitando todo o pipeline DataVolume → PVC → block device sob carga.
Live migration via overlay de rede vs. vMotion. O vMotion transfere o estado da memória em execução por um canal TCP dedicado de alta banda. A live migration do KubeVirt tunela a mesma transferência de memória através da overlay SDN do cluster (ex.: OVN-Kubernetes), adicionando latência e competindo com o tráfego de workload. O virtbench mede o stun time — a janela durante a qual a interface de rede da VMI fica indisponível — para cenários de migração sequencial e paralela.
Como o virtbench mede o readiness de VMs?
O virtbench usa um modelo de orquestração do lado do cliente com um pod auxiliar dentro do cluster. O pipeline de medição funciona da seguinte forma:
- API Trigger:
virtbenchsubmete objetosVirtualMachineao API server do Kubernetes, que cria os recursosDataVolumeePVCassociados via driver CSI. - State Machine Tracking: A CLI monitora o status da VMI, rastreando toda a cadeia de transição:
Pending → Scheduled → Bound → Running. - Guest Network Probing: Um
ssh-test-podimplantado dentro do cluster emite sondagens TCP contínuas para o endereço IP atribuído a cada VMI. - Measurement Completion: O cronômetro é encerrado apenas no handshake TCP bem-sucedido — confirmando que a pilha de rede do guest está totalmente operacional.
Os resultados são emitidos como JSON e CSV estruturados, depois renderizados em um dashboard HTML interativo para análise. A ferramenta aciona quatro engines de benchmark internos — DataSource Clone, Migration, Capacity e Failure Recovery — cada um implementado como um módulo distinto contra as APIs do KubeVirt e de armazenamento.
Figura 1: Arquitetura do virtbench
Quais cenários de benchmark estão incluídos no virtbench?
O virtbench já acompanha seis cenários de teste prontos:
| Cenário | O que testa |
|---|---|
| DataSource VM Provisioning | Eficiência de clonagem do storage e tempos de criação de volumes |
| Single Node Boot Storm | Capacidade em nível de nó sob inicialização simultânea de VMs |
| Multi-Node Boot Storm | Desempenho de startup em todo o cluster; simula recuperação pós-falha |
| Live Migration | Stun time da migração de VMs; suporta execuções sequenciais e paralelas |
| Chaos Benchmark | Operações de caos concorrentes (criar, redimensionar, clonar, reiniciar, snapshot) |
| Failure and Recovery | Validação de HA via Fence Agents Remediation; mede tempo de recuperação |
Visualizando gargalos de desempenho
Os resultados são automaticamente renderizados em um dashboard HTML com múltiplos gráficos.
Figura 2: Dashboard de Performance
Cada gráfico corresponde a uma fase distinta de medição:
- Creation Duration (azul): Latência de provisionamento por VM sob carga sequencial — estabelece sua baseline de storage e scheduler.
- Boot Storm (verde): Latência de provisionamento sob N requisições concorrentes — expõe pontos de inflexão de saturação no driver CSI ou na vazão de escrita do etcd.
- Live Migration (laranja): Duração da migração e stun time por VMI durante a sequência de evacuação de nós — usado para limitar SLAs de janela de manutenção.
Uma tabela Creation Summary decompõe o tempo ponta a ponta em três subfases: clone_duration (tempo de cópia CSI), running_time (inicialização do container pelo kubelet) e ping_time (sondagem de rede do guest). Essa decomposição isola se uma regressão se origina na camada de storage, no runtime do container ou na sequência de inicialização do guest OS.
Comparando diferentes abordagens de benchmarking
| Ferramenta | Foco | Diferença do virtbench |
|---|---|---|
| kube-burner | Churn do API/control plane (etcd, scheduler) | Mede o data path: velocidades de clone, tempos de boot do OS, acessibilidade de rede |
| wrappers fio/iperf | Micro-benchmarks brutos de disco/rede | Testa a interação entre componentes (ex.: desempenho de rede durante live migration; velocidade de clone durante boot storm) |
| Testes E2E do KubeVirt | Passa/falha binário | Quantitativo: "Quanto tempo a operação levou?" Superficializa problemas de desempenho antes da produção |
Nota: Uma versão futura incluirá ferramentas de fio dentro da VM para benchmarking de I/O a partir do guest OS.
Executando seu primeiro teste com virtbench
O virtbench foi projetado para ser integrado em pipelines de CI de staging. Isso significa que você pode executá-lo antes e depois de mudanças na infraestrutura (upgrades de storage array, trocas de CNI, atualizações de versão do Kubernetes) para detectar regressões de desempenho antes que cheguem à produção.
Dados de benchmarking são frequentemente muito específicos do ambiente, tornando metodologias compartilhadas e abordagens de teste reproduzíveis particularmente valiosas para a comunidade KubeVirt.
Contribuindo e roadmap futuro
O projeto está disponível como open-source e recebe contribuições e feedback da comunidade: github.com/portworx/kubevirt-benchmark. Como as características de desempenho da infraestrutura variam amplamente entre plataformas de storage, CNIs e perfis de hardware, o feedback da comunidade e as contribuições de benchmark são especialmente valiosos. O projeto aceita casos de teste reproduzíveis, comparações entre plataformas e módulos de benchmark adicionais de operadores que executam KubeVirt em produção.
Perguntas Frequentes
-
Qual a diferença entre pod readiness e VM readiness no KubeVirt?
O Kubernetes considera o pod Ready assim que o container processa início (milissegundos). Já uma VMI do KubeVirt só está operacional quando o kernel da VM boota, os serviços user-space inicializam e o guest agent reporta heartbeat. Benchmarks que param no pod/Running subestimam o tempo real em minutos. -
O virtbench funciona em clusters OpenShift?
Sim. O artigo menciona explicitamente suporte a KubeVirt em OpenShift, além de ambientes com armazenamento compatível com CSI. O framework foi projetado para rodar em staging CI pipelines antes e depois de mudanças na infraestrutura. -
Como o virtbench mede o stun time da live migration?
O stun time é a janela em que a interface de rede da VMI fica indisponível durante a migração ao vivo. O virtbench sonda continuamente o endereço IP da VMI (via ssh-test-pod) e registra o tempo de interrupção, considerando que a migração no KubeVirt passa pelo overlay SDN (ex.: OVN-Kubernetes), diferente do canal dedicado do vMotion. -
Quais cenários de teste o virtbench oferece?
São seis cenários prontos: DataSource VM Provisioning (eficiência de clone), Single Node Boot Storm, Multi-Node Boot Storm (simula recuperação pós-falha), Live Migration, Chaos Benchmark (operações concorrentes) e Failure and Recovery (validação de HA via Fence Agents). -
O benchmarking com virtbench substitui ferramentas como kube-burner ou fio?
Não substitui, complementa. kube-burner foca em churn do API server e etcd; fio mede micro-benchmarks de disco/rede. O virtbench testa a interação entre componentes — por exemplo, velocidade de clone durante um boot storm ou performance de rede durante live migration — algo que as ferramentas tradicionais não capturam.
Artigo originalmente publicado por Bob Glithero, Senior Technical Product Marketing Manager, Portworx by Everpure em Cloud Native Computing Foundation.
