Volume per­si­sten­te in Ku­ber­ne­tes: tutorial

I volumi per­si­sten­ti di Ku­ber­ne­tes (PV, Per­si­stent Volume) svolgono un compito fon­da­men­ta­le per la gestione ef­fi­cien­te dei dati nei cluster Ku­ber­ne­tes. Essi con­sen­to­no l’astra­zio­ne dei dati e per­met­to­no un’ar­chi­via­zio­ne coerente at­tra­ver­so i cicli di vita dei pod.

Che cos’è un volume per­si­sten­te in Ku­ber­ne­tes?

In Ku­ber­ne­tes, un volume per­si­sten­te (PV) è una risorsa fon­da­men­ta­le nell’ambito dell’or­che­stra­zio­ne Ku­ber­ne­tes, che è stata svi­lup­pa­ta per una gestione ef­fi­cien­te e scalabile dei dati in cluster di container. Lo scopo di un PV è fornire un’area di memoria stan­dar­diz­za­ta e per­si­sten­te. Un PV può essere uti­liz­za­to da diversi pod, in­di­pen­den­te­men­te dalle risorse di memoria fisiche a cui accede il cluster. In questo modo si ottiene un livello di astra­zio­ne superiore, separando i dettagli di memoria dalla logica ap­pli­ca­ti­va.

I PV sono di­spo­ni­bi­li in forma statica e dinamica. Nella tipologia statica, le risorse di memoria sono pre­de­fi­ni­te ma­nual­men­te, mentre nella forma dinamica i PV vengono creati au­to­ma­ti­ca­men­te quando un pod presenta requisiti di memoria par­ti­co­la­ri. Questa fles­si­bi­li­tà assicura una gestione ef­fi­cien­te di dati per­si­sten­ti nei cluster Ku­ber­ne­tes e rende le ap­pli­ca­zio­ni af­fi­da­bi­li e scalabili.

Qual è la dif­fe­ren­za fra volume e volume per­si­sten­te?

In Ku­ber­ne­tes esistono due tipi fon­da­men­ta­li di volumi di ar­chi­via­zio­ne: i volumi normali e i volumi per­si­sten­ti. Un volume normale è legato alla durata di vita di un singolo pod. È di­chia­ra­to di­ret­ta­men­te nella con­fi­gu­ra­zio­ne del pod e serve prin­ci­pal­men­te all’ar­chi­via­zio­ne tem­po­ra­nea dei dati durante l’ese­cu­zio­ne 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 per­si­sten­te in Ku­ber­ne­tes ha una durata di vita maggiore ed è in­di­pen­den­te da un pod specifico. Può essere richiesto e sbloccato da più pod in diversi cicli di vita. I volumi per­si­sten­ti vengono di­chia­ra­ti se­pa­ra­ta­men­te dai pod e quindi ac­cop­pia­ti alle richieste Per­si­stent Volume Claim (PVC). Il col­le­ga­men­to fra una PVC e un PV può essere dinamico o manuale. I volumi per­si­sten­ti sono l’ideale per i dati che devono rimanere per­si­sten­ti nel corso della vita di un singolo pod e sono un modo per con­di­vi­de­re e me­mo­riz­za­re i dati fra diversi pod, anche se i pod vengono creati o eliminati.

Quali tipi di volumi per­si­sten­ti esistono?

In Ku­ber­ne­tes esistono diversi tipi di volumi per­si­sten­ti che rap­pre­sen­ta­no diverse soluzioni e tec­no­lo­gie di ar­chi­via­zio­ne. Alcuni dei tipi di volumi per­si­sten­ti più comuni sono:

• hostPath: il tipo HostPath unisce un volume per­si­sten­te a un percorso sul nodo host nel cluster Ku­ber­ne­tes. Questo tipo permette di accedere a risorse di memoria locali dell’host ed è indicato per ambienti di test e sviluppo. Tuttavia, deve essere uti­liz­za­to con cautela in ambienti di pro­du­zio­ne, in quanto i dati non vengono replicati fra i nodi.
• emptyDir: emptyDir crea un volume tem­po­ra­neo e vuoto ogni volta che viene creato un pod. È utile per me­mo­riz­za­re dati tem­po­ra­nei 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 per­si­sten­te di Ku­ber­ne­tes a soluzioni di ar­chi­via­zio­ne cloud esterne, come i dischi per­ma­nen­ti di Google Compute Engine, i volumi Amazon EBS o i dischi e le con­di­vi­sio­ni file di Azure. Rap­pre­sen­ta­no una pos­si­bi­li­tà per mantenere per­si­sten­ti i dati su diversi pod e ad­di­rit­tu­ra cluster e sono molto utili per quelle ap­pli­ca­zio­ni che vengono messe a di­spo­si­zio­ne in ambienti cloud.
• nfs (Network File System): i PV del tipo NFS sono collegati a una con­di­vi­sio­ne di rete messa a di­spo­si­zio­ne tramite il Network File System (NFS). Essi per­met­to­no di con­di­vi­de­re 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 di­spo­si­ti­vi di ar­chi­via­zio­ne a blocchi, di­spo­ni­bi­li tramite il pro­to­col­lo ISCSI. Sono un modo per uti­liz­za­re di­spo­si­ti­vi esterni di ar­chi­via­zio­ne a blocchi in cluster Ku­ber­ne­tes e offrono una soluzione fles­si­bi­le e scalabile per i dati per­si­sten­ti.
• local: il tipo local consente l’accesso diretto a risorse di memoria fisiche sul nodo locale nel cluster Ku­ber­ne­tes. È par­ti­co­lar­men­te utile per quelle ap­pli­ca­zio­ni che devono accedere ra­pi­da­men­te alla memoria locale. Tuttavia, occorre uti­liz­zar­lo 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 ar­chi­via­zio­ne di in­te­grar­li per mezzo della Container Storage Interface. In questo modo, i sistemi di or­che­stra­zio­ne dei container come Ku­ber­ne­tes possono co­mu­ni­ca­re con varie soluzioni di ar­chi­via­zio­ne di terze parti. Così facendo si crea maggiore fles­si­bi­li­tà e si permette l’utilizzo di una vasta gamma di sistemi di ar­chi­via­zio­ne che sup­por­ta­no la CSI.
• cephfs: CephFS è un file system di­stri­bui­to a cui sono collegati i volumi per­si­sten­ti di tipo CephFS. Questo tipo di PV è uti­liz­za­to per ap­pli­ca­zio­ni che ri­chie­do­no l’accesso a file condivisi e operano in un ambiente di ar­chi­via­zio­ne di­stri­bui­to, come nel caso di Ceph.
• fc (Fibre Channel): i volumi per­si­sten­ti basati su FC sono collegati a di­spo­si­ti­vi di ar­chi­via­zio­ne Fibre Channel. Questo tipo permette di accedere a soluzioni di ar­chi­via­zio­ne esterne basate su Fibre Channel. È comune negli ambienti in cui sono uti­liz­za­te reti Fibre Channel per fornire un’ar­chi­via­zio­ne a blocchi.
• rbd (RADOS Block Device): il tipo RBD si collega ai di­spo­si­ti­vi di ar­chi­via­zio­ne a blocchi nel cluster Ceph che operano come di­spo­si­ti­vi a blocchi RADOS. Questo tipo ti permette di accedere al sistema di ar­chi­via­zio­ne a blocchi di Ceph e di sfrut­tar­ne i par­ti­co­la­ri vantaggi negli ambienti di ar­chi­via­zio­ne di­stri­bui­ti con elevata sca­la­bi­li­tà.

Modalità di accesso ai volumi per­si­sten­ti in Ku­ber­ne­tes

In Ku­ber­ne­tes, le modalità di accesso ai volumi per­si­sten­ti de­ter­mi­na­no il modo in cui i pod possono accedere ai volumi per­si­sten­ti a essi associati. Esistono tre tipi di modalità di accesso prin­ci­pa­li:

• ReadWriteOnce (RWO): questa modalità consente a un singolo pod di montare il volume per­si­sten­te in modalità di lettura e scrittura con­tem­po­ra­nea­men­te. È utile per quelle ap­pli­ca­zio­ni che ri­chie­do­no 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 si­mul­ta­nea­men­te il volume per­si­sten­te in modalità di sola lettura. È utile per quelle ap­pli­ca­zio­ni che possono con­di­vi­de­re 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 per­si­sten­te sia in modalità di accesso in lettura che in scrittura, con­tem­po­ra­nea­men­te. Questa modalità è uti­liz­za­ta in si­tua­zio­ni 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 con­si­de­ra­re il tipo di accesso ai dati uti­liz­za­to dall’ap­pli­ca­zio­ne e ve­ri­fi­ca­re che la modalità se­le­zio­na­ta supporti i modelli di accesso richiesti.

Ricorda che non tutti i tipi di volume e le classi di ar­chi­via­zio­ne sup­por­ta­no tutte e tre le modalità di accesso. Il supporto dipende dall’in­fra­strut­tu­ra di ar­chi­via­zio­ne sot­to­stan­te e dallo specifico tipo di volume per­si­sten­te. Pertanto, è con­si­glia­bi­le con­sul­ta­re la do­cu­men­ta­zio­ne della classe di ar­chi­via­zio­ne e del tipo di volume per­si­sten­te in­te­res­sa­ti per as­si­cu­rar­si che i modelli di accesso de­si­de­ra­ti siano con­sen­ti­ti.

Ciclo di vita di un volume per­si­sten­te (PV)

I cicli di vita dei volumi per­si­sten­ti di Ku­ber­ne­tes possono essere suddivisi in diverse fasi che rap­pre­sen­ta­no il processo di messa a di­spo­si­zio­ne, utilizzo e sblocco dell’ar­chi­via­zio­ne per­si­sten­te nel cluster.

1. Creazione (pro­vi­sio­ning): il ciclo di vita di un PV inizia con la creazione o il pro­vi­sio­ning. Un am­mi­ni­stra­to­re del cluster crea un volume per­si­sten­te e lo configura in modo statico con risorse di ar­chi­via­zio­ne fisse oppure in modo dinamico per mezzo di una classe di ar­chi­via­zio­ne che consenta il pro­vi­sio­ning dinamico.
2. As­so­cia­zio­ne (binding): un PV viene legato a una PVC (Per­si­stent Volume Claim) quando un pod dichiara un requisito di ar­chi­via­zio­ne che cor­ri­spon­de alle spe­ci­fi­che del PV. Questo passaggio ga­ran­ti­sce che il PV soddisfi i requisiti di un pod specifico.
3. Utilizzo da parte del pod: una volta com­ple­ta­to il processo di as­so­cia­zio­ne, il PV può essere uti­liz­za­to da un pod. Il pod può eseguire ope­ra­zio­ni di lettura o scrittura sul volume montato, a seconda delle modalità di accesso spe­ci­fi­ca­te durante la creazione del PV.
4. Con­clu­sio­ne dell’utilizzo: quando un pod termina il suo servizio o viene eliminato, il relativo PV può essere riu­ti­liz­za­to da un altro pod. Il PV viene con­ser­va­to finché non viene eliminato ma­nual­men­te o da una classe di ar­chi­via­zio­ne dinamica.
5. Sblocco (release): un PV può essere sbloccato espli­ci­ta­men­te se­pa­ran­do­lo da una PVC. In questo modo è possibile legare nuo­va­men­te il PV, even­tual­men­te a un’altra PVC o a un altro pod.
6. Eli­mi­na­zio­ne: infine puoi anche eliminare un PV se non è più ne­ces­sa­rio. Questa ope­ra­zio­ne può essere eseguita ma­nual­men­te o au­to­ma­ti­ca­men­te, se la replica del PV è impostata nella classe di ar­chi­via­zio­ne.

Creazione di un volume per­si­sten­te in Ku­ber­ne­tes

La creazione di un volume per­si­sten­te in Ku­ber­ne­tes è un processo in più fasi che richiede un’attenta con­fi­gu­ra­zio­ne.

Primo passaggio: con­fi­gu­ra­zio­ne del volume per­si­sten­te

Il primo passaggio consiste nell’aprire un editor di testo e creare un file YAML con­te­nen­te la con­fi­gu­ra­zio­ne del volume per­si­sten­te di Ku­ber­ne­tes. Ad esempio, puoi chiamare questo file pv.yaml. Nelle parti seguenti ti mostriamo un semplice esempio di con­fi­gu­ra­zio­ne 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 Ku­ber­ne­tes. In questo caso è la v1.
• kind: il tipo di oggetto Ku­ber­ne­tes, in questo caso Per­si­stent­Vo­lu­me.
• metadata: contiene metadati relativi al volume per­si­sten­te, come il nome del volume.
• spec: definisce le spe­ci­fi­che del volume.
• capacity: indica la capacità di ar­chi­via­zio­ne, in questo esempio 1 GB.
• volumeMode: indica la modalità per il volume, Filesystem oppure Block. In questo esempio uti­liz­zia­mo 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ù ne­ces­sa­rio. Retain significa che il volume deve essere eliminato ma­nual­men­te.
• storageClassName: assegna una classe di ar­chi­via­zio­ne al volume per­si­sten­te.
• hostPath: definisce il percorso nel file system host che verrà uti­liz­za­to come spazio di ar­chi­via­zio­ne per il volume per­si­sten­te.

Secondo passaggio: ap­pli­ca­zio­ne della con­fi­gu­ra­zio­ne

Dopo aver definito il file di con­fi­gu­ra­zio­ne PV, puoi attivarlo con Kubelet:

kubectl apply -f pv.yaml

Questo comando invia il file di con­fi­gu­ra­zio­ne al cluster Ku­ber­ne­tes, che crea le risorse al suo interno.

Terzo passaggio: ap­pli­ca­zio­ne della con­fi­gu­ra­zio­ne

Per as­si­cu­rar­ti che il volume per­si­sten­te di Ku­ber­ne­tes sia stato creato cor­ret­ta­men­te, puoi uti­liz­za­re il seguente comando:

kubectl get pv

Il comando elenca tutti i volumi per­si­sten­ti 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 Per­si­stent Volume Claim (PVC)

Compila un file YAML che spe­ci­fi­chi la con­fi­gu­ra­zio­ne della Per­si­stent Volume Claim:

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

Applica il file di con­fi­gu­ra­zio­ne PVC al cluster Ku­ber­ne­tes:

kubectl apply -f pvc.yaml

Verifica che la Per­si­stent Volume Claim sia stata creata cor­ret­ta­men­te 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 pro­vi­sio­ning dinamico di una Per­si­stent Volume Claim (PVC) in Ku­ber­ne­tes. Il manifest crea e richiede au­to­ma­ti­ca­men­te un nuovo volume per­si­sten­te da 1 gigabyte in Ku­ber­ne­tes, che è sup­por­ta­to dalla classe di ar­chi­via­zio­ne standard.

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

Dopo aver definito le con­fi­gu­ra­zio­ni, attiviamo il manifest:

kubectl apply -f pvc-dynamic.yaml

Quinto passaggio: col­le­ga­men­to delle PVC con i pod

Per rea­liz­za­re un’as­so­cia­zio­ne fra PVC e pod, è ne­ces­sa­rio impostare la con­fi­gu­ra­zio­ne per il pod che uti­liz­ze­rà l’ar­chi­via­zio­ne per­si­sten­te.

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 con­fi­gu­ra­zio­ne del pod al cluster Ku­ber­ne­tes per creare il pod:

kubectl apply -f pod.yaml

Se hai appena iniziato a uti­liz­za­re Ku­ber­ne­tes, troverai tutte le in­for­ma­zio­ni più im­por­tan­ti su in­stal­la­zio­ne e con­fi­gu­ra­zio­ne di un cluster nel tutorial di Ku­ber­ne­tes della nostra guida.