O Azure Container Instances (ACI) é uma plataforma de containers serverless, desenhada para rodar workloads on-demand sem a necessidade de gerenciar o ciclo de vida de nós de infraestrutura. A integração com o Azure Kubernetes Service (AKS) via Virtual Nodes permite que clusters Kubernetes utilizem essa capacidade serverless para acomodar pods em vez de escalar node pools tradicionais baseados em VMs.
Para o engenheiro de plataforma, o Virtual Node é visto como um nó padrão do Kubernetes, mas, internamente, o agendamento é disparado diretamente na infraestrutura serverless do ACI. Essa arquitetura é extremamente valiosa para cenários de burst, workloads imprevisíveis ou tarefas de vida curta, onde a agilidade no scale-out é mais crítica do que o provisionamento de capacidade fixa. A nova implementação – Virtual Nodes v2 – moderniza esse modelo, abandonando o padrão de managed add-on em prol de uma abordagem via Helm. Essa mudança remove travas da implementação legado e aproxima a experiência do desenvolvedor ao padrão nativo do ecossistema Kubernetes.
O que muda na nova geração (v2)?
A versão v2 do Virtual Nodes no ACI não é apenas uma atualização, mas uma reconstrução. Entre as melhorias operacionais, destacam-se o suporte a Init Containers, Host Aliases, Persistent Volumes (e Claims), além de Confidential Containers e ACI standby pools. O ponto de atenção para arquitetos é que a gestão agora é centralizada via Helm, o que transfere o controle do ciclo de vida diretamente para os pipelines de CI/CD do time de engenharia, em vez de depender inteiramente das atualizações de provisionamento gerenciado do Azure.
Contudo, essa transição exige planejamento. É importante notar que não há suporte para uma migração de "clique único". O processo exige a desinstalação dos recursos legados e o setup do novo Helm chart. Além disso, as limitações permanecem como pontos de atenção críticos: o uso obrigatório de Azure CNI, a falta de suporte para DaemonSets e a incompatibilidade com clusters que utilizam API server authorized IP ranges.
Considerações Práticas para o seu Roadmap de Migração
A migração, de forma resumida, envolve:
- Redimensionamento: Ajustar os workloads existentes para evitar interrupções.
- Clean-up: Desabilitar o add-on legado (
az aks disable-addons ...). - Infraestrutura: Como a nomenclatura de subnets no Azure muitas vezes exige recriação (por não permitirem rename), planeje a rede para a nova delegação.
- Configuração de RBAC: Garantir que a Managed Identity (agora vinda do seu pool de agentes/kubelet) tenha as permissões necessárias de
Contributorno grupo de recursos eNetwork Contributorna nova subnet delegada.
Para times de plataforma, a principal vantagem é a flexibilidade de configurar o Virtual Node através de Helm values, permitindo testes de novas funcionalidades e customizações de forma muito mais granular. Para ambientes de alta complexidade em produção, nossa recomendação é sempre isolar o ambiente de staging antes de qualquer alteração na rede, dada a natureza da delegação de subnets ao ACI.
Artigo originalmente publicado em Azure Updates - Latest from Azure Charts.
