Una Guida Semplice per Implementare lo Storage Persistente in Kubernetes

Lo storage persistente in Kubernetes risolve un problema semplice: il tuo contenitore può scomparire, ma i tuoi file di database, upload o dati di coda non possono. I Pod stateless possono essere sostituiti in qualsiasi momento. Le app stateful necessitano di storage che sopravviva a riavvii dei Pod, riprogrammazioni e manutenzione dei nodi.

Questa guida spiega i PersistentVolume (PV), i PersistentVolumeClaim (PVC), le modalità di accesso e le StorageClass con esempi pratici in YAML che puoi adattare per un carico di lavoro reale.

Comprendere i PersistentVolume (PV) e i PersistentVolumeClaim (PVC)

Prima di montare lo storage in un Pod, sappi quale oggetto gestisce quale compito:

• PersistentVolume (PV): Un PV è un pezzo di storage nel cluster che è stato provisionato da un amministratore o provisionato dinamicamente utilizzando StorageClass. I PV sono risorse del cluster, proprio come i Nodi. Hanno un ciclo di vita indipendente da qualsiasi Pod che utilizza il PV. I PV astraggono i dettagli di implementazione dello storage sottostante (ad es., NFS, iSCSI, storage a blocchi del provider cloud).
• PersistentVolumeClaim (PVC): Un PVC è una richiesta di storage da parte di un utente. Consuma risorse di storage disponibili nel cluster come PV. I PVC sono simili ai Pod in quanto consumano risorse di calcolo e sono limitati a un namespace. Un PVC specifica la capacità di storage desiderata, le modalità di accesso e, opzionalmente, una StorageClass.

Questa separazione consente ai team di piattaforma di gestire i dettagli dello storage mentre i team applicativi richiedono la capacità e il modello di accesso di cui hanno bisogno.

Concetti Chiave: Modalità di Accesso e StorageClass

Due impostazioni controllano la maggior parte del comportamento dei PVC: come il volume può essere montato e quale backend di storage dovrebbe crearlo.

Modalità di Accesso

Le modalità di accesso definiscono come un volume può essere montato su un Pod. Le modalità di accesso disponibili sono:

• ReadWriteOnce (RWO): Il volume può essere montato in lettura-scrittura da un singolo nodo.
• ReadOnlyMany (ROX): Il volume può essere montato in sola lettura da molti nodi.
• ReadWriteMany (RWX): Il volume può essere montato in lettura-scrittura da molti nodi.
• ReadWriteOncePod (RWOP): Il volume può essere montato in lettura-scrittura da un singolo Pod. È utile quando hai bisogno di un comportamento di scrittura singola più rigoroso e il tuo driver CSI lo supporta.

È importante notare che il supporto effettivo per queste modalità dipende dal provider di storage sottostante.

StorageClass

Una StorageClass fornisce un modo per gli amministratori di descrivere le "classi" di storage che offrono. Classi diverse possono corrispondere a livelli di qualità del servizio, politiche di backup o politiche arbitrarie determinate dagli amministratori del cluster. Una StorageClass ha un provisioner che provisiona lo storage e un insieme di parametri per il provisioner. Quando viene creato un PVC senza un PV specifico e richiede una StorageClass, Kubernetes provisionerà dinamicamente un PV utilizzando la StorageClass specificata.

Implementare lo Storage Persistente Passo dopo Passo

Esaminiamo uno scenario comune: richiedere e utilizzare lo storage persistente per un Pod.

Passo 1: Definire un PersistentVolumeClaim (PVC)

Prima di tutto, devi creare un PVC che specifichi i tuoi requisiti di storage. Questo PVC fungerà da richiesta di storage per la tua applicazione.

Esempio pvc.yaml:

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

In questo esempio:

• name: my-pvc: Questo è il nome del nostro PVC.
• accessModes: - ReadWriteOnce: Stiamo richiedendo storage che può essere montato in lettura-scrittura da un singolo nodo.
• resources.requests.storage: 1Gi: Stiamo richiedendo 1 Gigabyte di storage.

Applicare il PVC:

Salva il contenuto sopra in un file chiamato pvc.yaml e applicalo al tuo cluster:

kubectl apply -f pvc.yaml

Dopo l'applicazione, puoi controllare lo stato del PVC:

kubectl get pvc my-pvc

Dovresti vedere un output che indica che il PVC è Bound se un PV adatto è disponibile o è stato provisionato dinamicamente.

Passo 2: Creare un Pod che Utilizza il PVC

Ora, creiamo un Pod che utilizzerà lo storage richiesto dal nostro PVC. Monteremo il volume fornito dal PVC in una directory specifica all'interno del nostro contenitore.

Esempio pod-with-pv.yaml:

apiVersion: v1
kind: Pod
metadata:
  name: my-stateful-pod
spec:
  containers:
    - name: my-container
      image: nginx
      ports:
        - containerPort: 80
      volumeMounts:
        - name: my-persistent-storage
          mountPath: /usr/share/nginx/html
  volumes:
    - name: my-persistent-storage
      persistentVolumeClaim:
        claimName: my-pvc

In questo esempio:

• volumes: Definiamo un volume chiamato my-persistent-storage.
• persistentVolumeClaim.claimName: my-pvc: Questo collega il nostro volume al PVC che abbiamo creato in precedenza.
• volumeMounts: All'interno della definizione del contenitore, specifichiamo dove questo volume deve essere montato (mountPath: /usr/share/nginx/html).

Applicare il Pod:

Salva il contenuto sopra in un file chiamato pod-with-pv.yaml e applicalo:

kubectl apply -f pod-with-pv.yaml

Ora, il tuo contenitore nginx avrà accesso allo storage persistente definito da my-pvc al percorso /usr/share/nginx/html. Qualsiasi dato scritto in questo percorso all'interno del contenitore sarà persistito anche se il Pod viene eliminato e ricreato, purché il PVC e il suo PV sottostante rimangano.

Provisioning Dinamico con StorageClass

Creare manualmente i PV può essere macchinoso. Kubernetes offre il provisioning dinamico, dove i PV vengono creati automaticamente quando un PVC richiede storage che non può essere soddisfatto dai PV esistenti. Questo si ottiene tramite StorageClass.

La maggior parte dei provider cloud (AWS, GCP, Azure) offre StorageClass preconfigurate. Puoi ispezionarle con:

kubectl get storageclass

Per utilizzare il provisioning dinamico, aggiungi semplicemente un campo storageClassName alla definizione del tuo PVC:

Esempio pvc-dynamic.yaml:

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-dynamic-pvc
spec:
  storageClassName: standard # Sostituisci 'standard' con un nome di StorageClass effettivo
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi

Quando applichi questo PVC, Kubernetes cercherà una StorageClass chiamata standard (o qualsiasi nome tu specifichi) e istruirà il suo provisioner a creare un nuovo PV di 5Gi e a legarlo a questo PVC.

Suggerimenti e Buone Pratiche

• Scegli la Modalità di Accesso Giusta: Considera attentamente la modalità di accesso richiesta dalla tua applicazione. ReadWriteOnce è comune per database a replica singola, mentre ReadWriteMany è necessario per file system condivisi utilizzati da più Pod.
• Comprendi le Prestazioni dello Storage: Diversi provider di storage e StorageClass offrono caratteristiche di prestazioni variabili (IOPS, throughput). Scegli una StorageClass che soddisfi le esigenze di prestazioni della tua applicazione.
• Strategia di Backup: Lo storage persistente non significa automaticamente backup. Implementa una strategia di backup robusta per i tuoi volumi persistenti, specialmente per i dati critici.
• Politica di Recupero dei PV: I PV hanno una persistentVolumeReclaimPolicy, comunemente Delete o Retain. I volumi provisionati dinamicamente spesso utilizzano la politica di recupero definita dalla loro StorageClass. La vecchia politica Recycle è deprecata e non dovrebbe essere utilizzata per nuove configurazioni.
• Considerazioni sui Namespace: I PVC sono limitati ai namespace. Assicurati che il tuo Pod e il PVC siano nello stesso namespace affinché avvenga il binding.

Conclusione

Lo storage persistente in Kubernetes inizia con un PVC, un mount del Pod e una StorageClass che corrisponde al tuo carico di lavoro. Per un database a replica singola, inizia con una richiesta ReadWriteOnce, verifica che raggiunga lo stato Bound, montala nel contenitore e rendi i backup parte del progetto fin dal primo giorno.