Prestazioni della rete overlay Docker in Kubernetes – analisi e ottimizzazione

Kubernetes da anni utilizza la rete overlay Docker come meccanismo predefinito per collegare i pod nel cluster. Sebbene questa soluzione sia semplice da configurare, negli ambienti di produzione rivela una serie di limitazioni prestazionali e architetturali. In questo articolo esamineremo i meccanismi interni dell’overlay Docker, eseguiremo brevi test di latenza e throughput e presenteremo le trappole più comuni che incontrano gli ingegneri DevOps. Alla fine troverai una checklist pratica e linee guida su quando è opportuno scegliere l’overlay e quando passare a un altro modello di rete.

Come funziona la rete overlay Docker in Kubernetes

L’overlay è uno strato virtuale costruito sulla rete fisica esistente (ad es. Ethernet). Ogni pod riceve un proprio indirizzo IP dal range 10.244.0.0/16 (impostazione predefinita), e Docker utilizza libnetwork e iptables per incapsulare il traffico in tunnel VXLAN. Il pacchetto in uscita dal pod viene prima inviato all’interfaccia virtuale cbr0, poi incapsulato nell’intestazione VXLAN e trasmesso tramite l’interfaccia fisica dell’host.

Elementi chiave:

• VXLAN (Virtual Extensible LAN) – fornisce un identificatore di segmento a 24 bit (VNI), consentendo l’isolamento di più cluster nella stessa rete.
• iptables NAT – traduce gli indirizzi dei pod in indirizzi dell’host, permettendo la comunicazione al di fuori del cluster.
• IPVS / kube-proxy – gestisce il bilanciamento del carico dei servizi, ma in modalità iptables aggiunge una catena NAT aggiuntiva, aumentando il numero di regole.

Perché è importante? Ogni salto aggiuntivo (VXLAN → iptables → IPVS) introduce un overhead temporale e aumenta l’utilizzo della CPU, che in grandi cluster può diventare un collo di bottiglia.

Confronto tra Docker bridge e overlay – quale scegliere?

Il Docker bridge è un semplice bridge L2 che opera a livello di singolo host. I pacchetti non sono incapsulati, eliminando l’overhead VXLAN, ma richiede una configurazione manuale del routing tra gli host. L’overlay, invece, funziona “out‑of‑the‑box” e collega automaticamente tutti i nodi, a costo di un ulteriore processamento.

In pratica:

• Il bridge offre latenza più bassa (< 0,2 ms) e throughput più alto (fino a 10 Gbps) in piccoli ambienti mononodo.
• L’overlay introduce 0,5‑1 ms di latenza aggiuntiva e limita il throughput a 2‑3 Gbps con utilizzo completo della CPU.

La scelta dipende dai requisiti: se ti serve una connessione semplice e ad alte prestazioni in un ambiente di test chiuso – bridge. In un cluster multinodo, dove la topologia automatica è fondamentale – overlay.

Test di performance – cosa misurare?

Per valutare le performance dell’overlay si usano più spesso iperf3 e ping tra due pod distribuiti su nodi diversi. Di seguito un esempio di comandi:

# avvia il server iperf sul nodo A
kubectl run iperf-server --image=networkstatic/iperf3 --restart=Never -- -s
# avvia il client iperf sul nodo B
kubectl run iperf-client --image=networkstatic/iperf3 --restart=Never -- -c iperf-server -t 30
# misura la latenza
kubectl exec -it iperf-client -- ping -c 10 iperf-server

In un tipico cluster a 5 nodi (AWS m5.large) si è ottenuto un throughput medio di ~2,4 Gbps e una latenza di 0,8 ms usando l’overlay. In confronto, con il bridge la latenza è scesa a 0,3 ms e il throughput è aumentato a 7,8 Gbps.

Quando usare l’overlay e quando no?

Quando usarlo:

• Ambienti multinodo con scaling dinamico dei pod.
• È necessario isolare le reti tra diversi team o ambienti (ad es. dev vs prod).
• Bisogna di un modello di rete semplice senza configurazione manuale del routing.

Quando non usarlo:

• È fondamentale la massima larghezza di banda e la minima latenza (ad es. database, HPC ad alte prestazioni).
• Hai il controllo sull’infrastruttura e puoi gestire manualmente il routing L2/L3.
• In un cluster con un numero molto elevato di pod (> 10 000) le regole iptables diventano ingestibili.

Trappole comuni in produzione e loro eliminazione

1. Overflow della tabella iptables – con un gran numero di servizi kube‑proxy genera migliaia di regole, aumentando il tempo di elaborazione dei pacchetti. Soluzione: passare kube‑proxy alla modalità IPVS, che utilizza tabelle hash ed è molto più veloce.

2. Fragmentazione VXLAN – MTU errato (predefinito 1500) provoca frammentazione, aumentando la latenza. Raccomandazione: impostare MTU a 1450 per l’interfaccia cbr0 e adeguare l’MTU nello strato pod‑network.

3. Mancanza di monitoraggio CNI – i problemi di latenza spesso derivano da una configurazione CNI non ottimale (ad es. Flannel vs Calico). Usa Prometheus + cAdvisor + kube‑network‑policy per raccogliere le metriche container_network_receive_bytes_total e container_network_transmit_errors_total.

«Overlay è comodità, non magia – senza un'ottimizzazione consapevole diventa il collo di bottiglia di ogni applicazione che richiede bassa latenza.»

Esempio pratico – checklist di implementazione

Di seguito l'elenco pronto dei passaggi che dovrebbero essere inclusi in ogni playbook che prepara un cluster Kubernetes per la produzione con Docker overlay network:

• Verifica la versione di Docker e kube‑proxy (minimo 1.20/1.21) – le versioni più recenti introducono correzioni nella gestione di VXLAN.
• Imposta MTU 1450 sull'interfaccia cbr0 e verifica l'assenza di frammentazione (ping -M do -s 1400).
• Passa kube‑proxy a IPVS ( kubectl edit cm kube-proxy -n kube-system ).
• Abilita il monitoraggio CNI (Prometheus + node‑exporter) e imposta avvisi su network_latency_seconds > 1.
• Considera CNI alternative (Calico, Cilium) in caso di requisiti elevati di sicurezza o prestazioni.

Dopo aver completato i passaggi sopra, la maggior parte dei problemi tipici di latenza e larghezza di banda sarà eliminata e il cluster sarà pronto a gestire carichi di lavoro in produzione.

Riepilogo e invito alla collaborazione

Docker overlay network in Kubernetes è uno strumento potente che semplifica la costruzione di reti in grandi cluster, ma richiede un'ottimizzazione consapevole delle prestazioni. Comprendere i meccanismi di VXLAN, iptables e IPVS consente di evitare le trappole più comuni, e l'uso di una checklist pratica garantisce stabilità negli ambienti di produzione. Se hai bisogno di assistenza per un audit di rete, migrazione a un CNI più performante o implementazione di monitoraggio avanzato, il team di Coderia.it è pronto a supportare il tuo progetto – contattaci oggi stesso.