Con il cluster Kubernetes operativo, il passo successivo è quello di gestire la cosa più critica di tutte i dati.
Un cluster senza storage persistente è solo una piattaforma di calcolo.
Un cluster con storage condiviso diventa invece una piattaforma applicativa reale 🙂
Il problema da risolvere
Le applicazioni Kubernetes non possono dipendere dai dischi locali dei nodi:
- un pod può spostarsi da un nodo all’altro
- un nodo può spegnersi
- un container può essere ricreato
Quindi se i dati restano legati al nodo, vengono persi.
Serve quindi uno storage:
- condiviso tra i nodi
- persistente
- gestito dinamicamente da Kubernetes
Lo storage esterno: Synology e WD
Nel laboratorio erano disponibili due sistemi di storage esterni:
- Synology → usato come storage primario con supporto iSCSI e snapshot
- WD NAS → usato come repository NFS per la seconda copia (backup)
Integrazione dello storage con Kubernetes
Per permettere a Kubernetes di usare lo storage Synology come se fosse nativo, è stato installato:
- CSI Driver di Synology
- Snapshot Controller CSI
Questi componenti trasformano lo storage fisico in risorse Kubernetes:
- PersistentVolumes
- PersistentVolumeClaims
- VolumeSnapshots
In pratica, Kubernetes ha iniziato a parlare direttamente con il NAS, senza script o mount manuali.
Le StorageClass
Una volta installato il driver, sono state create le StorageClass, che definiscono:
- tipo di storage (iSCSI)
- policy di cancellazione
- supporto snapshot
Ogni applicazione che richiede storage non chiede più “un disco”, ma chiede una Storage Class con determinate caratteristiche.
Ed è K8s, tramite il CSI driver, che crea automaticamente i volumi sul NAS.
Verifica con PV, PVC e Pod
Per validare l’integrazione sono stati creati:
- un PVC (PersistentVolumeClaim)
- un PV (creato dinamicamente dal NAS)
- un Pod di test che scrive dati sul volume
In quel momento è stato verificato che:
- il volume esiste realmente sul Synology
- il pod può scrivere dati
- i dati sopravvivono al riavvio del pod
Questo è stato il primo vero test di persistenza reale del cluster.
Risultato
Il cluster è diventato un cluster Kubernetes con storage condiviso.
Ora il sistema era pronto per:
- snapshot
- backup
- restore
- disaster recovery
Prossimo capitolo, usare Kasten K10 per proteggere l’ambiente.