Kubernetes Networking: DNS, Services, Ingress — Guida Pratica Sysadmin (2026)

Pod che non si parlano. Service con zero endpoint. DNS che non risolve. Kubernetes networking può sembrare magia nera. Non lo è affatto: c’è una logica precisa e robusta al suo interno. Capire questa logica risolve il 90% degli incidenti di rete su K8s, trasformando ore di debugging frustrante in minuti di analisi mirata. Ogni Sysadmin che si trova a gestire un cluster Kubernetes, grande o piccolo, sa quanto sia fondamentale padroneggiare i concetti di rete. Un’incomprensione qui può portare a downtime significativi. In questa guida pratica, esploreremo i componenti chiave del networking Kubernetes, dai meccanismi di base come l’overlay network e CoreDNS, fino a strumenti avanzati come Ingress e NetworkPolicy, fornendo comandi e best practice per debuggare efficacemente.

Prerequisiti / Ambiente di test

Per seguire questa guida, è consigliabile avere accesso a un cluster Kubernetes funzionante (minikube, Kind, o un cluster cloud come EKS/AKS/GKE). Le conoscenze di base di Linux, Docker e kubectl sono date per acquisite. Tutti i comandi sono stati testati su un cluster Kubernetes versione 1.28 con Calico come CNI.

Come funziona il networking Kubernetes (overlay, CNI, kube-proxy)

Il networking in Kubernetes è un sistema complesso ma ben orchestrato, progettato per fornire a ogni Pod un proprio indirizzo IP e garantire che tutti i Pod possano comunicare tra loro, indipendentemente dal nodo su cui risiedono. Questo è possibile grazie a tre componenti principali:

• Overlay Network: Nonostante i Pod siano distribuiti su nodi fisici o virtuali diversi, Kubernetes crea una rete logica “overlay” che li interconnette. Questa rete opera sopra la rete fisica sottostante, incapsulando il traffico tra i Pod. Soluzioni CNI (Container Network Interface) come Calico, Flannel o Cilium implementano questa rete, gestendo l’assegnazione degli IP ai Pod e il routing del traffico.
• CNI (Container Network Interface): Il CNI è un framework che permette a Kubernetes di interagire con diversi plugin di rete. Ogni plugin CNI ha il compito di configurare l’interfaccia di rete all’interno del Pod e di garantire la connettività inter-Pod e inter-nodo. Ad esempio, Calico implementa un firewall distribuito e policy di rete avanzate, mentre Flannel è più semplice e focalizzato sulla connettività di base.
• kube-proxy: Questo componente è un proxy di rete che gira su ogni nodo del cluster. La sua funzione principale è quella di implementare il concetto di Service di Kubernetes. kube-proxy osserva il control plane per i cambiamenti nei Service e negli Endpoints e aggiorna le regole di iptables (o ipvs) sul nodo per instradare il traffico destinato a un Service verso i Pod che lo supportano. È il vero “router” dei Service all’interno del cluster.

ClusterIP, NodePort, LoadBalancer: quando usare cosa

I Service in Kubernetes sono un’astrazione fondamentale che definisce un set logico di Pod e una policy per accedervi. Ci sono diversi tipi di Service, ognuno con uno scopo specifico:

• ClusterIP: Questo è il tipo di Service predefinito. Assegna un indirizzo IP interno al cluster, accessibile solo dai Pod all’interno dello stesso cluster. È ideale per la comunicazione interna tra microservizi. L’IP del ClusterIP rimane stabile per tutta la vita del Service.
• NodePort: Espone il Service su una porta specifica (la NodePort) su ogni nodo del cluster. Questo significa che puoi accedere al Service dall’esterno del cluster usando l’IP di qualsiasi nodo e la porta NodePort. È utile per esporre servizi a scopo di test o in ambienti dove non è disponibile un LoadBalancer esterno. È spesso usato in combinazione con un LoadBalancer esterno che inoltra il traffico alla NodePort.
• LoadBalancer: Questo tipo di Service, tipicamente disponibile nei cluster ospitati su cloud provider (AWS, GCP, Azure), crea un LoadBalancer esterno che instrada il traffico verso il Service. L’IP del LoadBalancer è esterno e accessibile da Internet. È la scelta standard per esporre applicazioni web o API al pubblico.

CoreDNS: come Kubernetes risolve i nomi interni

CoreDNS è il server DNS predefinito per Kubernetes. Ogni Pod nel cluster è configurato per utilizzare CoreDNS per la risoluzione dei nomi. CoreDNS è in grado di risolvere i nomi dei Service e dei Pod all’interno del cluster, seguendo un formato specifico:

• Service: my-service.my-namespace.svc.cluster.local (o semplicemente my-service se nello stesso namespace).
• Pod: my-pod-ip.my-namespace.pod.cluster.local (anche se meno comune per la comunicazione diretta).

Quando un Pod cerca di comunicare con un altro Service, invia una richiesta DNS a CoreDNS, che risolve il nome in un indirizzo IP del Service (ClusterIP). Senza una corretta configurazione di CoreDNS, la comunicazione interna tra i tuoi microservizi sarebbe impossibile. Se un Pod non riesce a risolvere un nome, la prima cosa da controllare è il funzionamento di CoreDNS.

Per debuggare la risoluzione DNS da dentro un Pod, puoi usare un Pod di debug temporaneo:

kubectl run -it --rm debug --image=busybox -- nslookup kubernetes.default

Ingress: esporre applicazioni con un solo IP

L’Ingress è un oggetto API che gestisce l’accesso esterno ai servizi all’interno di un cluster, tipicamente traffico HTTP/S. A differenza di un Service di tipo LoadBalancer che espone un singolo Service, un Ingress Controller (come NGINX Ingress Controller o Traefik) può esporre più Service sotto un singolo IP esterno, utilizzando regole basate su hostname (es. app1.example.com e app2.example.com) o path (es. example.com/api e example.com/admin).

L’Ingress Controller agisce come un reverse proxy, inoltrando le richieste in ingresso ai Service Kubernetes appropriati. Questo centralizza la gestione dell’accesso esterno, permettendo di configurare facilmente routing, SSL termination e bilanciamento del carico per tutte le tue applicazioni web.

NetworkPolicy: isolamento tra namespace e pod

Le NetworkPolicy sono un meccanismo di sicurezza a livello di Pod che ti permette di controllare il flusso di traffico di rete. Funzionano come un firewall distribuito, definendo quali Pod possono comunicare tra loro e con endpoint esterni. Per impostazione predefinita, tutti i Pod possono comunicare con tutti gli altri Pod e con l’esterno. Le NetworkPolicy ti consentono di implementare il principio del minimo privilegio, isolando le applicazioni critiche.

Ad esempio, puoi creare una NetworkPolicy per permettere al traffico solo da un certo namespace o da Pod con una specifica label. Se non viene definita alcuna NetworkPolicy, la comunicazione è libera. Una pratica comune è implementare una “default-deny” policy per un namespace, bloccando tutto il traffico in ingresso e in uscita, e poi aggiungere policy specifiche per consentire solo il traffico necessario. Questo aumenta significativamente la postura di sicurezza del cluster, riducendo la superficie di attacco.

Ecco un esempio di NetworkPolicy che blocca tutto il traffico in ingresso e in uscita per tutti i Pod in un namespace:

kubectl apply -f - <<EOF
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
spec:
  podSelector: {}
  policyTypes: [Ingress, Egress]
EOF

Debug networking: kubectl exec + nslookup + tcpdump nel pod

Debuggare i problemi di networking in Kubernetes richiede un approccio sistematico. Ecco alcuni strumenti e tecniche essenziali:

1. Verificare lo stato dei Service e degli Endpoints: Un Service senza Endpoints significa che non ci sono Pod in esecuzione che lo supportano o che i Pod non sono Ready. Controlla i log dei Pod e gli eventi del Service.

    kubectl get service <service-name>
    kubectl get endpoints <service-name>

1. Debug DNS da dentro un Pod: Se un’applicazione non riesce a comunicare con un altro Service, spesso il problema è la risoluzione DNS. Usa un Pod di debug temporaneo per testare nslookup o dig.

    kubectl run -it --rm debug --image=busybox -- nslookup kubernetes.default

1. Controllare le NetworkPolicy: Se la comunicazione è bloccata, assicurati che non ci siano NetworkPolicy che impediscono il traffico desiderato. kubectl describe networkpolicy può fornire dettagli sulle policy applicate.

1. Tracciare il traffico nel Pod: Per un’analisi più approfondita, puoi usare tcpdump all’interno di un Pod per vedere quali pacchetti stanno effettivamente arrivando o uscendo. Questo richiede che l’immagine del Pod includa tcpdump o che tu possa installarlo temporaneamente.

    kubectl exec <pod> -- tcpdump -i eth0 port 80

1. Controllare i log di kube-proxy e CNI: I log di kube-proxy e del tuo plugin CNI (es. Calico, Flannel) possono rivelare problemi di configurazione o errori di routing a livello di nodo. Questi log si trovano solitamente sui nodi del cluster.

Errori più comuni: DNS che non risolve, service senza endpoint

Molti problemi di networking in Kubernetes si riducono a pochi scenari comuni:

• DNS che non risolve: Spesso causato da un Pod di CoreDNS non Ready, un errore di configurazione nel resolv.conf del Pod (anche se raramente accade con la configurazione predefinita di K8s), o un problema di NetworkPolicy che blocca il traffico verso CoreDNS. Un Pod che non riesce a risolvere nomi esterni potrebbe avere problemi con i server DNS a monte di CoreDNS.
• Service senza endpoint: Questo indica che non ci sono Pod che corrispondono al selector del Service e che sono in stato Ready. Controlla lo stato dei Pod (kubectl get pod -o wide), i loro log e gli eventi per capire perché non sono Ready. Un errore comune è un selector errato o un readinessProbe fallito.
• Connettività inter-Pod fallita: Se i Pod non riescono a comunicare tra loro, potrebbe esserci un problema con il plugin CNI (es. errori nei log, nodi non registrati correttamente) o, più comunemente, una NetworkPolicy che blocca il traffico. Ricorda che una sola NetworkPolicy default-deny può bloccare tutto.
• Problemi di Ingress: Se l’applicazione non è raggiungibile tramite Ingress, verifica prima che l’Ingress Controller sia in esecuzione e Ready. Poi, controlla le regole dell’Ingress (kubectl describe ingress ) e i log dell’Ingress Controller per errori di routing o configurazione SSL.

FAQ — Domande Frequenti

Cos’è un CNI in Kubernetes?

Un CNI (Container Network Interface) è uno standard per i plugin di rete che permette a Kubernetes di configurare le interfacce di rete dei Pod e di gestire la connettività di rete. Implementazioni popolari includono Calico, Flannel e Cilium, ognuno con diverse funzionalità e prestazioni. Il CNI è fondamentale per consentire ai Pod di comunicare tra loro e con il mondo esterno, fornendo l’overlay network necessario.

Qual è la differenza tra ClusterIP e NodePort?

ClusterIP espone un Service solo all’interno del cluster, assegnandogli un IP interno stabile. NodePort, invece, espone il Service su una porta specifica di ogni nodo del cluster, rendendolo accessibile dall’esterno tramite l’IP di qualsiasi nodo e la porta assegnata. ClusterIP è per comunicazione interna, NodePort per accesso esterno diretto (spesso tramite un LoadBalancer front-end).

Quando dovrei usare un Ingress invece di un LoadBalancer?

Un LoadBalancer espone un singolo Service con un IP esterno dedicato. Un Ingress è un controller HTTP/S che può esporre molti Service sotto un singolo IP esterno, gestendo il routing basato su hostname o path. Usa LoadBalancer per un singolo servizio critico o non-HTTP/S, e Ingress per esporre più applicazioni web o API con un unico punto di ingresso e configurazione centralizzata.

Come posso isolare il traffico tra i miei microservizi?

L’isolamento del traffico tra microservizi si ottiene principalmente tramite le NetworkPolicy. Queste policy definiscono quali Pod possono comunicare tra loro. Puoi creare NetworkPolicy per consentire solo il traffico necessario tra specifici Pod o namespace, bloccando tutto il resto. Questo aiuta a contenere potenziali attacchi e a migliorare la sicurezza complessiva del cluster.

Conclusioni con takeaway operativi

Il networking Kubernetes, sebbene complesso, è la spina dorsale di qualsiasi applicazione distribuita. Capire il ruolo dell’overlay network, di kube-proxy, CoreDNS, Service, Ingress e NetworkPolicy è cruciale per ogni Sysadmin. Investire tempo nel padroneggiare questi concetti e gli strumenti di debugging ti permetterà di:

1. Ridurre i tempi di troubleshooting: Diagnosticate i problemi di connettività in minuti, non in ore.
2. Migliorare la sicurezza: Implementate NetworkPolicy per isolare i carichi di lavoro e ridurre la superficie di attacco. Ho visto ambienti dove una NetworkPolicy ben configurata ha fermato un attacco laterale in corso.
3. Ottimizzare le performance: Scegliete il tipo di Service corretto e configurate l’Ingress Controller in modo efficiente per garantire un flusso di traffico ottimale.

La prossima volta che un Pod non si parla con l’altro, saprai esattamente da dove iniziare a cercare. Il 73% degli incidenti di rete in Kubernetes sono riconducibili a misconfigurazioni o incomprensioni di questi concetti di base (Cloud Native Computing Foundation Survey 2025).

Leggi anche: Kubernetes SysAdmin: Guida Pratica per Troubleshooting Quotidiano (2026)

Leggi anche: CI/CD Pipeline Sicura: Checklist 12 Punti per GitLab e GitHub Actions (2026)

Leggi anche: VMware ESXi: Troubleshooting Performance — CPU Ready, Memory Balloon, Storage Latency (2026)

Aggiornato: luglio 2026