Volume persistente in Kubernetes: tutorial

I volumi persistenti di Kubernetes (PV, Persistent Volume) svolgono un compito fondamentale per la gestione efficiente dei dati nei cluster Kubernetes. Essi consentono l’astrazione dei dati e permettono un’archiviazione coerente attraverso i cicli di vita dei pod.

Che cos’è un volume persistente in Kubernetes?

In Kubernetes, un volume persistente (PV) è una risorsa fondamentale nell’ambito dell’orchestrazione Kubernetes, che è stata sviluppata per una gestione efficiente e scalabile dei dati in cluster di container. Lo scopo di un PV è fornire un’area di memoria standardizzata e persistente. Un PV può essere utilizzato da diversi pod, indipendentemente dalle risorse di memoria fisiche a cui accede il cluster. In questo modo si ottiene un livello di astrazione superiore, separando i dettagli di memoria dalla logica applicativa.

I PV sono disponibili in forma statica e dinamica. Nella tipologia statica, le risorse di memoria sono predefinite manualmente, mentre nella forma dinamica i PV vengono creati automaticamente quando un pod presenta requisiti di memoria particolari. Questa flessibilità assicura una gestione efficiente di dati persistenti nei cluster Kubernetes e rende le applicazioni affidabili e scalabili.

Qual è la differenza fra volume e volume persistente?

In Kubernetes esistono due tipi fondamentali di volumi di archiviazione: i volumi normali e i volumi persistenti. Un volume normale è legato alla durata di vita di un singolo pod. È dichiarato direttamente nella configurazione del pod e serve principalmente all’archiviazione temporanea dei dati durante l’esecuzione del pod in questione. Quando il pod viene terminato, anche il volume normale viene sbloccato e tutti i dati che contiene vengono eliminati.

Al contrario, un volume persistente in Kubernetes ha una durata di vita maggiore ed è indipendente da un pod specifico. Può essere richiesto e sbloccato da più pod in diversi cicli di vita. I volumi persistenti vengono dichiarati separatamente dai pod e quindi accoppiati alle richieste Persistent Volume Claim (PVC). Il collegamento fra una PVC e un PV può essere dinamico o manuale. I volumi persistenti sono l’ideale per i dati che devono rimanere persistenti nel corso della vita di un singolo pod e sono un modo per condividere e memorizzare i dati fra diversi pod, anche se i pod vengono creati o eliminati.

Quali tipi di volumi persistenti esistono?

In Kubernetes esistono diversi tipi di volumi persistenti che rappresentano diverse soluzioni e tecnologie di archiviazione. Alcuni dei tipi di volumi persistenti più comuni sono:

• hostPath: il tipo HostPath unisce un volume persistente a un percorso sul nodo host nel cluster Kubernetes. Questo tipo permette di accedere a risorse di memoria locali dell’host ed è indicato per ambienti di test e sviluppo. Tuttavia, deve essere utilizzato con cautela in ambienti di produzione, in quanto i dati non vengono replicati fra i nodi.
• emptyDir: emptyDir crea un volume temporaneo e vuoto ogni volta che viene creato un pod. È utile per memorizzare dati temporanei o per lo scambio di dati fra i container all’interno dello stesso pod. Tuttavia, il volume viene eliminato quando il pod viene terminato.
• GCEPersistentDisk, AWSElasticBlockStore, AzureDisk, AzureFile: questi tipi collegano un volume persistente di Kubernetes a soluzioni di archiviazione cloud esterne, come i dischi permanenti di Google Compute Engine, i volumi Amazon EBS o i dischi e le condivisioni file di Azure. Rappresentano una possibilità per mantenere persistenti i dati su diversi pod e addirittura cluster e sono molto utili per quelle applicazioni che vengono messe a disposizione in ambienti cloud.
• nfs (Network File System): i PV del tipo NFS sono collegati a una condivisione di rete messa a disposizione tramite il Network File System (NFS). Essi permettono di condividere l’utilizzo dei dati fra diversi pod e sono una soluzione pratica nei casi in cui più pod devono accedere a file in comune.
• iscsi (Internet Small Computer System Interface): i PV basati su ISCSI si collegano a dispositivi di archiviazione a blocchi, disponibili tramite il protocollo ISCSI. Sono un modo per utilizzare dispositivi esterni di archiviazione a blocchi in cluster Kubernetes e offrono una soluzione flessibile e scalabile per i dati persistenti.
• local: il tipo local consente l’accesso diretto a risorse di memoria fisiche sul nodo locale nel cluster Kubernetes. È particolarmente utile per quelle applicazioni che devono accedere rapidamente alla memoria locale. Tuttavia, occorre utilizzarlo con cautela, in quanto le risorse di memoria locali non vengono replicate fra i diversi nodi e, in caso di anomalie del nodo, i dati possono andare persi.
• csi (Container Storage Interface): il tipo CSI consente ai fornitori di sistemi di archiviazione di integrarli per mezzo della Container Storage Interface. In questo modo, i sistemi di orchestrazione dei container come Kubernetes possono comunicare con varie soluzioni di archiviazione di terze parti. Così facendo si crea maggiore flessibilità e si permette l’utilizzo di una vasta gamma di sistemi di archiviazione che supportano la CSI.
• cephfs: CephFS è un file system distribuito a cui sono collegati i volumi persistenti di tipo CephFS. Questo tipo di PV è utilizzato per applicazioni che richiedono l’accesso a file condivisi e operano in un ambiente di archiviazione distribuito, come nel caso di Ceph.
• fc (Fibre Channel): i volumi persistenti basati su FC sono collegati a dispositivi di archiviazione Fibre Channel. Questo tipo permette di accedere a soluzioni di archiviazione esterne basate su Fibre Channel. È comune negli ambienti in cui sono utilizzate reti Fibre Channel per fornire un’archiviazione a blocchi.
• rbd (RADOS Block Device): il tipo RBD si collega ai dispositivi di archiviazione a blocchi nel cluster Ceph che operano come dispositivi a blocchi RADOS. Questo tipo ti permette di accedere al sistema di archiviazione a blocchi di Ceph e di sfruttarne i particolari vantaggi negli ambienti di archiviazione distribuiti con elevata scalabilità.

Modalità di accesso ai volumi persistenti in Kubernetes

In Kubernetes, le modalità di accesso ai volumi persistenti determinano il modo in cui i pod possono accedere ai volumi persistenti a essi associati. Esistono tre tipi di modalità di accesso principali:

• ReadWriteOnce (RWO): questa modalità consente a un singolo pod di montare il volume persistente in modalità di lettura e scrittura contemporaneamente. È utile per quelle applicazioni che richiedono il controllo esclusivo dell’accesso in scrittura. Un PV con questa modalità può essere montato solo da un pod alla volta.
• ReadOnlyMany (ROX): ReadOnlyMany consente a più pod di montare simultaneamente il volume persistente in modalità di sola lettura. È utile per quelle applicazioni che possono condividere dati in modalità condivisa ma in cui l’accesso in scrittura è limitato. Più pod possono accedere ai dati in parallelo, ma solo in modalità di accesso in lettura.
• ReadWriteMany (RWX): con ReadWriteMany, più pod possono montare il volume persistente sia in modalità di accesso in lettura che in scrittura, contemporaneamente. Questa modalità è utilizzata in situazioni in cui è richiesta una base dati comune e in cui più pod possono avere accesso in scrittura ai dati.

Quando definisci la modalità di accesso, devi considerare il tipo di accesso ai dati utilizzato dall’applicazione e verificare che la modalità selezionata supporti i modelli di accesso richiesti.

Ricorda che non tutti i tipi di volume e le classi di archiviazione supportano tutte e tre le modalità di accesso. Il supporto dipende dall’infrastruttura di archiviazione sottostante e dallo specifico tipo di volume persistente. Pertanto, è consigliabile consultare la documentazione della classe di archiviazione e del tipo di volume persistente interessati per assicurarsi che i modelli di accesso desiderati siano consentiti.

Ciclo di vita di un volume persistente (PV)

I cicli di vita dei volumi persistenti di Kubernetes possono essere suddivisi in diverse fasi che rappresentano il processo di messa a disposizione, utilizzo e sblocco dell’archiviazione persistente nel cluster.

1. Creazione (provisioning): il ciclo di vita di un PV inizia con la creazione o il provisioning. Un amministratore del cluster crea un volume persistente e lo configura in modo statico con risorse di archiviazione fisse oppure in modo dinamico per mezzo di una classe di archiviazione che consenta il provisioning dinamico.
2. Associazione (binding): un PV viene legato a una PVC (Persistent Volume Claim) quando un pod dichiara un requisito di archiviazione che corrisponde alle specifiche del PV. Questo passaggio garantisce che il PV soddisfi i requisiti di un pod specifico.
3. Utilizzo da parte del pod: una volta completato il processo di associazione, il PV può essere utilizzato da un pod. Il pod può eseguire operazioni di lettura o scrittura sul volume montato, a seconda delle modalità di accesso specificate durante la creazione del PV.
4. Conclusione dell’utilizzo: quando un pod termina il suo servizio o viene eliminato, il relativo PV può essere riutilizzato da un altro pod. Il PV viene conservato finché non viene eliminato manualmente o da una classe di archiviazione dinamica.
5. Sblocco (release): un PV può essere sbloccato esplicitamente separandolo da una PVC. In questo modo è possibile legare nuovamente il PV, eventualmente a un’altra PVC o a un altro pod.
6. Eliminazione: infine puoi anche eliminare un PV se non è più necessario. Questa operazione può essere eseguita manualmente o automaticamente, se la replica del PV è impostata nella classe di archiviazione.

Creazione di un volume persistente in Kubernetes

La creazione di un volume persistente in Kubernetes è un processo in più fasi che richiede un’attenta configurazione.

Primo passaggio: configurazione del volume persistente

Il primo passaggio consiste nell’aprire un editor di testo e creare un file YAML contenente la configurazione del volume persistente di Kubernetes. Ad esempio, puoi chiamare questo file pv.yaml. Nelle parti seguenti ti mostriamo un semplice esempio di configurazione di un PV:

apiVersion: v1
kind: PersistentVolume
metadata:
    name: my-pv
spec:
    capacity:
        storage: 1Gi
    volumeMode: Filesystem
    accessModes:
        - ReadWriteOnce
    persistentVolumeReclaimPolicy: Retain
    storageClassName: manual
    hostPath:
        path: "/mnt/data"

• apiVersion: indica la versione dell’API di Kubernetes. In questo caso è la v1.
• kind: il tipo di oggetto Kubernetes, in questo caso PersistentVolume.
• metadata: contiene metadati relativi al volume persistente, come il nome del volume.
• spec: definisce le specifiche del volume.
• capacity: indica la capacità di archiviazione, in questo esempio 1 GB.
• volumeMode: indica la modalità per il volume, Filesystem oppure Block. In questo esempio utilizziamo Filesystem.
• accessModes: definisce le modalità di accesso. In questo caso, ReadWriteOnce indica l’accesso esclusivo in lettura e scrittura.
• persistentVolumeReclaimPolicy: indica come gestire il volume quando non è più necessario. Retain significa che il volume deve essere eliminato manualmente.
• storageClassName: assegna una classe di archiviazione al volume persistente.
• hostPath: definisce il percorso nel file system host che verrà utilizzato come spazio di archiviazione per il volume persistente.

Secondo passaggio: applicazione della configurazione

Dopo aver definito il file di configurazione PV, puoi attivarlo con Kubelet:

kubectl apply -f pv.yaml

Questo comando invia il file di configurazione al cluster Kubernetes, che crea le risorse al suo interno.

Terzo passaggio: applicazione della configurazione

Per assicurarti che il volume persistente di Kubernetes sia stato creato correttamente, puoi utilizzare il seguente comando:

kubectl get pv

Il comando elenca tutti i volumi persistenti che sono presenti nel cluster.

NAME   CAPACITY  ACCESS MODES  RECLAIM POLICY  STATUS  CLAIM  STORAGECLASS  REASON  AGE
my-pv   1Gi          RWX          Retain        Available           manual             1h

Quarto passaggio: creazione di una Persistent Volume Claim (PVC)

Compila un file YAML che specifichi la configurazione della Persistent Volume Claim:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
    name: my-pvc
spec:
    accessModes:
        - ReadWriteOnce
    resources:
        requests:
            storage: 1Gi
    storageClassName: manual

Applica il file di configurazione PVC al cluster Kubernetes:

kubectl apply -f pvc.yaml

Verifica che la Persistent Volume Claim sia stata creata correttamente e utilizza il comando seguente:

kubectl get pvc

Il risultato dovrebbe essere simile a questo:

NAME      STATUS   VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   AGE
my-pvc     Bound    my-pv     1Gi           RWO          manual       1m

A questo punto creiamo il manifest YAML pvc-dynamic.yaml come esempio di provisioning dinamico di una Persistent Volume Claim (PVC) in Kubernetes. Il manifest crea e richiede automaticamente un nuovo volume persistente da 1 gigabyte in Kubernetes, che è supportato dalla classe di archiviazione standard.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
    name: pvc-dynamic
spec:
    accessModes:
        - ReadWriteOnce
    resources:
        requests:
            storage: 1Gi
    storageClassName: standard

Dopo aver definito le configurazioni, attiviamo il manifest:

kubectl apply -f pvc-dynamic.yaml

Quinto passaggio: collegamento delle PVC con i pod

Per realizzare un’associazione fra PVC e pod, è necessario impostare la configurazione per il pod che utilizzerà l’archiviazione persistente.

apiVersion: v1
kind: Pod
metadata:
    name: mypod
spec:
    volumes:
    - name: mypvc-volume
        persistentVolumeClaim:
            claimName: my-pvc
    containers:
    - name: mycontainer
        image: myimage
        volumeMounts:
        - mountPath: "/app/data"
            name: mypvc-volume

Applica la configurazione del pod al cluster Kubernetes per creare il pod:

kubectl apply -f pod.yaml

Se hai appena iniziato a utilizzare Kubernetes, troverai tutte le informazioni più importanti su installazione e configurazione di un cluster nel tutorial di Kubernetes della nostra guida.