A Nova Geração dos Virtual Nodes no Azure Container Instances: Serverless de Verdade no AKS
A Microsoft lançou uma nova geração dos Virtual Nodes no ACI com dezenas de melhorias e correções que transformam essa funcionalidade em serverless de verdade no AKS. Neste artigo, vou explicar o que mudou, o que agora é possível e quando faz sentido usar essa abordagem.
Olá pessoALL,
Você já precisou rodar contêineres sob demanda na nuvem, mas não queria provisionar e gerenciar um cluster inteiro de VMs só pra isso? Se a resposta é sim, você provavelmente já esbarrou no Azure Container Instances (ACI) — e talvez até nos Virtual Nodes do AKS. E se você tentou usar Virtual Nodes no passado e desistiu por causa das limitações... eu entendo. Eu também achava que a ideia era boa demais pra funcionar de verdade.
Mas as coisas mudaram. E mudaram muito.
A Microsoft lançou uma nova geração dos Virtual Nodes no ACI — reconstruída do zero, com dezenas de melhorias e correções que transformam essa funcionalidade de "interessante mas limitada" pra "serverless de verdade no AKS". Neste artigo, vou explicar o que mudou, o que agora é possível, e quando faz sentido usar essa abordagem.
O Que São Virtual Nodes e Azure Container Instances?
Antes de mergulhar nas novidades, vale nivelar o entendimento.
Azure Container Instances (ACI) é uma plataforma serverless totalmente gerenciada que permite rodar contêineres sob demanda, sem provisionar infraestrutura. Você define a imagem, os recursos (CPU, memória), e o Azure cuida do resto. Sem VMs pra gerenciar, sem patches de SO, sem cluster orchestrator obrigatório.
Agora, Virtual Nodes levam essa ideia um passo adiante. Eles permitem que pods do Kubernetes — gerenciados por um cluster AKS — sejam executados de forma serverless no ACI, em vez de rodar nos node pools tradicionais baseados em VMs.
Na prática, o que isso significa? Do ponto de vista do desenvolvedor, um Virtual Node aparece como um nó normal do Kubernetes. Você faz kubectl get nodes e ele está lá. Mas por baixo dos panos, os pods estão rodando na infraestrutura serverless do ACI. Isso habilita scale-out rápido — sem esperar VMs serem provisionadas — ideal pra workloads com picos imprevisíveis, jobs de curta duração, ou processamento em batch.
Ou seja, você mantém os benefícios do ecossistema Kubernetes (deployments, services, configurações) com a agilidade do serverless. O melhor dos dois mundos, certo? Pelo menos, essa era a promessa.
O Legado: O Que Não Funcionava Bem
A versão original dos Virtual Nodes era implementada como um managed add-on do AKS. A ideia era simples: habilitar com um comando e pronto. Na teoria, bonito. Na prática? Uma lista de limitações que frustrava qualquer cenário minimamente complexo.
Veja o que não funcionava na versão legada:
- Sem VNet peering — isolamento de rede comprometido
- Sem init containers — padrão básico do Kubernetes, indisponível
- Sem Persistent Volumes e Persistent Volume Claims — sem storage persistente
- Sem host aliases — configuração de DNS limitada
- Sem container hooks — sem lifecycle management adequado
- Sem argumentos para exec — debugging limitado
Pra quem precisava de qualquer um desses recursos — e convenhamos, a maioria dos cenários reais precisa — os Virtual Nodes viravam mais uma curiosidade do que uma solução viável.
Muita gente testou, esbarrou nessas limitações, e voltou pros node pools tradicionais. Eu não julgo. As restrições eram reais e impactantes. Perdi um bom tempo avaliando a viabilidade dos Virtual Nodes pra cenários de burst em projetos anteriores, e a conclusão era sempre a mesma: "legal, mas não dá pra usar em produção assim."
Lição aprendida: uma boa ideia com limitações técnicas demais vira uma frustração.
A Nova Geração: Virtual Nodes v2
Agora que entendemos a dor, a pergunta natural é: o que a Microsoft fez pra resolver isso? A resposta é ambiciosa.
A nova geração dos Virtual Nodes no ACI foi reconstruída do zero. Não é um patch, não é um upgrade incremental. É uma reimplementação completa, que inclusive foi apresentada no keynote do Azure Kubernetes Service no KubeCon.
A primeira mudança estrutural importante: o deploy agora é feito via Helm chart, não mais como managed add-on do AKS. Isso pode parecer mais complexo à primeira vista.
Mas é justamente essa mudança que destranca a flexibilidade. Gerenciar via Helm significa configurar exatamente o que você precisa — réplicas, subnets, zonas de disponibilidade, políticas de segurança — tudo via values.yaml. Você ganha controle granular sem depender de decisões que o managed add-on tomava por você.
Vamos ver o que mudou, camada por camada.
Networking: Finalmente Integrado
A versão legada praticamente ignorava cenários de rede avançados. A v2 corrige isso:
- VNet peering e tráfego outbound com Network Security Groups (NSGs) — seus pods em ACI agora participam da rede como cidadãos de primeira classe
- Suporte a múltiplas subnets — cada pod pode ser direcionado pra uma subnet específica via annotation, ou o nó distribui automaticamente entre subnets configuradas
- NAT Gateway obrigatório pra tráfego outbound — arquitetura mais previsível e segura
Storage: Persistência Real
- Persistent Volumes e Persistent Volume Claims — finalmente disponíveis
- Azure File com autenticação via Managed Identity — sem precisar gerenciar client secrets pra montar file shares
Segurança: Enterprise-Grade
Aqui a evolução é impressionante:
- Confidential Containers — contêineres rodando em hardware confidencial com políticas CCE, ideal pra workloads sensíveis. Disponível em mais de 15 regiões
- Criptografia via Customer Managed Keys (CMK) — dados de deployment protegidos com suas próprias chaves no Key Vault
- Workload Identity — integração nativa com Azure Entra, usando tokens OIDC federados. Funciona com as Azure Identity client libraries que você já conhece
- Custom RBAC roles — permissões mínimas necessárias, sem precisar de Contributor no nível de subscription
- Compatibilidade com NRG Lockdown do AKS — pra quem precisa de isolamento rígido do resource group gerenciado
Operações: Produção de Verdade
- Standby Pools — UVMs pré-criadas e aquecidas, prontas pra receber pods com latência mínima de boot. Você configura quantas UVMs manter "quentes" e até faz image caching pra acelerar ainda mais o pull de imagens
- Métricas via Prometheus e Grafana — um novo endpoint de métricas que funciona com managed Prometheus no AKS, dando visibilidade real sobre os pods nos Virtual Nodes
- Pod cycling via CronJob — padrão documentado pra reciclar pods em intervalos configuráveis, garantindo que rodem sempre em hosts atualizados
- Custom ARM tags — tags nos container groups do ACI, facilitando governança e cost management
- Availability Zones — deploy em zonas específicas, configurável tanto no nível do nó quanto do pod
Escala: De 200 a Milhares
E quanto à escala? Cada Virtual Node suporta até 200 pods. Precisa de mais? Escale horizontalmente — cada réplica adicional do Helm chart adiciona mais 200 pods de capacidade. Pra cenários de 2.000+ pods e taxas de deployment de 1.000 pods por minuto, existe um guia dedicado de best practices que inclui desabilitar kube-proxy (que em alta escala sobrecarrega o API server) e usar Workload Identity ao invés de credentials manuais.
O Que Mudou: Visão Comparativa
Pra consolidar, aqui está o que a nova geração corrigiu versus o legado:
| Recurso | Virtual Nodes (Legado) | Virtual Nodes v2 |
|---|---|---|
| VNet peering e NSGs | ❌ | ✅ |
| Init containers | ❌ | ✅ |
| Persistent Volumes / PVCs | ❌ | ✅ |
| Host aliases | ❌ | ✅ |
| Container hooks | ❌ | ✅ |
| Exec com argumentos | ❌ | ✅ |
| Confidential Containers | ❌ | ✅ |
| Standby Pools | ❌ | ✅ |
| Métricas Prometheus | ❌ | ✅ |
| Deploy via Helm | ❌ (managed add-on) | ✅ |
| DaemonSets | ❌ | ❌ |
| Windows containers | ❌ | 🔜 (planejado) |
| IPv6 | ❌ | 🔜 (planejado) |
| Network policies do K8s | ❌ | 🔜 (planejado) |
Quando Usar (e Quando NÃO Usar)
Vamos ser honestos: Virtual Nodes v2 não serve pra qualquer cenário. E tudo bem. Saber quando não usar é tão importante quanto saber quando usar.
Cenários ideais
- Burst workloads — picos de demanda que precisam de scale-out rápido sem esperar VMs
- Batch processing — jobs de curta duração que processam e encerram
- Event-driven — funções disparadas por eventos que precisam de contêineres efêmeros
- CI/CD agents — runners de pipeline que escalam conforme a demanda
- Dev/test — ambientes temporários que não justificam node pools dedicados
Cenários onde NÃO faz sentido
- DaemonSets — limitação hard, não suportado e sem previsão de mudar
- Workloads stateful de longa duração — para serviços que rodam 24/7 com estado persistente complexo, node pools tradicionais ainda são mais adequados
- Windows containers — planejado pro futuro, mas ainda não disponível
- Cenários que exigem IPv6 — também planejado, mas ainda não suportado
Limitações técnicas que permanecem
- Requer Azure CNI networking no AKS — Kubenet e overlay não são suportados
- Incompatível com API server authorized IP ranges — por causa da delegação de subnet pro ACI
- Cada Virtual Node consome 3 vCPUs e 12 GiB de memória em uma VM do node pool do AKS
Mas pra workloads on-demand, burst e processamento efêmero — que é exatamente o que ACI foi desenhado pra fazer — é difícil encontrar algo melhor no ecossistema Azure. A combinação de agilidade serverless com o ecossistema Kubernetes é poderosa.
A configuração dos pods também é simples. O nodeSelector e os tolerations mudaram do legado pra v2:
# Virtual Nodes v2
nodeSelector:
virtualization: virtualnode2
tolerations:
- effect: NoSchedule
key: virtual-kubelet.io/provider
operator: Exists
O Que Esperar no Futuro
Se você chegou até aqui, deve estar se perguntando: isso tudo está maduro o suficiente pra confiar? O ritmo de desenvolvimento responde essa pergunta. O repositório no GitHub tem releases mensais com correções de segurança, novos recursos e melhorias de performance. Nos últimos meses, vimos adições como:
- Suporte a pull de imagens de ACRs privados via Trusted Access e Managed Identity
- Kube-Proxy configurável — desabilitável no nível do nó ou do pod, conforme a necessidade
- Pod Disruption Budgets e Priority Classes — controle fino sobre scheduling e resiliência
- Azure File com autenticação MI — eliminando a necessidade de client secrets
A matriz de compatibilidade com versões do AKS já cobre 1.29 até 1.33, com atualizações frequentes pra acompanhar os releases do Kubernetes.
No roadmap oficial, os próximos itens planejados são:
- Kubernetes network policies
- Suporte a IPv6
- Windows containers
- Port forwarding
O fato de o Virtual Nodes v2 ter sido destaque no keynote do AKS no KubeCon mostra o nível de investimento que a Microsoft está colocando nessa direção. Não é um side project — é parte central da estratégia de containers no Azure.
Conclusão
Voltando à pergunta inicial: você precisa rodar contêineres sob demanda na nuvem sem gerenciar VMs? A nova geração dos Virtual Nodes no Azure Container Instances é a resposta mais completa que o Azure já ofereceu pra esse cenário.
Diferente do legado — que era uma boa ideia com muitas restrições — a v2 entrega serverless de verdade dentro do ecossistema Kubernetes. VNet peering, persistent volumes, confidential containers, standby pools, métricas via Prometheus, segurança enterprise-grade. Tudo isso gerenciado via Helm, com a flexibilidade que cenários reais exigem.
Não é perfeito. DaemonSets continuam sem suporte. Windows containers ainda estão no roadmap. Requer Azure CNI. Mas pra workloads de burst, batch, event-driven, CI/CD — o tipo de coisa que ACI faz de melhor — a nova geração dos Virtual Nodes é uma evolução significativa.
Se você avaliou Virtual Nodes no passado e desistiu, vale revisitar. Se nunca testou, agora é um bom momento. O repositório no GitHub tem toda a documentação, exemplos e guia de troubleshooting que você precisa pra começar.
Deixe nos comentários se você já testou ou pretende testar. Quero saber como está sendo a experiência de vocês!
[]s e até a próxima
Links Úteis
Documentação Oficial
- Virtual Nodes on Azure Container Instances — Microsoft Learn — Documentação principal do recurso
- ACI Resource Availability & Quota — Limites de quota e disponibilidade regional
Repositório e Código
- Virtual Nodes on ACI — GitHub — Repositório oficial com Helm chart, documentação avançada e exemplos
- Documentação avançada (Node/Pod Customizations, Security, Troubleshooting) — Guias detalhados de configuração
Artigos e Vídeos
- Migrating to the next generation of Virtual Nodes on ACI — Tech Community — Guia de migração passo a passo do legado pra v2
- AKS Keynote no KubeCon — YouTube — Segmento demonstrando as melhorias do Virtual Nodes v2
