Persistent Volume e Persistent Volume Claim

I Pod nascono e terminano, ma spesso i dati dell'applicazione devono durare nel tempo. Pensi a un database o ai file caricati dagli utenti.

• Quando un Pod viene riavviato o ripianificato, tutti i dati memorizzati direttamente nel file system del container vanno persi.
• Questa natura effimera è adatta alle applicazioni stateless, ma i dati critici richiedono una soluzione duratura.
• Kubernetes offre un potente sistema per gestire lo storage persistente, che sopravvive al ciclo di vita dei Pod.

Un PersistentVolume (PV) è una risorsa di storage nel cluster Kubernetes.

• È una risorsa con ambito di cluster, cioè non appartiene ad alcun namespace specifico.
• I PV vengono forniti da un amministratore oppure dinamicamente da una StorageClass.
• Ast traggono i dettagli della tecnologia di storage sottostante, come Google Persistent Disk, AWS EBS o una condivisione NFS.

I PV vengono definiti specificando dettagli come capacità, modalità di accesso e tipo di storage. Questo YAML descrive un PV che utilizza hostPath (per i test locali) con 5 Gigabyte di storage.

apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-local-pv
spec:
  capacity:
    storage: 5Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  hostPath:
    path: "/mnt/data"

Nota: hostPath viene in genere utilizzato per lo sviluppo su un singolo nodo e non è consigliato in produzione.

Un PersistentVolumeClaim (PVC) è una richiesta di storage da parte di un utente o di un'applicazione all'interno di uno specifico namespace.

• I Pod non utilizzano direttamente i PV, ma richiedono lo storage tramite un PVC.
• I PVC hanno ambito di namespace, quindi risiedono nell'area di uno specifico progetto o team.
• Specificano la dimensione desiderata, le modalità di accesso e, facoltativamente, una classe di storage.

Kubernetes abbina automaticamente un PVC a un PV disponibile attraverso un processo chiamato binding.

• Quando viene creato un PVC, Kubernetes cerca un PV che soddisfi i requisiti del PVC (dimensione, modalità di accesso e classe di storage).
• Quando viene trovato un PV adatto, i due oggetti vengono "associati" in una relazione uno a uno.
• Questo binding garantisce che il PVC ottenga esattamente lo storage richiesto.

Le modalità di accesso definiscono come lo storage può essere montato e utilizzato dai Pod. Queste modalità vengono richieste dai PVC e supportate dai PV:

• ReadWriteOnce (RWO): il volume può essere montato in lettura e scrittura da un singolo nodo.
• ReadOnlyMany (ROX): il volume può essere montato in sola lettura da più nodi.
• ReadWriteMany (RWX): il volume può essere montato in lettura e scrittura da più nodi.

La disponibilità di queste modalità dipende dal provider di storage specifico.

Le Storage Classes consentono agli amministratori di descrivere diverse "classi" di storage, come "fast-ssd" e "slow-hdd".

• Invece di creare manualmente i PV, una StorageClass può effettuare il provisioning dinamico di un PV quando un PVC lo richiede.
• In questo modo automatizza la creazione dei PV sulla base di template predefiniti.
• Separa il provisioning dello storage dal suo utilizzo, semplificando il lavoro degli utenti.

Creiamo un PVC che richiede 1 Gigabyte di storage con accesso ReadWriteOnce. Questo PVC cercherà un PV esistente oppure attiverà il provisioning dinamico tramite una StorageClass.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-app-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
  storageClassName: standard # Optional: if you have a 'standard' StorageClass

Salvi questo contenuto come pvc.yaml e lo applichi con kubectl apply -f pvc.yaml.

Una volta associato un PVC, un Pod può utilizzarlo facendo riferimento al nome del PVC nella configurazione del volume. Il Pod non deve conoscere il PV sottostante, ma solo il PVC.

apiVersion: v1
kind: Pod
metadata:
  name: my-data-pod
spec:
  containers:
    - name: data-container
      image: busybox
      command: ["/bin/sh", "-c", "echo 'Hello from CoddyKit!' > /mnt/data/hello.txt && sleep 3600"]
      volumeMounts:
        - name: persistent-storage
          mountPath: /mnt/data
  volumes:
    - name: persistent-storage
      persistentVolumeClaim:
        claimName: my-app-pvc

Questo Pod scriverà un file nel volume persistente montato.

Può monitorare lo stato delle risorse di storage persistente utilizzando kubectl:

• Per visualizzare tutti i PV: kubectl get pv
• Per visualizzare tutti i PVC nel namespace: kubectl get pvc
• Per ottenere informazioni dettagliate, inclusi stato ed eventi:
• kubectl describe pv <pv-name>
• kubectl describe pvc <pvc-name>

Si assicuri che i PV siano Bound e che i PVC siano associati (Bound) al PV corretto.

Un utente vuole distribuire un database che necessita di 50 GB di storage persistente. Quale risorsa Kubernetes rappresenta direttamente la richiesta di questo storage da parte dell'applicazione dell'utente?

Abbiamo visto come Kubernetes gestisce lo storage duraturo per le applicazioni:

• I PersistentVolume (PV) sono risorse del cluster che rappresentano lo storage effettivo.
• I PersistentVolumeClaim (PVC) sono richieste di storage da parte degli utenti.
• Kubernetes associa i PVC ai PV adatti in base ai requisiti.
• Le modalità di accesso definiscono come può essere utilizzato lo storage (RWO, ROX, RWX).
• Le Storage Classes consentono il provisioning dinamico dei PV, automatizzando la configurazione.

Questo sistema garantisce la persistenza dei dati dell'applicazione anche quando i Pod vengono creati e terminati, offrendo affidabilità alle applicazioni stateful.