Kubernetes da zero: Pod, Deployment, Service e Namespace — Architettura e operatività

Hai un'applicazione containerizzata e funziona in locale. Ora devi portarla in produzione su più server, gestire repliche, aggiornamenti e traffico. Kubernetes lo fa, ma se non capisci cosa sono Pod, Deployment, Service e Namespace, rischi di copiare YAML da tutorial senza sapere cosa stai facendo. E quando qualcosa si rompe, ci rimetti tempo e soldi.

Noi di Meteora Web lavoriamo con Kubernetes su progetti reali da anni. Abbiamo visto clienti lanciare cluster senza isolamento tra ambienti, o usare Pod direttamente invece dei Deployment, con conseguenze disastrose. Questa guida ti spiega i quattro mattoni fondamentali — Pod, Deployment, Service, Namespace — con esempi concreti, YAML funzionanti e comandi che puoi eseguire subito. Niente teoria astratta: qui impari perché si usano e come si combinano in produzione.

Pod: l'unità atomica del cluster

Un Pod è l'oggetto più piccolo che Kubernetes gestisce. Contiene uno o più container che condividono lo stesso namespace di rete e storage. Nella pratica, la maggior parte dei Pod contiene un solo container. Perché allora chiamarlo Pod e non container? Perché Kubernetes lavora a un livello di astrazione superiore. Un Pod garantisce che i suoi container girino sullo stesso nodo, condividano localhost e volumi. Serve per pattern come sidecar (es. un proxy, un logger) che devono stare attaccati al container principale.

Errore comune: creare Pod direttamente con kubectl run. Un Pod così non si auto-ripara. Se il nodo crasha, il Pod muore con lui. Per questo esistono i Deployment.

YAML base di un Pod

apiVersion: v1
kind: Pod
metadata:
  name: web-pod
  labels:
    app: web
spec:
  containers:
  - name: nginx
    image: nginx:1.25
    ports:
    - containerPort: 80

Eseguilo con kubectl apply -f pod.yaml. Ma non farlo in produzione. Servono Deployment.

Cosa puoi fare subito: se hai un cluster, crea un Pod di test, esploralo con kubectl describe pod web-pod e poi cancellalo con kubectl delete pod web-pod. Capirai come funziona la terminazione.

Deployment: la gestione dello stato desiderato

Un Deployment dichiara quante repliche di un Pod vuoi, con quale immagine, e come aggiornarle. Kubernetes si occupa del resto: creare i Pod, sostituirli se muoiono, eseguire rolling update senza downtime. Nel nostro lavoro quotidiano, il Deployment è il punto di partenza per qualsiasi applicazione stateless.

YAML di un Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-deployment
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: nginx
        image: nginx:1.25
        ports:
        - containerPort: 80

replicas: 3 dice a Kubernetes di mantenere sempre tre Pod in esecuzione. Il selector collega il Deployment ai Pod tramite le label. Il template definisce il Pod desiderato.

Comandi operativi:

• kubectl apply -f deployment.yaml
• kubectl get pods -w per vedere lo stato
• kubectl scale deployment web-deployment --replicas=5 per scalare al volo

Abbiamo visto clienti che modificavano a mano i Pod esistenti. Con un Deployment, basta cambiare l'immagine nel file YAML e fare kubectl apply: Kubernetes esegue un rolling update sostituendo un Pod alla volta. Zero downtime.

Attenzione: senza un Service, i Pod sono raggiungibili solo all'interno del cluster tramite IP effimeri. Per esporli al mondo serve un Service.

Service: il punto d'accesso stabile

I Pod nascono e muoiono, cambiano IP. Un Service fornisce un indirizzo DNS stabile (es. web-service.default.svc.cluster.local) e bilancia il traffico tra i Pod corrispondenti alle label selezionate.

Esistono tre tipi principali:

• ClusterIP (default): accessibile solo dentro il cluster. Utile per comunicazione tra microservizi.
• NodePort: espone il Service su una porta statica di ogni nodo. Per sviluppo o ambienti piccoli.
• LoadBalancer: crea un bilanciatore esterno (su cloud come AWS, GKE, AKS). Il modo più comune per esporre in produzione.

YAML di un Service di tipo LoadBalancer

apiVersion: v1
kind: Service
metadata:
  name: web-service
spec:
  type: LoadBalancer
  selector:
    app: web
  ports:
  - port: 80
    targetPort: 80

selector: app: web dice al Service di inoltrare il traffico a tutti i Pod con quella label. port è la porta esposta dal Service, targetPort la porta del container.

Operatività: dopo aver applicato, controlla l'IP esterno con kubectl get svc web-service. Se non ottieni un IP (es. su minikube), usa minikube service web-service.

Noi, di Meteora Web, abbiamo ottimizzato Service per applicazioni ad alto traffico usando session affinity e health check. Ma la base è questa: senza Service, il tuo Deployment è invisibile.

Namespace: isolamento logico multi-ambiente

Un namespace è una partizione virtuale del cluster. Permette di separare team, ambienti (dev, staging, prod), o applicazioni. Le risorse di un namespace non vedono quelle di un altro (a meno di espliciti NetworkPolicy).

Perché è fondamentale? In molti progetti ereditati abbiamo trovato tutte le risorse nel namespace default. Un caos. Con i namespace puoi applicare quote di risorse, RBAC e reti isolate per ogni ambiente.

Creare un namespace e deployare al suo interno

kubectl create namespace staging
kubectl apply -f deployment.yaml -n staging
kubectl get pods -n staging

Oppure dichiarativo:

apiVersion: v1
kind: Namespace
metadata:
  name: staging
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-deployment
  namespace: staging
spec:
  ...

Comandi utili:

• kubectl get ns elenca i namespace
• kubectl config set-context --current --namespace=staging cambia il namespace di default del contesto

Attenzione: i namespace non isolano di default la rete. I Pod possono comunicare tra namespace tramite DNS (servizio.namespace.svc.cluster.local). Per bloccare il traffico servono NetworkPolicy, ma quello è un altro spoke.

Mettere tutto insieme: un esempio operativo

Supponiamo di voler lanciare un'applicazione web in staging, con 3 repliche e un bilanciatore esterno. Ecco la sequenza:

1. Crea il namespace (se non esiste).
2. Applica il Deployment con le label corrette.
3. Applica il Service di tipo LoadBalancer (su cloud) o NodePort (locale).
4. Verifica che i Pod siano Running e che il Service abbia un endpoint.

kubectl create namespace staging
kubectl apply -f deployment.yaml -n staging
kubectl apply -f service.yaml -n staging
kubectl get all -n staging

Il comando kubectl get all mostra Pod, Service, Deployment e ReplicaSet in un colpo solo.

Debug comune: se il Service non trova Pod, controlla le label. kubectl get pods --show-labels -n staging mostra le label reali. Il selector del Service deve corrispondere esattamente.

Errori che vediamo spesso nei progetti che arrivano da noi

• Usare Pod direttamente invece di Deployment: nessuna resilienza. Se il nodo crasha, addio.
• Omettere i namespace: tutto in default, conflitti e confusione.
• Service con selector sbagliato: il traffico non arriva ai Pod, ma nessun errore visibile.
• Impostare replicas senza Resource Requests: il cluster può sovraccaricare i nodi. Usa sempre resources.requests per CPU/memoria.
• Non usare readiness probe: il Service manda traffico a Pod che non sono ancora pronti. Aggiungi readinessProbe nel container spec.

Noi, di Meteora Web, abbiamo costruito pipeline CI/CD su Kubernetes per clienti che prima facevano deploy a mano. La differenza è abissale: da ore di downtime a rolling update trasparenti. Ma tutto parte dalla comprensione di questi quattro oggetti.

In sintesi — cosa fare adesso

1. Installa kubectl e connettiti a un cluster (minikube per test locale, o un cluster cloud gratuito come GKE Autopilot).
2. Crea il tuo primo Pod con kubectl run nginx --image=nginx e cancellalo. Poi crealo con un Deployment YAML di 2 repliche.
3. Esponilo con un Service di tipo NodePort o LoadBalancer. Verifica di raggiungerlo.
4. Dividi in namespace: sposta il Deployment in un namespace chiamato lab e ripeti l'operazione.
5. Leggi i log dei Pod con kubectl logs -n lab deployment/web-deployment-xxxx. Capisci la differenza tra log di Pod e log di Deployment.

Questa è la base per ogni architettura Kubernetes che non sia monolitica e fragile. Dopo aver padroneggiato Pod, Deployment, Service e Namespace, puoi passare a Ingress, ConfigMap, Secret, PersistentVolumeClaim e via dicendo. Ma se questi quattro non sono solidi, il resto vacilla.

Sei un'impresa che vuole portare le proprie applicazioni in produzione senza intoppi? Contattaci: lavoriamo con Kubernetes ogni giorno e ti supportiamo su infrastruttura, automazione e sicurezza.