> ## Content Index > Fetch the complete content index at: https://www.azurebrasil.cloud/llms.txt > Use this file to discover other available public pages before exploring further. # A Nova Geração dos Virtual Nodes no Azure Container Instances: Serverless de Verdade no AKS - URL: https://www.azurebrasil.cloud/blog/a-nova-geracao-dos-virtual-nodes-no-azure-container-instances-serverless-de-verdade-no-aks/ - Published: 2026-06-10T12:22:51.000Z - Updated: 2026-06-10T12:22:51.000Z - Description: 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. - Author: Rafael dos Santos 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: ```yaml # 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](https://learn.microsoft.com/en-us/azure/container-instances/container-instances-virtual-nodes?ref=azurebrasil.cloud) — Documentação principal do recurso - [ACI Resource Availability & Quota](https://learn.microsoft.com/en-us/azure/container-instances/container-instances-resource-and-quota-limits?ref=azurebrasil.cloud) — Limites de quota e disponibilidade regional ### Repositório e Código - [Virtual Nodes on ACI — GitHub](https://github.com/microsoft/virtualnodesOnAzureContainerInstances?ref=azurebrasil.cloud) — Repositório oficial com Helm chart, documentação avançada e exemplos - [Documentação avançada (Node/Pod Customizations, Security, Troubleshooting)](https://github.com/microsoft/virtualnodesOnAzureContainerInstances/tree/main/Docs?ref=azurebrasil.cloud) — Guias detalhados de configuração ### Artigos e Vídeos - [Migrating to the next generation of Virtual Nodes on ACI — Tech Community](https://techcommunity.microsoft.com/blog/appsonazureblog/migrating-to-the-next-generation-of-virtual-nodes-on-azure-container-instances-a/4496565?ref=azurebrasil.cloud) — Guia de migração passo a passo do legado pra v2 - [AKS Keynote no KubeCon — YouTube](https://www.youtube.com/watch?v=yJOc3D52%5FIs&t=2330s&ref=azurebrasil.cloud) — Segmento demonstrando as melhorias do Virtual Nodes v2