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

Q: Come posso diagnosticare problemi di connettività tra Pod in Namespace diversi?

Inizia verificando che i Pod siano Running e che i loro IP siano corretti. Poi, usa kubectl exec per entrare in un Pod e tentare di fare ping o curl all'IP dell'altro Pod. Se fallisce, controlla le NetworkPolicy nei Namespace coinvolti. Spesso, una NetworkPolicy in un Namespace impedisce il traffico da o verso l'altro Namespace.

Pod che non si parlano. Service con zero endpoint. DNS che non risolve. Quando un’applicazione su Kubernetes smette di funzionare, il 70% delle volte il problema risiede nel networking. Questa non è una statistica inventata, ma un’osservazione ricorrente in ambienti enterprise complessi, dove la comprensione del flusso di rete è fondamentale per il troubleshooting rapido e efficace. Un dato interessante da Red Hat (2024) indica che le misconfigurazioni di rete sono tra le cause principali di downtime in cluster Kubernetes.

Capire come funziona il networking in Kubernetes non è magia nera, ma una logica precisa che, una volta padroneggiata, permette di risolvere la maggior parte degli incidenti in pochi minuti. In questa guida pratica, esploreremo i concetti chiave del networking Kubernetes, dai Service ai DNS, fino all’Ingress e alle NetworkPolicy, fornendo strumenti e comandi utili per ogni Sysadmin.

Prerequisiti / Ambiente di test

Per seguire questa guida, è utile avere accesso a un cluster Kubernetes funzionante (minikube, Kind, o un cluster cloud come EKS/AKS/GKE) e l’utility kubectl configurata. Tutte le operazioni descritte sono state testate su Kubernetes v1.29.

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

Il networking in Kubernetes si basa su un modello di rete flat, dove ogni Pod riceve un proprio indirizzo IP e può comunicare con qualsiasi altro Pod nel cluster, senza NAT. Questo è possibile grazie a un overlay network virtuale creato sopra la rete fisica o virtuale sottostante.

Il cuore di questa architettura è il CNI (Container Network Interface), uno standard che permette a diversi provider (come Calico, Flannel, Cilium) di implementare la connettività di rete per i Pod. Il CNI assegna gli IP ai Pod e configura le regole di routing necessarie. Senza un CNI, i Pod non possono comunicare.

Un altro componente cruciale è kube-proxy, un demone che gira su ogni nodo del cluster. Kube-proxy non è un proxy tradizionale, ma si occupa di mantenere le regole di rete (principalmente tramite iptables o IPVS) per i Service, garantendo che le richieste ai Service vengano instradate correttamente ai Pod backend. Questo significa che quando un client tenta di connettersi a un Service, kube-proxy reindirizza il traffico a uno dei Pod associati.

ClusterIP, NodePort, LoadBalancer: quando usare cosa

Kubernetes offre diversi tipi di Service per esporre le applicazioni, ognuno con uno scopo specifico:

ClusterIP: Questo è il tipo di Service predefinito. Espone il Service su un IP interno al cluster, rendendolo raggiungibile solo da altri Pod all’interno dello stesso cluster. È ideale per i servizi interni che non devono essere esposti all’esterno, come un database o un backend API.
NodePort: Espone il Service su una porta statica su ogni nodo del cluster. Accedendo a NodeIP:NodePort, il traffico viene inoltrato al Service. Utile per scopi di test o per esporre servizi a un load balancer esterno che non è integrato con Kubernetes.
LoadBalancer: Questo tipo di Service è disponibile solo in ambienti cloud. Richiede un provider cloud che supporti i load balancer (es. AWS ELB, Azure Load Balancer, Google Cloud Load Balancing). Il cloud provider crea automaticamente un load balancer esterno con un IP pubblico che instrada il traffico al Service. È il modo più comune per esporre applicazioni di produzione a internet.

Per ispezionare gli endpoints di un service, un comando utile è:

kubectl get endpoints <service-name>

Questo ti mostrerà gli IP dei Pod a cui il Service sta instradando il traffico. Se questa lista è vuota, il tuo Service non ha Pod backend sani o correttamente etichettati.

CoreDNS: come Kubernetes risolve i nomi interni

CoreDNS è il server DNS predefinito in Kubernetes e gioca un ruolo centrale nella risoluzione dei nomi dei Service e dei Pod all’interno del cluster. Ogni Pod è configurato per utilizzare CoreDNS per la risoluzione dei nomi. Quando un Pod cerca di connettersi a my-service.my-namespace.svc.cluster.local, CoreDNS traduce questo nome nell’IP del Service my-service.

Un problema comune è un DNS mal configurato o non funzionante, che impedisce ai Pod di comunicare tra loro o con servizi esterni. Per debuggare la risoluzione DNS da dentro un Pod, puoi usare un’immagine busybox:

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

Questo comando avvierà un Pod temporaneo con busybox ed eseguirà nslookup per risolvere il nome del Service kubernetes.default, che dovrebbe sempre funzionare. Se questo fallisce, hai un problema grave con CoreDNS o la configurazione di rete del Pod.

Ingress: esporre applicazioni con un solo IP

Mentre i Service di tipo LoadBalancer espongono un singolo Service con un IP pubblico, l’Ingress è un oggetto API che gestisce l’accesso esterno ai servizi HTTP e HTTPS all’interno del cluster. L’Ingress agisce come un router di livello 7, permettendo di consolidare il routing del traffico per più servizi sotto un singolo IP pubblico (spesso fornito da un LoadBalancer Service per l’Ingress Controller stesso).

Un Ingress Controller (come NGINX Ingress Controller o Traefik) è richiesto per soddisfare le regole definite nell’oggetto Ingress. Questo controller è responsabile di configurare un reverse proxy per indirizzare il traffico alle applicazioni corrette in base al nome host, al path URL e ad altre regole. L’Ingress semplifica la gestione di certificati TLS e la configurazione di virtual hosts.

NetworkPolicy: isolamento tra namespace e pod

Le NetworkPolicy sono un meccanismo di sicurezza a livello di rete che permette di controllare il flusso di traffico tra i Pod. Sono essenziali per implementare il principio del minimo privilegio e segmentare la rete all’interno del cluster, riducendo la superficie di attacco. Le NetworkPolicy sono state introdotte per rispettare standard come ISO 27001:2022 e NIST CSF 2.0 per l’isolamento dei carichi di lavoro.

Per impostazione predefinita, i Pod possono comunicare liberamente tra loro. Una NetworkPolicy può definire regole di Ingress (traffico in entrata) ed Egress (traffico in uscita) basate su label di Pod e Namespace. Una buona pratica è implementare una politica di default-deny, bloccando tutto il traffico non esplicitamente consentito:

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

Questa policy, applicata a un Namespace, bloccherà tutto il traffico in entrata e in uscita per i Pod in quel Namespace, a meno che non ci siano altre NetworkPolicy che lo consentano esplicitamente. Questo è un passo fondamentale per la sicurezza di un cluster di produzione.

Debug networking: kubectl exec + nslookup + tcpdump nel pod

Quando il networking su Kubernetes si comporta in modo inatteso, è fondamentale avere una metodologia di debug. Ecco alcuni strumenti e tecniche:

Verifica lo stato dei Pod e dei Service: kubectl get pods -o wide, kubectl get services, kubectl get endpoints. Controlla gli IP, le porte e che i Pod siano Running.
Test DNS dal Pod: Come visto, usare nslookup da un Pod temporaneo (busybox) è il primo passo per diagnosticare problemi di risoluzione nomi.

    kubectl run -it --rm debug --image=busybox -- nslookup my-service.my-namespace.svc.cluster.local

Ispeziona le regole di iptables/IPVS: Su un nodo, puoi usare iptables -L -t nat o ipvsadm -Ln per vedere come kube-proxy sta configurando le regole di routing per i Service. Questo richiede accesso SSH al nodo.
Traccia il traffico nel Pod: Per un’analisi più approfondita, puoi usare tcpdump direttamente all’interno di un Pod. Prima, assicurati che il Pod abbia tcpdump o installalo (se l’immagine lo permette).

    # Tracciare traffico nel pod
    kubectl exec <pod-name> -c <container-name> -- tcpdump -i eth0 port 80

Sostituisci e con i valori corretti e port 80 con la porta desiderata.

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

DNS che non risolve: Spesso causato da problemi a CoreDNS (Pod non sani), un CNI non funzionante, o una resolv.conf errata all’interno del Pod. Verifica i log di CoreDNS (kubectl logs -n kube-system -l k8s-app=kube-dns) e la configurazione del CNI.
Service senza endpoint: Indica che il Service non ha Pod sani a cui indirizzare il traffico. Le cause comuni includono Pod che non sono Running, label selector del Service che non corrisponde alle label dei Pod, o Pod che non superano i readiness/liveness probes. Controlla le label e gli stati dei Pod.
NetworkPolicy troppo restrittive: A volte, una NetworkPolicy blocca il traffico necessario. Monitora i log del CNI (se supporta il logging delle policy) o rimuovi temporaneamente le policy per isolare il problema.
Porta non mappata correttamente: Assicurati che la containerPort nel Deployment corrisponda alla targetPort nel Service e che la port nel Service sia quella che i client useranno.

FAQ — Domande Frequenti

Qual è la differenza tra un Service NodePort e un Ingress?

Un Service NodePort espone un’applicazione su una porta specifica su ogni nodo del cluster, rendendola accessibile tramite l’IP di qualsiasi nodo e quella porta. Un Ingress, invece, è un oggetto di livello 7 che permette di esporre molteplici servizi sotto un singolo IP/hostname esterno, gestendo il routing basato su URL e nomi host, oltre a terminare il traffico TLS. L’Ingress richiede un Ingress Controller per funzionare.

Come posso diagnosticare problemi di connettività tra Pod in Namespace diversi?

Inizia verificando che i Pod siano Running e che i loro IP siano corretti. Poi, usa kubectl exec per entrare in un Pod e tentare di fare ping o curl all’IP dell’altro Pod. Se fallisce, controlla le NetworkPolicy nei Namespace coinvolti. Spesso, una NetworkPolicy in un Namespace impedisce il traffico da o verso l’altro Namespace.

È possibile usare un LoadBalancer senza un cloud provider?

Tecnicamente sì, con soluzioni come MetalLB per cluster on-premise. MetalLB è un’implementazione di un LoadBalancer per ambienti bare-metal, che permette di assegnare indirizzi IP esterni ai Service di tipo LoadBalancer senza dipendere da un cloud provider. Richiede però una configurazione aggiuntiva della rete sottostante.

Conclusioni con takeaway operativi

Il networking di Kubernetes è un sistema robusto e complesso, ma basato su principi logici. La chiave per gestirlo efficacemente è comprendere i ruoli di CNI, kube-proxy, Service e CoreDNS. Non sottovalutare l’importanza delle NetworkPolicy per la sicurezza e usa gli strumenti di debugging (kubectl exec, nslookup, tcpdump) per isolare rapidamente i problemi. Mantenere una buona comprensione di questi concetti ti permetterà di mantenere le tue applicazioni online e performanti, riducendo significativamente i tempi di risoluzione degli incidenti.

Aggiornato: luglio 2026