Provisioning e volumi permanenti GKE

Questa pagina fornisce una panoramica di Persistent Volumes (PV), Persistent Volume Claims (PVC) e StorageClass 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 per garantire la sicurezza dei dati, l'alta affidabilità e prestazioni ottimali.

Questa pagina è dedicata agli specialisti di Storage che creano e allocano 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, un PersistentVolume è in genere supportato da un disco permanente.

Puoi invece utilizzare altre soluzioni di archiviazione come NFS. Filestore è una soluzione NFS su Google 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. Il provisioning delle risorse PersistentVolume può essere eseguito dinamicamente tramite PersistentVolumeClaims oppure le risorse possono essere 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 dell'API Persistent Volumes.

Gli oggetti PersistentVolumeClaim

Un PersistentVolumeClaim è una richiesta e una rivendicazione di una risorsa PersistentVolume. Gli oggetti PersistentVolumeClaim richiedono dimensioni, modalità di accesso e StorageClass specifici per PersistentVolume. Se esiste o può essere eseguito 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 diversi cluster e ambienti perché PersistentVolume è un'interfaccia per l'archiviazione di backend effettiva.

StorageClasses

Le implementazioni dei volumi, come il driver Container Storage Interface (CSI) per il 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 uno di tua scelta. Per istruzioni, consulta Modifica la classe StorageClass predefinita.

Puoi creare risorse StorageClass personalizzate per descrivere diverse classi di spazio di archiviazione. Ad esempio, le classi potrebbero essere mappate ai livelli di qualità del servizio o alle policy di backup. Questo concetto viene a volte 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é fstype predefinito (ext4) non è supportato da Windows. Se utilizzi un disco permanente Compute Engine, devi utilizzare NTFS come tipo di archiviazione file.

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

Eseguire il provisioning dinamico di PersistentVolume

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

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 binding del volume WaitForFirstConsumer, PersistentVolume non verrà creato finché non viene pianificato un pod per utilizzare il volume.

L'esempio seguente mostra la risorsa PersistentVolume creata.

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 Compute Engine vuoto.

Elimina l'archiviazione permanente

Durante il provisioning dinamico, puoi controllare se l'archiviazione permanente viene eliminata quando viene eliminata una 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 questo criterio per i carichi di lavoro temporanei o per i requisiti di conformità in cui i dati devono essere puliti al termine di un job.

  • reclaimPolicy: Retain: se imposti questo criterio, 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 un nuovo PVC finché un amministratore non lo rivendica 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 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 su Recupero di un PersistentVolume.

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

Risoluzione dei problemi relativi all'eliminazione imprevista del disco

Se noti che i 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 StorageClass del tuo PVC: bash kubectl get pvc <your-pvc-name> -o jsonpath='{.spec.storageClassName}'

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

  3. Allinea la policy al tuo intento:

    • Se il criterio è Delete e la tua applicazione richiede la persistenza dei dati, devi aggiornarla in modo che utilizzi una configurazione StorageClass che imposta il criterio 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.

Gestire 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 il criterio Delete. In alternativa, puoi eliminare le 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 molti 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 Persistent Disk di Compute Engine supportano anche la modalità ReadOnlyMany, in modo che molte applicazioni o molte repliche della stessa applicazione possano utilizzare lo stesso disco contemporaneamente. Un caso d'uso di esempio è la pubblicazione di contenuti statici su più repliche.

Per istruzioni, consulta Utilizzare Persistent Disk con più lettori.

Utilizzare Persistent Disk preesistenti come PersistentVolume

Le risorse PersistentVolume con provisioning dinamico sono vuote quando vengono create. Se hai un disco permanente Compute Engine esistente popolato 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 PersistentVolume supportato da un Persistent Disk preesistente.

Deployment e StatefulSet

Puoi utilizzare i modelli PersistentVolumeClaim o VolumeClaim nei 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, in questa impostazione possono funzionare solo i volumi con la modalità ReadWriteMany.

Non sono consigliati nemmeno i deployment con una replica che utilizza il volume ReadWriteOnce. 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 un 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 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 non sono più pianificabili, Kubernetes può eseguire il failover dei carichi di lavoro utilizzando il volume nell'altra zona. Con i dischi permanenti a livello di regione puoi creare soluzioni ad alta disponibilità per i carichi di lavoro stateful in GKE. Devi assicurarti che sia la zona principale sia quella di failover siano configurate con una capacità di 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 maggiori dettagli, vedi Confronto delle prestazioni dell'archiviazione a blocchi.

Come per i dischi permanenti a livello di zona, i dischi permanenti a livello di regione possono essere sottoposti a provisioning dinamico in base alle necessità o a provisioning manuale in anticipo dall'amministratore del cluster. Per scoprire come aggiungere dischi permanenti a livello di regione, vedi 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 spazio di 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 Persistent Disk preesistenti, utilizza metodi di posizionamento zonale come nodeAffinity nelle specifiche di pod o specifica 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 su 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à nelle zone consente di distribuire i pod StatefulSet tra le zone insieme ai dischi corrispondenti.

Di seguito è riportato un esempio di StorageClass per il provisioning dei 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