Kubernetes Networking: apriamo la Matrioska al mondo, senza mal di testa

1) La Matrioska: dall’ applicativo all’utente finale (Applicativo → Container → Pod → Service → Ingress → LB → Client)

Il guscio più interno è il container: è dove gira davvero il tuo applicativo, ma Kubernetes ragiona quasi sempre a livello di Pod, cioè il “contenitore di contenitori”. Un Pod può avere uno o più container (tipico: app + sidecar tipo proxy o agent), e la cosa fondamentale per il networking è questa:

• tutti i container nello stesso Pod condividono la stessa rete
  Quindi: stesso IP, stesso namespace di rete, e possono parlarsi su localhost.

In pratica, se hai un container “app” che espone :8080 e un sidecar che deve intercettare o osservare traffico, per loro è come vivere nello stesso appartamento: bussano alla porta di casa e via.

Ogni Pod riceve poi un IP proprio nella rete del cluster, ma idealmente, ogni Pod può parlare con qualsiasi altro Pod senza fare acrobazie. Questa cosa la realizza il plugin CNI (Calico/Cilium/Flannel/…), ma il concetto per te è semplice: la rete del cluster è una rete vera, anche se è “virtuale”.

2) Il Service: un indirizzo stabile per bersagli instabili

Se i Pod cambiano IP come calzini dopo la palestra, tu vuoi un riferimento stabile. E lo ottieni con un Service: il “numero fisso” che sta davanti a un gruppo di Pod.

Un Service seleziona i Pod con delle label e ti offre:

• un IP virtuale stabile (tipicamente un ClusterIP) raggiungibile dentro il cluster
• un nome DNS facile da ricordare (tipo api.default.svc.cluster.local)
• bilanciamento verso i Pod disponibili

Il Service è la risposta alla domanda: “Come faccio a chiamare l’app e non quel Pod specifico?”
E da qui discende un pattern sano: i componenti interni del cluster parlano quasi sempre Service-to-Service, non Pod-to-Pod.

Tipi comuni (versione “senza mal di testa”):

• ClusterIP: solo interno cluster. È il default e spesso basta per microservizi.
• NodePort: apre una porta su ogni nodo e inoltra al Service. Funziona, ma è spesso il “piano B”: utile per test o casi semplici.
• LoadBalancer: lo teniamo per la sezione finale, perché è il guscio più esterno “cloud-friendly”.

Nota da tenere a mente: un Service non è “magia DNS e basta”. Dietro c’è un meccanismo di forwarding (kube-proxy con iptables/ipvs, o alternative) che fa sì che l’IP del Service distribuisca traffico ai Pod giusti.

Fin qui: hai stabilità interna. Ma come entra il traffico da fuori? E come gestisci HTTP, host, path, TLS? Apriamo la prossima matrioska.

3) Ingress: il portiere per HTTP/HTTPS (host, path, TLS)

Il Service ti dà un endpoint stabile, ma di solito non vuoi esporre 12 servizi al mondo ognuno con la sua porta. Vuoi qualcosa tipo:

• https://shop.example.com/ → frontend
• https://shop.example.com/api → backend
• TLS gestito bene, redirect, magari rate limit e compagnia

Qui entra Ingress: è una risorsa Kubernetes che descrive regole di routing HTTP/HTTPS (host e path) verso uno o più Service.

Però attenzione: Ingress da solo è un “manifesto”, non un “oggetto fisico”. Per funzionare serve un Ingress Controller (Nginx Ingress, Traefik, HAProxy, Contour, ecc.) che prende quelle regole e le rende operative, tipicamente comportandosi come un reverse proxy.

In breve:

• Ingress = “regole”
• Ingress Controller = “chi le applica”

Ingress è la scelta giusta quando:

• hai tante app web e vuoi un singolo punto d’ingresso
• vuoi routing per host/path
• vuoi gestire TLS in modo centralizzato
• vuoi funzionalità da proxy (rewrite, header, auth, ecc.)

E quindi: Ingress sta “sopra” i Service, e i Service stanno “sopra” i Pod.

Resta un ultimo guscio: come fai ad avere un IP pubblico e un vero entrypoint dal mondo esterno verso il tuo controller (o verso un servizio TCP/UDP)? E qui arriva LoadBalancer.

4) LoadBalancer: l’uscita elegante verso l’esterno (e il ponte col cloud)

Il tipo di Service LoadBalancer è il modo “Kubernetes-friendly” per dire:
“Ehi infrastruttura, dammi un endpoint esterno per questo Service”.

In un ambiente cloud (AWS, GCP, Azure), creare un Service di tipo LoadBalancer di solito porta alla creazione di un load balancer gestito dal provider, con:

• IP pubblico o DNS pubblico
• health check
• forwarding verso i nodi / target (a seconda dell’implementazione)

Nel mondo on-prem, spesso non hai un load balancer “magico” che appare dal nulla. Qui entrano soluzioni come MetalLB (che assegna IP esterni sulla LAN) o integrazioni con appliance/ingress specifici. Il concetto però non cambia: LoadBalancer è il guscio che collega Kubernetes a una rete esterna reale.

Pattern tipico super comune:

1. esponi l’Ingress Controller con un Service di tipo LoadBalancer
2. punti DNS pubblico (es. shop.example.com) a quell’IP/DNS esterno
3. Ingress fa routing verso i Service interni
4. Service distribuisce verso i Pod

È una catena pulita:
Internet → LoadBalancer → Ingress Controller → Service → Pod → Container → Applicativo

A questo punto la mappa è completa. Il segreto è trattare questi livelli come responsabilità distinte: i Pod cambiano, i Service restano, l’Ingress governa le rotte e il LoadBalancer espone l’ingresso. Con questo schema a “matrioska” in testa, anche i cluster più affollati diventano leggibili.