Capire le differenze tra Azure CNI, CNI Overlay e Kubenet è fondamentale per le scelte di architettura di rete su AKS: le opzioni di networking determinano infatti il modo in cui i pod comunicano, come vengono assegnati gli indirizzi IP e quali funzionalità sono disponibili nel cluster. Tutte le soluzioni abilitano la connettività tra pod, ma si differenziano per implementazione, caratteristiche prestazionali e considerazioni di scalabilità. Questa panoramica tecnica mette a confronto Azure CNI (nelle modalità tradizionale e overlay) e Kubenet, con focus sulla gestione degli indirizzi IP, sulle prestazioni di rete e sulle capacità di integrazione, così da aiutarla a definire la sua strategia di networking su AKS.
Gestione degli indirizzi IP
Con Azure CNI tradizionale, ogni pod riceve un indirizzo IP direttamente dalla subnet della Azure Virtual Network. I pod diventano quindi cittadini di rete a tutti gli effetti all'interno della VNet e possono comunicare in modo diretto con le altre risorse dell'ambiente Azure. Gli IP dei pod sono instradabili e raggiungibili da qualsiasi risorsa con connettività verso la subnet.
Azure CNI offre oggi anche una modalità Overlay, in cui solo i nodi del cluster vengono distribuiti in una subnet. Ai pod vengono assegnati indirizzi IP da un CIDR privato, logicamente distinto dalla VNet che ospita i nodi. Il traffico tra pod e nodi all'interno del cluster passa per una rete Overlay, mentre il Network Address Translation (NAT) sfrutta l'indirizzo IP del nodo per raggiungere risorse esterne al cluster. Questa soluzione consente di risparmiare un numero significativo di indirizzi IP e di scalare il cluster molto di più.
Anche Kubenet implementa una rete overlay. I pod ricevono indirizzi IP da uno spazio di indirizzamento separato, che non fa parte della VNet. Quando i pod devono comunicare con risorse esterne al cluster, Kubenet usa il NAT per instradare il traffico tramite l'indirizzo IP del nodo. Si introduce così un hop di rete aggiuntivo, ma si risparmiano indirizzi IP della VNet, dato che solo i nodi richiedono IP dalla subnet.
Requisiti di spazio nella subnet
Con Azure CNI tradizionale, la pianificazione delle subnet richiede particolare attenzione, perché ogni potenziale pod ha bisogno di un indirizzo IP dedicato dalla subnet. Occorre quindi allocare una subnet sufficientemente ampia da ospitare tutti i nodi e il numero massimo di pod previsti. Se ad esempio ogni nodo può eseguire 30 pod e si prevede di scalare a 10 nodi, serviranno almeno 300 indirizzi IP per i pod, oltre agli IP per i nodi stessi. Spesso questo requisito impone di scegliere intervalli CIDR più ampi e può condizionare l'intero design della rete.
Azure CNI Overlay garantisce un utilizzo più efficiente degli indirizzi IP, assegnando uno spazio /24 a ciascun nodo a partire da un CIDR privato definito in fase di creazione del cluster. Il blocco /24 è fisso e può supportare fino a 250 pod per nodo. È possibile riutilizzare lo stesso CIDR dei pod su più cluster AKS indipendenti nella stessa VNet, ampliando notevolmente lo spazio IP disponibile per le applicazioni containerizzate.
Anche Kubenet utilizza gli indirizzi IP in modo efficiente, perché richiede IP della VNet solo per i nodi. I pod usano un intervallo CIDR interno per la rete overlay, in genere con default 10.244.0.0/16, che non intacca lo spazio di indirizzamento della VNet. È quindi una buona scelta in ambienti con disponibilità di IP limitata o vincoli stringenti sugli indirizzi. Il rovescio della medaglia è la necessità di una configurazione di routing aggiuntiva tramite User Defined Routes (UDR).
Prestazioni di rete
Azure CNI tradizionale offre prestazioni di rete superiori grazie al modello di integrazione diretta. Poiché i pod hanno connettività diretta alla VNet senza una rete overlay, l'overhead nello stack di rete è minimo. I pacchetti viaggiano direttamente tra i pod e le altre risorse della VNet senza ulteriori livelli di incapsulamento o traduzione, garantendo latenze più basse e throughput più elevato per i workloads ad alta intensità di rete.
Azure CNI Overlay mantiene prestazioni paragonabili a quelle delle VM all'interno di una VNet. Non serve configurare route personalizzate né ricorrere a metodi di incapsulamento per il tunneling del traffico tra pod, e questo garantisce una connettività tra pod allineata a quella delle VM in VNet.
Kubenet introduce un overhead di rete aggiuntivo, perché richiede NAT e routing attraverso l'interfaccia di rete del nodo. Ogni pacchetto deve essere elaborato dalla rete overlay e tradotto tra l'IP interno del pod e l'IP esterno del nodo. Per molte applicazioni l'impatto sulle prestazioni è trascurabile, ma può diventare rilevante in scenari con elevati requisiti di throughput o per workloads sensibili alla latenza.
Controllo dei Network Security Group (NSG)
Azure CNI funziona con gli NSG a livello di subnet e di interfaccia di rete, e le regole possono fare riferimento agli IP dei pod, dato che fanno parte della VNet. Gli NSG non possono essere associati direttamente a singoli pod, ma è possibile creare regole specifiche che agiscono su singoli pod o gruppi di pod tramite i loro IP nella VNet.
Con Azure CNI Overlay il traffico pod-to-pod non viene incapsulato e si applicano le regole NSG della subnet. Per il corretto funzionamento del cluster sono necessarie regole specifiche, incluso il traffico tra gli intervalli CIDR dei nodi e quelli dei pod. Per il controllo del traffico dei workloads sono consigliate le network policy.
Con Kubenet il controllo della sicurezza di rete è limitato al livello di nodo, perché i pod non hanno indirizzi IP diretti nella VNet. Le regole NSG possono essere applicate solo all'interfaccia di rete del nodo, quindi tutti i pod su un nodo condividono le stesse regole di sicurezza. Questo limite rende più complesso implementare policy di rete specifiche per pod e può richiedere soluzioni alternative, come le Kubernetes Network Policies, per un controllo del traffico più granulare all'interno del cluster.
Integrazione con la VNet
Azure CNI tradizionale offre un'integrazione completa con la VNet, permettendo ai pod di comunicare direttamente con qualsiasi risorsa connessa alla VNet nel suo ambiente Azure. Sono inclusi servizi come SQL Managed Instances, Azure Cache for Redis o risorse in VNet in peering. Poiché i pod ottengono gli indirizzi IP direttamente dalla subnet della VNet, possono stabilire connessioni dirette senza configurazioni di rete aggiuntive: una soluzione ideale negli scenari che richiedono un'integrazione fluida con altri servizi Azure.
Azure CNI Overlay realizza l'integrazione con la VNet tramite NAT: il traffico in uscita dei pod utilizza l'indirizzo IP del nodo. I pod non sono raggiungibili direttamente dall'esterno del cluster, ma è possibile pubblicare le loro applicazioni come servizi Kubernetes Load Balancer per renderle accessibili sulla VNet.
Kubenet offre capacità di integrazione con la VNet più limitate. I pod possono comunque comunicare con risorse esterne, ma questa comunicazione richiede UDR per instradare correttamente il traffico tra la rete overlay dei pod e la VNet. La complessità aggiuntiva del routing può influire sulla connettività con alcuni servizi Azure e richiedere configurazioni extra in scenari di VNet peering o di rete ibrida. I requisiti di routing tendono inoltre a complicarsi al crescere dell'architettura di rete.
Gestione delle route table e complessità di setup
La gestione delle route table cambia in modo significativo a seconda dell'opzione scelta. Azure CNI tradizionale semplifica la gestione delle route, perché i pod comunicano direttamente sulla VNet e non sono necessarie voci aggiuntive nelle route table per il loro traffico. La configurazione del routing rimane lineare anche con la crescita del cluster. Il prezzo da pagare è una maggiore complessità nel setup iniziale, che richiede un'attenta pianificazione degli indirizzi IP.
Azure CNI Overlay semplifica il networking dei pod perché, a differenza di Kubenet, non richiede UDR per la connettività di base. Sono necessarie regole NSG specifiche per il corretto funzionamento del cluster, ma la soluzione gestisce automaticamente il routing pod-to-pod e mantiene prestazioni paragonabili alla comunicazione tradizionale in VNet. Le UDR possono comunque servire in scenari specifici, come il forced tunneling o requisiti di routing personalizzato.
Kubenet utilizza UDR e IP forwarding per la connettività dei pod, creati e mantenuti automaticamente dal servizio AKS per impostazione predefinita. È possibile, in alternativa, fornire una propria route table per una gestione personalizzata, ma la configurazione standard non richiede manutenzione manuale delle route. La principale limitazione è che Azure supporta un massimo di 400 route in una UDR, il che di fatto limita il cluster a 400 nodi. Il setup iniziale è più semplice rispetto ad Azure CNI tradizionale, perché non serve un'estesa pianificazione degli indirizzi IP: basta tenere conto degli IP dei nodi nella subnet. L'architettura UDR aggiunge però un hop di rete extra, che introduce una lieve latenza nella comunicazione tra pod, e non consente di condividere subnet tra più cluster Kubenet.
Funzionalità aggiuntive
Ogni opzione di networking supporta funzionalità avanzate diverse. Azure CNI tradizionale offre il supporto più ampio, inclusi container Windows, Azure Network Policies e integrazione con Application Gateway. Azure CNI Overlay supporta i container Windows e diverse opzioni di network policy (Azure, Calico, Cilium), ma non può utilizzare Application Gateway come Ingress Controller. Entrambe le modalità CNI supportano il networking dual-stack, sebbene Overlay presenti alcune limitazioni. Kubenet ha un supporto più ridotto: funziona solo con container Linux e network policy Calico. Inoltre, Kubenet è limitato ai soli container Linux, supporta fino a 400 nodi con 250 pod per nodo ed è ristretto a Calico per le network policy. Non supporta i container Windows né le funzionalità di rete Azure più avanzate.
Quale scegliere?
La scelta tra le opzioni di networking dipende dai requisiti specifici dei workloads e dai vincoli infrastrutturali:
Azure CNI tradizionale è la scelta più adatta per workloads enterprise che richiedono integrazione di rete diretta, prestazioni elevate o un'integrazione avanzata con i servizi Azure. Lo scelga quando:
- Dispone di spazio di indirizzamento IP sufficiente
- La maggior parte della comunicazione dei pod è verso risorse esterne al cluster
- Risorse esterne al cluster devono raggiungere direttamente i pod
- Necessita di funzionalità avanzate di AKS come i virtual nodes
- È richiesta l'integrazione con Application Gateway
Azure CNI Overlay è ideale per deployment su larga scala con spazio di indirizzamento IP limitato. Lo scelga quando:
- Deve scalare fino a un gran numero di pod ma dispone di spazio IP limitato
- La maggior parte della comunicazione dei pod avviene all'interno del cluster
- Desidera una configurazione di rete più semplice
- Necessita del supporto per container Windows ma non di Application Gateway Ingress Controller
- Vuole riutilizzare gli intervalli CIDR dei pod tra più cluster
Kubenet funziona bene per workloads Linux di base e per ambienti con vincoli sugli indirizzi IP. Lo scelga quando:
- Ha workloads di base solo Linux
- Ha vincoli sugli indirizzi IP ma non gli serve la scalabilità di CNI Overlay
- Non gli servono funzionalità di rete avanzate
- Sta configurando ambienti di sviluppo o test
La scelta del plugin di networking per il suo cluster AKS ha implicazioni a lungo termine su scalabilità, prestazioni e complessità operativa! Conoscere caratteristiche e limiti distintivi di ciascuna opzione è essenziale per prendere una decisione informata, in linea con i requisiti infrastrutturali e i piani di crescita futuri. Tenga presente che il passaggio da un'opzione di networking all'altra richiede in genere la ricreazione del cluster: una decisione, quindi, da prendere nelle prime fasi di pianificazione di AKS.
Un'ultima nota: il 31 marzo 2028 il networking Kubenet per AKS verrà ritirato. Valuti la migrazione ad Azure CNI Overlay, una soluzione sostitutiva adeguata che supera molti dei limiti di Kubenet mantenendo un utilizzo efficiente degli indirizzi IP.
Contatti DoiT oggi stesso per scoprire come possiamo aiutarla a massimizzare efficienza, sostenibilità economica e sicurezza del suo ambiente cloud. Con DoiT ha accesso a competenze cloud esclusivamente senior per consulenza, formazione e supporto, e siamo al suo fianco ogni volta che le serve un parere esperto, un'opinione esterna, assistenza nell'adozione di nuove tecnologie o un aiuto per gestire emergenze in produzione.
Se desidera approfondire altri argomenti di sicurezza e architettura cloud, dia un'occhiata ai nostri post sul blog di cloud engineering.