Persistent Volumes e StatefulSet in Kubernetes — Storage Progettato per Sopravvivere al Crash dei Pod

Il tuo database PostgreSQL in Kubernetes è sparito con il pod? O peggio: hai perso dati perché il volume era legato al ciclo di vita del container. Succede più spesso di quanto pensi. Noi, di Meteora Web, lo abbiamo visto nei progetti che ci arrivano dopo un disastro: volumi temporanei, claim male configurati, StatefulSet usati come fossero Deployment. La differenza tra un’infrastruttura che regge e una che crolla al primo crash è tutta qui: Persistent Volumes e StatefulSet. Se gestisci applicazioni stateful in produzione, questa guida ti serve per non ripetere gli errori che paghiamo noi quando facciamo recovery.

Perché lo storage in Kubernetes non è uguale a quello di un server singolo?

Su un server fisico o VM, il disco è lì. Monti, scrivi, riavvi: i dati restano. In Kubernetes, i pod sono effimeri. Nascono, muoiono, si replicano. Se un pod scrive su un filesystem locale e poi viene ricreato su un nodo diverso, i dati spariscono. Ecco perché servono i PersistentVolume (PV) e i PersistentVolumeClaim (PVC): separano la dichiarazione di bisogno di storage (claim) dalla risorsa fisica (volume).

Con un PVC dichiari: “voglio 10 GiB di storage con accesso ReadWriteOnce”. Kubernetes cerca un PV che soddisfi la richiesta e lo lega al pod. Se il pod muore e rinasce su un altro nodo, il PVC si riaggancia allo stesso PV, che è persistente. Sembra semplice, ma i dettagli (classi di storage, reclaim policy, access modes) fanno la differenza tra un setup funzionante e uno che perde dati al primo scale down.

Come funzionano PersistentVolume e PersistentVolumeClaim in pratica?

Dividiamo i concetti. Un PV è una risorsa del cluster: un pezzo di storage pre-provisionato o dinamico. Ha un storageClassName, una capacità, una modalità di accesso (ReadWriteOnce, ReadOnlyMany, ReadWriteMany) e una reclaim policy: Retain, Delete, Recycle. Retain conserva il volume anche dopo che il PVC viene eliminato — utile per disaster recovery. Delete lo cancella con il PVC — attenzione ai dati sensibili.

Un PVC è la richiesta. Esempio YAML per un PVC per un database MySQL:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: mysql-data
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: standard

Kubernetes cerca un PV che matcha. Se la StorageClass è di tipo dinamico (es. provisioner: kubernetes.io/aws-ebs), il PV viene creato automaticamente. È il metodo più usato in produzione: dichiari bisogno e il cluster lo approvvigiona.

Errori comuni da evitare con PV e PVC

• AccessMode sbagliato: un database clusterizzato su più repliche con ReadWriteOnce non funziona. Usa ReadWriteMany su volumi NFS, ma attento alle performance.
• ReclaimPolicy Delete su volumi critici: se per errore cancelli il PVC, il volume sparisce. Scegli Retain per dati di produzione.
• StorageClass non definita: se non specifichi storageClassName, Kubernetes usa la default — che potrebbe essere lenta o non persistente. Verifica sempre.

Perché StatefulSet è obbligatorio per applicazioni stateful?

Un Deployment crea pod identici e intercambiabili. Se un pod muore, ne nasce un altro con un nome e IP diversi. Per applicazioni stateful (database, coda messaggi, sistemi che tengono identità di rete) questo non va bene. StatefulSet garantisce:

• Identità stabile: ogni pod ha un nome ordinale (mysql-0, mysql-1) e un hostname fisso.
• Storage persistente: ogni pod ha il suo PVC creato da un template, legato per sempre allo stesso pod.
• Ordine di start/stop: i pod partono in sequenza, ideale per cluster che richiedono un master prima delle repliche.

Noi abbiamo visto team usare Deployment per un database “tanto non è produzione”. Risultato: dopo un rolling update, il nuovo pod non trovava i dati perché il volume era attaccato al pod vecchio. Con StatefulSet e volumeClaimTemplates, ogni pod riceve il suo volume univoco e lo riaggancia sempre allo stesso pod, anche dopo crash o update.

Come configurare un PersistentVolumeClaim in uno StatefulSet — esempio completo

Ecco un esempio di StatefulSet per MySQL con storage persistente. Nota volumeClaimTemplates — non un semplice volume mount:

apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: mysql
spec:
  serviceName: mysql
  replicas: 3
  selector:
    matchLabels:
      app: mysql
  template:
    metadata:
      labels:
        app: mysql
    spec:
      containers:
      - name: mysql
        image: mysql:8.0
        env:
        - name: MYSQL_ROOT_PASSWORD
          value: "password"
        volumeMounts:
        - name: data
          mountPath: /var/lib/mysql
  volumeClaimTemplates:
  - metadata:
      name: data
    spec:
      accessModes: [ "ReadWriteOnce" ]
      storageClassName: standard
      resources:
        requests:
          storage: 10Gi

Kubernetes crea un PVC per ogni replica: data-mysql-0, data-mysql-1… e i nomi dei pod rimangono fissi. Se il pod mysql-0 viene cancellato e ricreato, riottiene lo stesso PVC e quindi gli stessi dati. Perfetto per database.

Accesso ai volumi con ReadWriteOnce in cluster multi-pod

Se hai un cluster MySQL con repliche che devono leggere dagli stessi dati, ReadWriteOnce non basta: ogni replica ha il suo volume. Soluzioni possibili:

• Usare un database nativamente distribuito (Galera, Vitess) che gestisce la replica a livello di applicazione.
• Usare un volume NFS con ReadWriteMany, ma attento: NFS non è performante per scritture sincrone.
• Configurare un operatore come MySQL Operator che crea automaticamente volumi separati per ogni nodo.

La scelta dipende dal carico e dal budget. Noi consigliamo di testare sempre con carichi reali prima di andare in produzione.

Quali storage back-end scegliere per produzione in Kubernetes?

Non tutti i CSI driver sono uguali. Ecco i più usati con i pro e contro:

• Cloud provider (EBS, GCE Persistent Disk, AzureDisk): performanti, resilienti, ma legati a una zona di disponibilità. Buoni per carichi transactional.
• Longhorn (Rancher): open source, sfrutta i dischi locali dei nodi e replica tra nodi. Ottimo per cluster on-premise.
• Rook/Ceph: potente, complesso da gestire. Ideale per grandi cluster con necessità di object storage e block storage insieme.
• Local Persistent Volume: usa il disco locale del nodo. Velocissimo, ma se il nodo muore, il volume è irraggiungibile. Adatto per etcd su nodi dedicati.

Noi abbiamo configurato Longhorn su cluster bare metal per un cliente che doveva evitare lock-in cloud. Funziona, ma bisogna monitorare lo stato della replica e avere failover pronto.

Come gestire backup, snapshot, resize e disaster recovery dei volumi?

Un PV persistente non è un backup. Se un amministratore cancella accidentalmente il PVC con reclaim policy Delete, addio dati. Ecco le pratiche che applichiamo nei nostri progetti:

• Snapshot con CSI: ogni CSI driver supporta VolumeSnapshot. Crea snapshot periodici (es. ogni ora) e conservali per 7 giorni. Esempio per Longhorn: kubectl apply -f volume-snapshot.yaml.
• Backup esterno con Velero: strumento open source che esporta i PV su object storage (S3, MinIO). Permette restore completo del cluster. Noi lo usiamo per disaster recovery.
• Resize a caldo: se hai bisogno di più spazio, aggiorna il PVC e modifica la storage class per supportare l’espansione. Esempio: kubectl edit pvc mysql-data-0 -n database e aumenta storage. Funziona se il CSI driver lo supporta.
• Disaster recovery: tieni i manifest del cluster in Git (GitOps), e usa Velero per backup dei PV su un secondo cluster o cloud region.

Un cliente e-commerce perdeva snapshot perché il CSI driver di default era configurato senza retention. Noi abbiamo aggiunto un cron job che crea snapshot con etichetta retain: 7d e li elimina dopo una settimana.

Cosa fare adesso

Ora hai le basi per non perdere dati su Kubernetes. Ecco tre azioni immediate:

1. Controlla la reclaim policy dei tuoi PV attuali. Se è Delete, valuta se passare a Retain per i volumi critici. Prova in un ambiente di test.
2. Sostituisci i Deployment delle applicazioni stateful con StatefulSet. Usa volumeClaimTemplates e verifica che i PVC siano nominati correttamente.
3. Implementa uno strumento di backup come Velero o snapshot CSI. Ti serve per dormire sereno. Non aspettare il primo crash.

Se vuoi approfondire l’orchestrazione completa dei container con tutti gli aspetti di produzione, leggi la nostra guida pillar su Kubernetes. Per il resto, siamo qui: lavoriamo con il territorio e con il codice tutti i giorni. La teoria aiuta, ma la pratica salva i dati.