Volumi permanenti e provisioning dinamico

Questa pagina fornisce una panoramica dei volumi e dei claim permanenti in Kubernetes e del loro utilizzo con Google Kubernetes Engine (GKE). Questa pagina è incentrata sullo spazio di archiviazione supportato dai dischi permanenti Compute Engine.

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

PersistentVolume

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

In alternativa, 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 tuoi 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 messe in provisioning in modo dinamico tramite PersistentVolumeClaims o create esplicitamente da un amministratore del cluster.

Per saperne di più sulle risorse PersistentVolume, consulta la documentazione sui volumi permanenti di Kubernetes e il riferimento all'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 StorageClass specifici per il PersistentVolume. Se esiste o può essere eseguito il provisioning di un PersistentVolume che soddisfa la richiesta, il PersistentVolumeClaim è associato a quel PersistentVolume.

I pod utilizzano i claim come volumi. Il cluster ispeziona la richiesta per trovare il volume vincolato 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 cluster ed 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 StorageClass predefinito viene utilizzato quando un PersistentVolumeClaim non specifica un StorageClassName. Puoi sostituire il valore predefinito fornito StorageClass con uno di tua scelta. Per le istruzioni, vedi Modificare la classe di archiviazione predefinita.

Puoi creare le tue risorse StorageClass per descrivere diverse classi di archiviazione. Ad esempio, le classi potrebbero essere associate a livelli di qualità del servizio o a criteri di backup. Questo concetto è a volte chiamato "profili" in altri sistemi di archiviazione.

Se utilizzi un cluster con pool di nodi Windows, devi creare un StorageClass e specificare un StorageClassName in PersistentVolumeClaim perché il valore fstype predefinito (ext4) non è supportato con Windows. Se utilizzi un disco permanente 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 un PersistentVolumeClaim e Kubernetes eseguirà automaticamente il provisioning di un disco permanente.

Il manifest seguente descrive una richiesta di 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 anche 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 associazione del volume WaitForFirstConsumer, PersistentVolume non verrà creato finché non viene pianificato un pod per consumare 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, PersistentVolume è supportato da un nuovo disco permanente Compute Engine vuoto.

Eliminazione dello spazio di archiviazione permanente

Per impostazione predefinita, l'eliminazione di una richiesta di volume permanente per i volumi di cui è stato eseguito il provisioning dinamicamente, come i dischi permanenti di Compute Engine, elimina sia l'oggetto PersistentVolume sia il disco di supporto effettivo. Questo comportamento è controllato dal criterio di recupero in StorageClass e PersistentVolume, che può essere impostato su Delete o Retain per impostazione predefinita. Per saperne di più, consulta la documentazione di Kubernetes relativa al recupero.

Per evitare o ridurre la perdita di dati quando elimini lo spazio di archiviazione permanente, ti consigliamo di attivare Backup per GKE e di pianificare backup regolari del tuo cluster GKE, inclusi i carichi di lavoro di cui è stato eseguito il deployment e i relativi dati.

Gestire lo spazio di archiviazione permanente durante l'eliminazione del cluster

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

Per rimuovere le risorse PersistentVolume quando elimini un cluster, puoi eliminare manualmente il nome di spazio dei Namespaces delle risorse PersistentVolume, il che attiverà l'eliminazione degli oggetti PersistentVolume con il criterio Delete.PersistentVolumeClaim 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 un ambito e poi elimini immediatamente il cluster, le risorse PersistentVolume con i criteri 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 consigli 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 molti nodi. Le risorse PersistentVolume basate su dischi permanenti Compute Engine non supportano questa modalità di accesso.

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 le istruzioni, consulta Utilizzare i dischi permanenti con più lettori.

Utilizzare dischi permanenti preesistenti come volumi permanenti

Le risorse PersistentVolume di cui è stato eseguito il provisioning dinamico sono vuote al momento della creazione. Se hai già un disco permanente Compute Engine con dati al suo interno, puoi introdurlo nel tuo cluster creando manualmente una risorsa PersistentVolume corrispondente. Il disco permanente deve trovarsi nella stessa zona del cluster.

Consulta questo esempio di come creare un volume permanente basato su un disco permanente preesistente.

Deployment e StatefulSet

Puoi utilizzare un modello PersistentVolumeClaim o VolumeClaim nei controller di livello superiore, come Deployment o StatefulSets.

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 utilizzano il volume ReadWriteOnce non sono consigliati. Questo accade perché la strategia di Deployment predefinita crea un secondo pod prima di interrompere il primo pod durante la ricostituzione. Il deployment potrebbe non riuscire a causa di un blocco in cui il secondo pod non può essere avviato perché il volume ReadWriteOnce è già in uso e il primo pod non verrà rimosso perché il secondo 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 modelli PersistentVolumeClaim, puoi avere applicazioni che possono eseguire il ridimensionamento automatico con PersistentVolumeClaim univoci associati a ogni replica Pod.

Dischi permanenti a livello di regione

I dischi permanenti a livello di regione sono risorse multizonali che replicano i dati tra due zone nella stessa regione e possono essere utilizzati in modo simile ai dischi permanenti zonali. In caso di interruzione del servizio a livello di zona o se i nodi del cluster in una zona non sono pianificabili, Kubernetes può eseguire il failover dei carichi di lavoro che utilizzano il volume nell'altra zona. Puoi utilizzare i dischi permanenti regionali per creare soluzioni ad alta disponibilità per i carichi di lavoro stateful su 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 un'alta disponibilità sia alte prestazioni. Per maggiori dettagli, vedi Confronto del rendimento dello spazio di archiviazione dei 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 esigenze o a provisioning manuale in anticipo da parte dell'amministratore del cluster. Per scoprire come aggiungere dischi permanenti a livello di regione, consulta 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, mentre i dischi permanenti a livello di regione sono risorse multi-zona. Quando aggiungi spazio di archiviazione permanente al tuo 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 i dischi permanenti preesistenti, utilizza i metodi di posizionamento zonale come nodeAffinity nelle specifiche del pod o 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 WaitForFirstConsumer modalità di associazione del volume nella classe di archiviazione. Questa impostazione indica a Kubernetes di eseguire il provisioning di un disco permanente nella stessa zona in cui viene pianificato il pod. Rispetta i vincoli di pianificazione dei pod come 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 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