Volumi permanenti e provisioning dinamico 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 sull'archiviazione supportata dai dischi permanenti di Compute Engine.

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

Questa pagina è dedicata agli specialisti di archiviazione 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 di GKE Enterprise.

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 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 cluster GKE, consulta Accedere 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 scoprire 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 una dimensione, una modalità di accesso e un 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 facilmente 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 risorse StorageClass.

GKE crea un StorageClass predefinito che utilizza il tipo di disco permanente bilanciato (ext4). Il StorageClass predefinito viene utilizzato quando un PersistentVolumeClaim non specifica un StorageClassName. Puoi sostituire il valore predefinito StorageClass fornito con uno di tua scelta. Per istruzioni, vedi Modificare la StorageClass predefinita.

Puoi creare risorse StorageClass personalizzate per descrivere diverse classi di spazio di archiviazione. Ad esempio, le classi possono essere mappate ai livelli di qualità del servizio o ai criteri 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 di file system (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 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. Viene inoltre creato 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 il 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.

Eliminazione dell'archiviazione permanente

Per impostazione predefinita, l'eliminazione di un PersistentVolumeClaim per i volumi di cui è stato eseguito il provisioning dinamico, come i dischi permanenti di Compute Engine, elimina sia l'oggetto PersistentVolume sia il disco di backup effettivo. Questo comportamento è controllato dalla policy di recupero in StorageClass e PersistentVolume, che può essere impostata sul valore predefinito Delete o Retain. Per saperne di più, consulta la documentazione di Kubernetes sul recupero.

Per prevenire o mitigare la perdita di dati quando elimini l'archiviazione permanente, ti consigliamo di attivare Backup per GKE e pianificare backup regolari del cluster GKE, inclusi i workload di cui è stato eseguito il deployment e i relativi dati.

Gestire l'archiviazione permanente durante l'eliminazione del cluster

Quando un cluster GKE viene eliminato, GKE conserva le risorse PersistentVolume con i criteri 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, 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 dischi permanenti e funziona come modalità di accesso predefinita per la maggior parte delle applicazioni. I dischi permanenti 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 dischi permanenti con più lettori.

Utilizzare dischi permanenti 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 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 Persistent Volume supportato da un disco permanente 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 applicazioni stateless, quindi 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 interrompere il primo pod durante una ricreazione. Il deployment potrebbe non riuscire a causa di un deadlock perché 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 StatefulSet con i modelli PersistentVolumeClaim, puoi avere applicazioni che possono essere scalate automaticamente con PersistentVolumeClaim univoci associati a ogni pod replica.

Dischi permanenti a livello di regione

I dischi permanenti 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 dischi permanenti 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 regionali sono un'opzione per applicazioni come i database che richiedono sia alta disponibilità che prestazioni elevate. Per maggiori dettagli, vedi Blocco del confronto delle prestazioni di archiviazione.

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 da parte dell'amministratore del cluster. Per scoprire come aggiungere dischi permanenti a livello di regione, consulta la sezione Provisioning dei dischi permanenti a livello di regione.

Zone nei dischi permanenti

I dischi permanenti a livello di zona sono risorse a livello di zona e i dischi permanenti regionali 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 dischi permanenti preesistenti. Per assicurarti che i pod vengano pianificati correttamente con dischi permanenti preesistenti, utilizza metodi di posizionamento zonale come nodeAffinity nelle specifiche di pod o 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 WaitForFirstConsumer modalità di binding del volume in 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.

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