Volumi permanenti e provisioning di GKE

Questa pagina fornisce una panoramica dei volumi permanenti (PV), delle richieste di volumi permanenti (PVC) e delle classi di archiviazione in Google Kubernetes Engine (GKE). Si concentra sullo spazio di archiviazione supportato dai dischi permanenti di Compute Engine.

Imparerai a creare, gestire e risolvere i problemi relativi all'archiviazione permanente all'interno dei tuoi cluster GKE in modo efficace per garantire la sicurezza dei dati, l'alta affidabilità e prestazioni ottimali.

Questa pagina è rivolta agli esperti di archiviazione che creano e allocano lo spazio di archiviazione e configurano e gestiscono la sicurezza, la protezione, l'accesso e le autorizzazioni dei dati. Per scoprire di più sui ruoli comuni e sulle attività di esempio a cui facciamo riferimento nei contenuti diGoogle Cloud , consulta Ruoli e attività comuni degli utenti GKE.

PersistentVolume

Le risorse PersistentVolume vengono usate per gestire l'archiviazione durevole in un cluster. In GKE, di norma, un PersistentVolume è supportato da un disco permanente.

In alternativa, puoi utilizzare altre soluzioni di archiviazione come NFS. Filestore è una soluzione NFS suGoogle Cloud. Per scoprire come configurare un'istanza Filestore come soluzione PV NFS per i tuoi cluster GKE, consulta Accedi alle istanze Filestore con il driver CSI Filestore nella documentazione di Filestore.

Il ciclo di vita di PersistentVolume è gestito da Kubernetes. Un PersistentVolume può essere sottoposto a provisioning dinamico; non è necessario creare ed eliminare manualmente lo spazio di archiviazione di supporto.

Le risorse PersistentVolume sono risorse del cluster che esistono indipendentemente dai pod. Ciò significa che il disco e i dati rappresentati da un PersistentVolume continuano a esistere quando cambia il cluster e quando vengono eliminati e ricreati i pod. Le risorse PersistentVolume possono essere sottoposte a provisioning dinamico tramite PersistentVolumeClaims o create in modo esplicito da un amministratore del cluster.

Per saperne di più sulle risorse PersistentVolume, consulta la documentazione sui volumi permanenti di Kubernetes e il riferimento API dei volumi permanenti.

Gli oggetti PersistentVolumeClaim

Un PersistentVolumeClaim è una richiesta e una rivendicazione di una risorsa PersistentVolume. Gli oggetti PersistentVolumeClaim richiedono dimensioni, modalità di accesso e StorageClass specifiche per PersistentVolume. Se esiste o è possibile eseguire il provisioning di un PersistentVolume che soddisfa la richiesta, il PersistentVolumeClaim viene associato a quel PersistentVolume.

I pod utilizzano le richieste come volumi. Il cluster esamina la richiesta per trovare il volume associato e lo monta per il pod.

La portabilità è un altro vantaggio dell'utilizzo di PersistentVolumes e PersistentVolumeClaims. Puoi utilizzare la stessa specifica del pod in cluster e ambienti diversi perché PersistentVolume è un'interfaccia per lo spazio di archiviazione di supporto effettivo.

StorageClasses

Le implementazioni dei volumi, come il driver CSI (Container Storage Interface) per i disco permanente di Compute Engine, vengono configurate tramite le risorse StorageClass.

GKE crea un StorageClass predefinito che utilizza il tipo di disco permanente bilanciato (ext4). Il valore predefinito StorageClass viene utilizzato quando un PersistentVolumeClaim non specifica un StorageClassName. Puoi sostituire il valore predefinito StorageClass fornito con il tuo. Per istruzioni, consulta Modifica la classe StorageClass predefinita.

Puoi creare le tue risorse StorageClass per descrivere diverse classi di archiviazione. Ad esempio, le classi potrebbero essere mappate ai livelli di qualità del servizio o alle policy di backup. Questo concetto è talvolta chiamato "profili" in altri sistemi di archiviazione.

Se utilizzi un cluster con node pool Windows, devi creare un StorageClass e specificare un StorageClassName in PersistentVolumeClaim perché il tipo fstype predefinito (ext4) non è supportato con Windows. Se utilizzi un disco permanente di Compute Engine, devi utilizzare NTFS come tipo di archiviazione dei file.

Quando definisci un StorageClass, devi elencare un provisioner. Su GKE, ti consigliamo di utilizzare uno dei seguenti provisioner:

Esegui il provisioning dinamico dei PersistentVolume

Nella maggior parte dei casi non è necessario configurare direttamente oggetti PersistentVolume o creare dischi permanenti di Compute Engine. È invece possibile creare una PersistentVolumeClaim e Kubernetes eseguirà automaticamente il provisioning di un disco permanente.

Il seguente manifest descrive una richiesta per un disco con 30 gibibyte (GiB) di spazio di archiviazione la cui modalità di accesso consente di montarlo in modalità di lettura e scrittura da un singolo nodo. Crea anche un pod che utilizza PersistentVolumeClaim come volume.

# pvc-pod-demo.yaml
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-demo
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 30Gi
  storageClassName: standard-rwo
---
kind: Pod
apiVersion: v1
metadata:
  name: pod-demo
spec:
  volumes:
    - name: pvc-demo-vol
      persistentVolumeClaim:
       claimName: pvc-demo
  containers:
    - name: pod-demo
      image: nginx
      resources:
        limits:
          cpu: 10m
          memory: 80Mi
        requests:
          cpu: 10m
          memory: 80Mi
      ports:
        - containerPort: 80
          name: "http-server"
      volumeMounts:
        - mountPath: "/usr/share/nginx/html"
          name: pvc-demo-vol

Quando crei questo oggetto PersistentVolumeClaim con kubectl apply -f pvc-pod-demo.yaml, Kubernetes crea dinamicamente un oggetto PersistentVolume corrispondente.

Poiché la classe di archiviazione standard-rwo utilizza la modalità di associazione del volume WaitForFirstConsumer, PersistentVolume non verrà creato finché non viene pianificato un pod per l'utilizzo del volume.

L'esempio seguente mostra l'oggetto PersistentVolume creato.

apiVersion: v1
kind: PersistentVolume
metadata:
  annotations:
    pv.kubernetes.io/provisioned-by: pd.csi.storage.gke.io
  finalizers:
  - kubernetes.io/pv-protection
  - external-attacher/pd-csi-storage-gke-io
  name: pvc-c9a44c07-cffa-4cd8-b92b-15bac9a9b984
  uid: d52af557-edf5-4f96-8e89-42a3008209e6
spec:
  accessModes:
  - ReadWriteOnce
  capacity:
    storage: 30Gi
  claimRef:
    apiVersion: v1
    kind: PersistentVolumeClaim
    name: pvc-demo
    namespace: default
    uid: c9a44c07-cffa-4cd8-b92b-15bac9a9b984
  csi:
    driver: pd.csi.storage.gke.io
    csi.storage.k8s.io/fstype: ext4
    volumeAttributes:
      storage.kubernetes.io/csiProvisionerIdentity: 1660085000920-8081-pd.csi.storage.gke.io
    volumeHandle: projects/xxx/zones/us-central1-c/disks/pvc-c9a44c07-cffa-4cd8-b92b-15bac9a9b984
  nodeAffinity:
    required:
      nodeSelectorTerms:
      - matchExpressions:
        - key: topology.gke.io/zone
          operator: In
          values:
          - us-central1-c
  persistentVolumeReclaimPolicy: Delete
  storageClassName: standard-rwo
  volumeMode: Filesystem
status:
  phase: Bound

Supponendo che tu non abbia sostituito la classe di archiviazione standard-rwo, questo PersistentVolume è supportato da un nuovo disco permanente di Compute Engine vuoto.

Elimina archiviazione permanente

Durante il provisioning dinamico, puoi controllare se l'archiviazione permanente viene eliminata quando viene eliminato un PersistentVolumeClaim (PVC). Per farlo, imposta il campo reclaimPolicy nella configurazione StorageClass su Delete o Retain.

  • reclaimPolicy: Delete: questa è la policy predefinita. Quando la PVC viene eliminata, l'oggetto PersistentVolume (PV) e il disco sottostante (ad esempio un disco permanente di Compute Engine) vengono eliminati automaticamente. Utilizza questa policy per i workload temporanei o per i requisiti di conformità in cui i dati devono essere eliminati dopo il completamento di un job.

  • reclaimPolicy: Retain: se imposti questa policy, il PV e il disco sottostante non vengono eliminati quando elimini la PVC. Lo stato del PV diventa Released. I dati vengono conservati, ma il volume non può essere utilizzato da una nuova PVC finché un amministratore non lo recupera manualmente.

Gestione manuale dei volumi conservati

Quando un PersistentVolume ha lo stato Released, devi decidere manualmente cosa fare con i dati e il disco sottostanti.

  • Per eliminare definitivamente lo spazio di archiviazione: devi eliminare sia la risorsa Kubernetes PersistentVolume sia il disco di Compute Engine sottostante.

    1. Elimina PersistentVolume: bash kubectl delete pv <your-pv-name>
    2. Trova il nome del disco sottostante descrivendo il file di configurazione YAML per il PV e cercando il campo volumeHandle o un campo simile.
    3. Elimina il disco permanente di Compute Engine: bash gcloud compute disks delete <your-disk-name> --zone=<your-zone>

  • Per riutilizzare il volume: il recupero di un volume con stato Released per l'utilizzo da parte di un'altra PVC è un'attività avanzata che prevede la pulizia manuale dei dati del disco e la modifica dell'oggetto PersistentVolume per renderlo nuovamente Available. Per ulteriori informazioni sulla procedura dettagliata, consulta la documentazione ufficiale di Kubernetes sul recupero di un PersistentVolume.

Per prevenire o mitigare la perdita di dati, ti consigliamo anche di attivare Backup per GKE e di pianificare backup regolari del tuo cluster GKE.

Risoluzione dei problemi relativi all'eliminazione imprevista dei dischi

Se noti che i tuoi Persistent Disk sottostanti vengono eliminati quando non te lo aspetti, la causa più comune è un campo reclaimPolicy impostato su Delete nella configurazione StorageClass utilizzata dal tuo PersistentVolumeClaim.

Per diagnosticare il problema, completa i seguenti passaggi:

  1. Controlla il StorageClass della tua PVC: bash kubectl get pvc <your-pvc-name> -o jsonpath='{.spec.storageClassName}'

  2. Esamina il campo reclaimPolicy: bash kubectl get sc <your-storageclass-name> -o yaml

  3. Allinea la policy al tuo intento:

    • Se la policy è Delete e la tua applicazione richiede la persistenza dei dati, devi aggiornare l'applicazione in modo che utilizzi una configurazione StorageClass che imposti la policy su Retain.
    • Se la policy è Delete e la tua applicazione è temporanea o soggetta a regole di conformità che richiedono la pulizia dei dati, la configurazione è corretta e funziona come previsto.

Per saperne di più, consulta la documentazione di Kubernetes sul recupero.

Gestisci l'archiviazione permanente durante l'eliminazione del cluster

Quando un cluster GKE viene eliminato, GKE conserva le risorse PersistentVolume con la policy di recupero Delete o Retain.

Per rimuovere le risorse PersistentVolume quando elimini un cluster, puoi eliminare manualmente lo spazio dei nomi delle risorse PersistentVolumeClaim, il che attiverà l'eliminazione degli oggetti PersistentVolume con la policy Delete. In alternativa, puoi eliminare singole risorse PersistentVolumeClaim. Tuttavia, GKE non attende il completamento di queste attività di eliminazione prima di iniziare a eliminare il cluster. Pertanto, se elimini uno spazio dei nomi e poi elimini immediatamente il cluster, le risorse PersistentVolume con policy Delete potrebbero non essere eliminate.

Dopo l'eliminazione del cluster, puoi visualizzare le risorse PersistentVolume rimanenti nella console Google Cloud .

Per visualizzare le risorse inutilizzate, ad esempio le risorse PersistentVolume inutilizzate, puoi visualizzare i suggerimenti per le risorse inattive.

Modalità di accesso

Le risorse PersistentVolume supportano le seguenti modalità di accesso:

  • ReadWriteOnce: il volume può essere montato in lettura/scrittura da un singolo nodo.
  • ReadOnlyMany: il volume può essere montato in sola lettura da più nodi.
  • ReadWriteMany: il volume può essere montato in lettura/scrittura da più nodi. Le risorse PersistentVolume supportate dai dischi permanenti di Compute Engine non supportano questa modalità di accesso.
  • ReadWriteOncePod: il volume può essere montato in lettura/scrittura solo da un singolo pod.

Utilizzo dei dischi permanenti di Compute Engine come ReadOnlyMany

ReadWriteOnce è il caso d'uso più comune per i Persistent Disk e funziona come modalità di accesso predefinita per la maggior parte delle applicazioni. I dischi permanenti di Compute Engine supportano anche la modalità ReadOnlyMany, in modo che più applicazioni o più repliche della stessa applicazione possano utilizzare lo stesso disco contemporaneamente. Un esempio di caso d'uso è la pubblicazione di contenuti statici su più repliche.

Per istruzioni, consulta Utilizza i Persistent Disk con più lettori.

Utilizza i dischi permanenti preesistenti come PersistentVolume

Le risorse PersistentVolume di cui viene eseguito il provisioning dinamico sono vuote quando vengono create. Se hai un disco permanente di Compute Engine esistente con dati, puoi introdurlo nel tuo cluster creando manualmente una risorsa PersistentVolume corrispondente. Il disco permanente deve trovarsi nella stessa zona dei nodi del cluster.

Consulta questo esempio di come creare un volume permanente supportato da un Persistent Disk preesistente.

Deployment e StatefulSet

Puoi utilizzare un template PersistentVolumeClaim o VolumeClaim in controller di livello superiore come Deployment o StatefulSets rispettivamente.

I deployment sono progettati per le applicazioni stateless, pertanto tutte le repliche di un deployment condividono lo stesso PersistentVolumeClaim. Poiché i pod di replica creati sono identici tra loro, solo i volumi con la modalità ReadWriteMany possono funzionare in questa impostazione.

Anche i deployment con una replica che utilizza il volume ReadWriteOnce non sono consigliati. Questo perché la strategia di deployment predefinita crea un secondo pod prima di arrestare il primo pod durante una ricreazione. Il deployment potrebbe non riuscire in caso di deadlock, poiché il secondo pod non può avviarsi perché il volume ReadWriteOnce è già in uso e il primo pod non verrà rimosso perché il secondo pod non è ancora stato avviato. Utilizza invece un oggetto StatefulSet con volumi ReadWriteOnce.

Gli StatefulSet sono il metodo consigliato per il deployment di applicazioni stateful che richiedono un volume univoco per replica. Utilizzando gli StatefulSet con i template PersistentVolumeClaim, puoi avere applicazioni che possono fare lo scale up automaticamente con PersistentVolumeClaim univoci associati a ogni pod di replica.

Persistent Disk a livello di regione

I Persistent Disk a livello di regione sono risorse multizona che replicano i dati tra due zone nella stessa regione e possono essere utilizzati in modo simile ai Persistent Disk a livello di zona. In caso di interruzione del servizio a livello di zona o se i nodi del cluster in una zona diventano non pianificabili, Kubernetes può eseguire il failover dei workload utilizzando il volume nell'altra zona. Con i Persistent Disk a livello di regione puoi creare soluzioni ad alta affidabilità per i workload stateful in GKE. Devi assicurarti che sia la zona principale che quella di failover siano configurate con una capacità delle risorse sufficiente per eseguire il workload.

I dischi permanenti SSD a livello di regione sono un'opzione per applicazioni come i database che richiedono sia alta affidabilità che prestazioni elevate. Per ulteriori dettagli, consulta Confronto delle prestazioni dell'archiviazione a blocchi.

Come per i dischi permanenti a livello di zona, il provisioning dei dischi permanenti a livello di regione può essere eseguito dinamicamente in base alle esigenze o manualmente in anticipo dall'amministratore del cluster. Per scoprire come aggiungere dischi permanenti a livello di regione, consulta Provisioning di dischi permanenti a livello di regione.

Zone nei dischi permanenti

I Persistent Disk a livello di zona sono risorse di zona, mentre i Persistent Disk a livello di regione sono risorse multizona. Quando aggiungi l'archiviazione permanente al cluster, a meno che non venga specificata una zona, GKE assegna il disco a una singola zona. GKE sceglie la zona in modo casuale. Una volta eseguito il provisioning di un disco permanente, tutti i pod che fanno riferimento al disco vengono pianificati nella stessa zona del disco permanente. Tuttavia, i pod o i deployment non riconoscono intrinsecamente la zona dei Persistent Disk preesistenti. Per assicurarti che i pod vengano pianificati correttamente con i Persistent Disk preesistenti, utilizza i metodi di posizionamento a livello di zona come nodeAffinity nelle specifiche dei pod o delle specifiche del deployment per scegliere come target le zone appropriate.

Modalità di associazione del volume WaitForFirstConsumer

Se esegui il provisioning dinamico di un disco permanente nel cluster, ti consigliamo di impostare la modalità di associazione del volume WaitForFirstConsumer nella definizione di StorageClass. Questa impostazione indica a Kubernetes di eseguire il provisioning di un disco permanente nella stessa zona in cui è pianificato il pod. Rispetta i vincoli di pianificazione dei pod, come l'anti-affinità e i selettori dei nodi. L'anti-affinità sulle zone consente di distribuire i pod StatefulSet tra le zone insieme ai dischi corrispondenti. Inoltre, questa impostazione aiuta a mitigare i problemi quando una zona non dispone di capacità di computing, rimandando il provisioning dello spazio di archiviazione fino a quando non è possibile proteggere un nodo integro e disponibile. Questo provisioning differito aiuta a evitare che l'applicazione stateful venga bloccata in modo permanente in una zona con prestazioni ridotte, dove rimarrebbe bloccata in uno stato Pending.

Di seguito è riportato un esempio di definizione StorageClass per il provisioning di dischi permanenti a livello di zona che imposta WaitForFirstConsumer:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: slow
provisioner: pd.csi.storage.gke.io
parameters:
  type: pd-balanced
  csi.storage.k8s.io/fstype: ext4
volumeBindingMode: WaitForFirstConsumer

Per un esempio di utilizzo dei dischi permanenti a livello di regione, consulta Provisioning dei dischi permanenti a livello di regione.

Passaggi successivi