A Microsoft tornou disponível em caráter geral (GA) a funcionalidade de expansão de pod CIDR no Azure CNI Overlay para clusters AKS. Se você gerencia clusters que crescem além do planejado, essa é uma daquelas mudanças que merecem atenção estratégica — não apenas técnica.
TL;DR: A expansão de pod CIDR no Azure CNI Overlay agora é GA, permitindo aumentar o espaço de endereçamento de pods sem recriar o cluster. Antes, o CIDR era fixo na criação e cada node consumia um bloco /24, limitando o scaling a 256 nodes (com /16 padrão). Agora é possível expandir sem downtime ou node reimaging. O planejamento cuidadoso segue sendo essencial para evitar overlapping entre clusters e considerar system node pools.
Como funciona o Azure CNI Overlay e por que o CIDR importa?
No Azure CNI Overlay, o pod CIDR do cluster é logicamente particionado em blocos menores por node — cada node recebe um slice fixo /24 atribuído pelo Azure. Isso desacopla completamente a rede de pods do espaço de endereço da VNet, já que os pods recebem IPs de um CIDR privado separado.
Por padrão, o Azure CNI Overlay usa o pod CIDR 10.244.0.0/16, que oferece 65.536 endereços. Como cada node consome 256 endereços (bloco /24), o limite máximo de nodes é 65.536 ÷ 256 = 256 nodes. A escolha do pod CIDR no momento da criação do cluster define um teto para quantos nodes o cluster pode acomodar.
| Pod CIDR | Bloco por Node | Máx. de Nodes Suportados |
|---|---|---|
| /16 | /24 | 256 |
| /15 | /24 | 512 |
| /14 | /24 | 1.024 |
O que a expansão de Pod CIDR permite na prática?
Mesmo com planejamento cuidadoso, clusters de longa duração crescem de formas difíceis de antecipar. Para organizações que usam Azure CNI Overlay, ficar preso ao CIDR escolhido na criação significava uma migração complexa — ou a recriação do cluster inteiro.
A expansão de pod CIDr permite aumentar o CIDR existente sem downtime ou node reimaging. Em vez de ficar refém do range inicial, operadores podem expandir o espaço de endereçamento disponível com mínimo esforço operacional.
Quais cuidados tomar ao escolher o Pod CIDR?
Além dos limites de scaling, existem outras considerações importantes:
- Overlapping de pod CIDRs entre clusters — embora os IPs dos pods não sejam diretamente roteáveis entre clusters, CIDRs sobrepostos podem causar problemas com ferramentas de observability ou com soluções de cross-cluster networking que atuam sobre o overlay. Um planejamento cuidadoso agora evita ter que recriar o cluster no futuro.
- Consumo por system node pools — cada system node (que roda componentes do plano de controle) também consome um bloco /24. O planejamento de endereçamento deve considerar esses nodes além das workloads existentes.
Perguntas Frequentes
-
Posso expandir o pod CIDR de um cluster AKS existente sem perder dados?
Sim. A funcionalidade de pod CIDR expansion permite expandir o CIDR sem downtime ou node reimaging. Basta seguir os passos da documentação oficial da Microsoft. -
Qual o limite máximo de nodes que um cluster AKS com Azure CNI Overlay pode ter?
Depende do pod CIDR escolhido. Com /16 (padrão), o limite é 256 nodes. Com /14, sobe para 1.024 nodes. Cada node consome um bloco /24. -
O que acontece se eu tiver pod CIDRs sobrepostos entre clusters?
Embora os IPs dos pods não sejam roteáveis entre clusters diretamente, a sobreposição pode causar problemas em ferramentas de observability e em soluções de cross-cluster networking sobre o overlay. Planeje CIDRs distintos desde o início. -
System node pools consomem blocos /24 do pod CIDR?
Sim. Cada system node (que roda componentes do plano de controle) também consome um bloco /24. Isso deve ser considerado no planejamento de endereçamento.
Artigo originalmente publicado por Sam_Foo em Azure Updates - Latest from Azure Charts.
