Utilizzo del driver CSI per il disco permanente di Compute Engine

Autopilot Standard

Google Kubernetes Engine (GKE) offre un modo semplice per eseguire automaticamente il deployment e la gestione del driver CSI (Container Storage Interface) per i disco permanente di Compute Engine nei tuoi cluster. Il driver CSI per il disco permanente di Compute Engine è sempre abilitato nei cluster Autopilot e non può essere disabilitato o modificato. Nei cluster Standard, devi abilitare il driver CSI per il disco permanente di Compute Engine.

La versione del driver CSI per il disco permanente di Compute Engine è associata ai numeri di versione di GKE. La versione del driver CSI per il disco permanente di Compute Engine è in genere l'ultimo driver disponibile al momento del rilascio della versione di GKE. I driver vengono aggiornati automaticamente quando il cluster viene sottoposto all'upgrade all'ultima patch GKE.

Nota: poiché il driver CSI del disco permanente Compute Engine e alcuni degli altri componenti CSI associati vengono implementati come container separati, comportano l'utilizzo di risorse (CPU, memoria e disco di avvio della VM) sui nodi Kubernetes. L'utilizzo della CPU della VM è in genere di decine di millicore e la memoria utilizzata è in genere di decine di MB. L'utilizzo del disco di avvio è dovuto principalmente ai log del driver CSI e di altri container di sistema nel deployment.

Vantaggi

L'utilizzo del driver CSI per il disco permanente di Compute Engine offre i seguenti vantaggi:

• Consente l'implementazione e la gestione automatiche del driver del disco permanente senza doverlo configurare manualmente.
• Puoi utilizzare le chiavi di crittografia gestite dal cliente (CMEK). Queste chiavi vengono utilizzate per criptare le chiavi di crittografia dei dati che criptano i tuoi dati. Per scoprire di più su CMEK su GKE, consulta Utilizzo di CMEK.
• Puoi utilizzare gli snapshot dei volumi con il driver CSI per il disco permanente di Compute Engine. Gli snapshot dei volumi ti consentono di creare una copia del volume in un momento specifico. Puoi utilizzare questa copia per riportare un volume a uno stato precedente o per eseguire il provisioning di un nuovo volume.
• Puoi utilizzare la clonazione dei volumi con il driver CSI del disco permanente di Compute Engine nei cluster che eseguono GKE versione 1.22 e successive. La clonazione del volume ti consente di creare un duplicato del volume in un momento specifico, con tutti i dati del volume di origine.
• Le correzioni di bug e gli aggiornamenti delle funzionalità vengono implementati indipendentemente dalle release secondarie di Kubernetes. Questo programma delle pubblicazioni in genere comporta una cadenza di rilascio più rapida.

Prima di iniziare

Prima di iniziare, assicurati di aver eseguito le seguenti operazioni:

• Abilita l'API Google Kubernetes Engine.
Abilita l'API Google Kubernetes Engine
• Per utilizzare Google Cloud CLI per questa attività, installala e poi inizializza gcloud CLI. Se hai già installato gcloud CLI, scarica l'ultima versione eseguendo il comando gcloud components update. Le versioni precedenti di gcloud CLI potrebbero non supportare l'esecuzione dei comandi in questo documento.
  Nota: per le installazioni esistenti di gcloud CLI, assicurati di impostare la proprietà compute/region. Se utilizzi principalmente cluster zonali, imposta invece compute/zone. Se imposti una località predefinita, puoi evitare errori in gcloud CLI come il seguente: One of [--zone, --region] must be supplied: Please specify location. Potresti dover specificare la posizione in determinati comandi se la posizione del cluster è diversa da quella predefinita che hai impostato.

Abilita il driver CSI per il disco permanente di Compute Engine

Per abilitare il driver CSI per il disco permanente di Compute Engine nei cluster Standard esistenti, utilizza Google Cloud CLI o la console Google Cloud .

Per attivare il driver su un cluster esistente, completa i seguenti passaggi:

gcloud

gcloud container clusters update CLUSTER-NAME \
   --update-addons=GcePersistentDiskCsiDriver=ENABLED

Sostituisci CLUSTER-NAME con il nome del cluster esistente.

Console

1. Vai alla pagina Google Kubernetes Engine nella console Google Cloud .

   Vai a Google Kubernetes Engine

2. Nell'elenco dei cluster, fai clic sul nome del cluster da modificare.

3. In Funzionalità, accanto al campo Driver CSI per il disco permanente di Compute Engine, fai clic su Modifica driver CSI di Compute Engine.

4. Seleziona la casella di controllo Abilita driver CSI per il disco permanente di Compute Engine.

5. Fai clic su Salva modifiche.

Dopo aver abilitato il driver CSI per il disco permanente di Compute Engine, puoi utilizzarlo nei volumi Kubernetes utilizzando il nome del driver e del provisioner: pd.csi.storage.gke.io.

Disabilita il driver CSI per il disco permanente di Compute Engine

Puoi disattivare il driver CSI per il disco permanente di Compute Engine per i cluster Standard utilizzando Google Cloud CLI o la console Google Cloud .

Se disattivi il driver, i pod che utilizzano PersistentVolumes di proprietà del driver non vengono terminati. Anche i nuovi pod che tentano di utilizzare questi PersistentVolume non vengono avviati.

Nota: poiché viene eseguita la migrazione del tipo di volume gcePersistentDisk al driver CSI del disco permanente di Compute Engine nella versione 1.22 e successive, se disabiliti il driver CSI del disco permanente, anche il tipo di volume gcePersistentDisk smette di funzionare.

Avviso: esiste un problema noto in GKE 1.21 e versioni precedenti se utilizzi il driver del disco permanente in-tree e vuoi eliminare i dischi regionali. Un disco regionale Compute Engine può subire perdite quando la risorsa PersistentVolume correlata viene eliminata. Questo problema può essere rilevato quando la chiamata API per eliminare il disco regionale non va a buon fine e restituisce un codice di errore diverso da NotFound. Per maggiori informazioni, vedi questo problema su GitHub.

Per disattivare il driver su un cluster Standard esistente, completa i seguenti passaggi:

gcloud

gcloud container clusters update CLUSTER-NAME \
    --update-addons=GcePersistentDiskCsiDriver=DISABLED

Sostituisci CLUSTER-NAME con il nome del cluster esistente.

Console

1. Vai alla pagina Google Kubernetes Engine nella console Google Cloud .

   Vai a Google Kubernetes Engine

2. Nell'elenco dei cluster, fai clic sul nome del cluster da modificare.

3. In Funzionalità, accanto al campo Driver CSI per il disco permanente di Compute Engine, fai clic su Modifica driver CSI di Compute Engine.

4. Deseleziona la casella di controllo Abilita driver CSI per il disco permanente di Compute Engine.

5. Fai clic su Salva modifiche.

Utilizza il driver CSI per il disco permanente di Compute Engine per i cluster Linux

Le sezioni seguenti descrivono la procedura tipica per l'utilizzo di un volume Kubernetes supportato da un driver CSI in GKE. Queste sezioni sono specifiche per i cluster che utilizzano Linux.

Crea una StorageClass

Dopo aver abilitato il driver CSI per il disco permanente di Compute Engine, GKE installa automaticamente le seguenti StorageClasses:

• standard-rwo, utilizzando il disco permanente bilanciato
• premium-rwo, utilizzando disco permanente SSD

Per i cluster Autopilot, StorageClass predefinita è standard-rwo, che utilizza il driver CSI del disco permanente di Compute Engine. Per i cluster Standard, la classe di archiviazione predefinita utilizza il plug-in del volume gcePersistentDisk in-tree di Kubernetes.

Puoi trovare il nome delle StorageClass installate eseguendo questo comando:

kubectl get sc

Puoi anche installare una StorageClass diversa che utilizza il driver CSI per il disco permanente di Compute Engine aggiungendo pd.csi.storage.gke.io nel campo del provisioner.

Ad esempio, puoi creare un oggetto StorageClass utilizzando il seguente file, denominato pd-example-class.yaml.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: pd-example
provisioner: pd.csi.storage.gke.io
# Recommended setting. Delays the binding and provisioning of a PersistentVolume until a Pod that uses the
# PersistentVolumeClaim is created and scheduled on a node.
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
parameters:
  type: pd-balanced

Puoi specificare i seguenti tipi di Persistent Disk nel parametro type:

• pd-balanced
• pd-ssd
• pd-standard
• pd-extreme (supportato su GKE versione 1.26 e successive)

Se utilizzi pd-standard o pd-extreme, consulta Tipi di macchine non supportati per ulteriori limitazioni di utilizzo.

Quando utilizzi l'opzione pd-extreme, devi anche aggiungere il campo provisioned-iops-on-create al manifest. Questo campo deve essere impostato sullo stesso valore del valore IOPS di cui è stato eseguito il provisioning specificato quando hai creato il disco permanente.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: pd-extreme-example
provisioner: pd.csi.storage.gke.io
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
parameters:
  type: pd-extreme
  provisioned-iops-on-create:'10000'

Dopo aver creato il file pd-example-class.yaml, esegui questo comando:

kubectl create -f pd-example-class.yaml

Crea un PersistentVolumeClaim

Puoi creare un PersistentVolumeClaim che fa riferimento a StorageClass del driver CSI per il disco permanente di Compute Engine.

Il seguente file, denominato pvc-example.yaml, utilizza la classe di archiviazione preinstallata standard-rwo:

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: podpvc
spec:
  accessModes:
  - ReadWriteOnce
  storageClassName: standard-rwo
  resources:
    requests:
      storage: 6Gi

Dopo aver creato il manifest PersistentVolumeClaim, esegui questo comando:

kubectl create -f pvc-example.yaml

Nella classe StorageClass preinstallata (standard-rwo), volumeBindingMode è impostato su WaitForFirstConsumer. Quando volumeBindingMode è impostato su WaitForFirstConsumer, il provisioning di PersistentVolume non viene eseguito finché non viene pianificato un pod che fa riferimento a PersistentVolumeClaim. Se volumeBindingMode in StorageClass è impostato su Immediate (o se viene omesso), viene eseguito il provisioning di un PersistentVolume supportato da un disco permanente dopo la creazione di PersistentVolumeClaim.

Crea un pod che utilizza il volume

Quando utilizzi i pod con PersistentVolume, ti consigliamo di utilizzare un controller del workload (ad esempio un Deployment o uno StatefulSet). Anche se in genere non utilizzeresti un pod autonomo, l'esempio seguente ne utilizza uno per semplicità.

L'esempio seguente utilizza il volume creato nella sezione precedente:

apiVersion: v1
kind: Pod
metadata:
  name: web-server
spec:
  containers:
   - name: web-server
     image: nginx
     volumeMounts:
       # The path in the container where the volume will be mounted.
       - mountPath: /var/lib/www/html
         # The name of the volume that is being defined in the "volumes" section.
         name: mypvc
  volumes:
   - name: mypvc
     persistentVolumeClaim:
       # References the PersistentVolumeClaim created earlier.
       claimName: podpvc
       readOnly: false

Pianificazione della compatibilità dell'archiviazione di GKE Autopilot

Nei cluster Autopilot, GKE gestisce automaticamente il provisioning dei nodi e l'allocazione delle risorse. Per fare in modo che Autopilot esegua il provisioning di nodi compatibili con il tipo di archiviazione richiesto, devi specificare il parametro use-allowed-disk-topology: "true" nella definizione StorageClass personalizzata.

La configurazione di questo parametro impone i seguenti comportamenti di pianificazione:

• Il gestore della scalabilità automatica dei cluster esegue il provisioning solo di nuovi nodi con tipi di macchine che supportano il tipo di disco richiesto.
• Il pod è pianificato su un nodo compatibile. Questa pianificazione impedisce al pod di bloccarsi negli stati ContainerCreating o Pending.

Per saperne di più, consulta Pianificazione dei nodi supportata.

Le serie di macchine più recenti, come C3 o E4, richiedono l'archiviazione Google Cloud Hyperdisk (ad esempio hyperdisk-balanced). Queste serie di macchine non supportano i tipi di volumi Persistent Disk precedenti, come i volumi Standard Persistent Disk (pd-standard) o SSD Persistent Disk (pd-ssd). La compatibilità dello spazio di archiviazione influisce sulla pianificazione come segue:

• Fallback silenzioso: se un workload stateful utilizza un tipo di volume Persistent Disk precedente, ad esempio volumi Standard Persistent Disk (pd-standard) o SSD Persistent Disk (pd-ssd), ma non richiede esplicitamente una serie di macchine specifica, GKE pianifica automaticamente i pod sui nodi E2 perché supportano questi tipi di volumi Persistent Disk. Il carico di lavoro torna automaticamente all'hardware più recente predefinito.
• Errore di pianificazione (in attesa): potresti richiedere esplicitamente una serie di macchine più recente (ad esempio utilizzando i campi nodeSelector o una ComputeClass personalizzata). Se colleghi anche un tipo di volume Persistent Disk precedente, ad esempio volumi Standard Persistent Disk (pd-standard) o SSD Persistent Disk (pd-ssd), GKE non riesce a trovare un nodo che soddisfi entrambi i vincoli. Il pod rimane nello stato Pending.
• Conflitto di tipi di archiviazione multipli (In attesa): se un pod fa riferimento a più PVC che utilizzano tipi di archiviazione diversi (ad esempio, combinando un tipo di volume Persistent Disk precedente come Standard Persistent Disk (pd-standard) e l'archiviazione Google Cloud Hyperdisk), GKE potrebbe non essere in grado di trovare un tipo di nodo che supporti tutti i vincoli. In questo scenario, il pod rimane nello stato Pending.
• Richiesta di CPU insufficiente per i dischi estremi (In attesa): i tipi di volume estremi, come hyperdisk-extreme e pd-extreme, richiedono forme di VM di grandi dimensioni con un numero elevato di vCPU. Se il pod richiede un numero troppo basso di vCPU, GKE potrebbe eseguire il provisioning di una forma del nodo che non supporta il tipo di volume, causando il mantenimento del pod nello stato Pending. Per garantire una pianificazione corretta, specifica richieste di CPU sufficientemente grandi in modo che Autopilot esegua il provisioning di una forma di VM supportata. Per l'elenco dei tipi di macchine supportati e dei requisiti minimi di vCPU, consulta Supporto delle macchine.

Per i passaggi per la risoluzione dei problemi e i dettagli su come verificare questo comportamento esaminando i log, consulta Workload pianificato su serie di macchine precedenti o bloccato nello stato Pending a causa dell'incompatibilità di archiviazione.

Utilizza il driver CSI per il disco permanente di Compute Engine per i cluster Windows

Le sezioni seguenti descrivono la procedura tipica per l'utilizzo di un volume Kubernetes supportato da un driver CSI in GKE. Queste sezioni sono specifiche per i cluster che utilizzano Windows.

Assicurati che:

• La versione del cluster è 1.19.7-gke.2000, 1.20.2-gke.2000 o successive.
• Le versioni dei nodi sono 1.18.12-gke.1203, 1.19.6-gke.800 o successive.

Crea una StorageClass

La creazione di un oggetto StorageClass per Windows è molto simile a quella per Linux. Tieni presente che la StorageClass installata per impostazione predefinita non funzionerà per Windows perché il tipo di file system è diverso. Il driver CSI per il disco permanente di Compute Engine per Windows richiede NTFS come tipo di file system.

Ad esempio, puoi creare una StorageClass utilizzando il seguente file denominato pd- windows-class.yaml. Assicurati di aggiungere csi.storage.k8s.io/fstype: NTFS all'elenco dei parametri:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: pd-sc-windows
provisioner: pd.csi.storage.gke.io
volumeBindingMode: WaitForFirstConsumer
allowVolumeExpansion: true
parameters:
  type: pd-balanced
  csi.storage.k8s.io/fstype: NTFS

Crea un PersistentVolumeClaim

Dopo aver creato una StorageClass per Windows, ora puoi creare una PersistentVolumeClaim che fa riferimento a questa StorageClass:

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: podpvc-windows
spec:
  accessModes:
  - ReadWriteOnce
  storageClassName: pd-sc-windows
  resources:
    requests:
      storage: 6Gi

Crea un pod che utilizza il volume

Il seguente esempio utilizza il volume che hai creato nell'attività precedente:

apiVersion: v1
kind: Pod
metadata:
  name: web-server
spec:
  # Node selector to ensure the Pod runs on a Windows node.
  nodeSelector:
    kubernetes.io/os: windows
  containers:
    - name: iis-server
      # The container image to use.
      image: mcr.microsoft.com/windows/servercore/iis
      ports:
      - containerPort: 80
      volumeMounts:
      # The path in the container where the volume will be mounted.
      - mountPath: /var/lib/www/html
        name: mypvc
  volumes:
    - name: mypvc
      persistentVolumeClaim:
        # References the PersistentVolumeClaim created earlier.
        claimName: podpvc-windows
        readOnly: false

Modificare dinamicamente le IOPS e il throughput di Hyperdisk utilizzando VolumeAttributeClass

Puoi utilizzare VolumeAttributesClass con il driver CSI per i disco permanente di Compute Engine per modificare dinamicamente gli attributi dei disco permanente, inclusi IOPS e throughput. Assicurati che la versione del cluster GKE sia 1.34 o successiva.

Questa sezione mostra come utilizzare VolumeAttributesClass per modificare dinamicamente le prestazioni del volume. Crea due risorse VolumeAttributesClass, silver e gold, per definire diversi livelli di IOPS e velocità effettiva. Poi, crei un StorageClass, un PersistentVolumeClaim che fa riferimento al livello silver e un pod per utilizzare il volume. Infine, aggiorni il PersistentVolumeClaim in modo che faccia riferimento al livello gold, che aggiorna dinamicamente le impostazioni delle prestazioni del volume.

Nota: sebbene i manifest StorageClass e Pod per l'utilizzo generale dei volumi Persistent Disk siano trattati in precedenza in questa pagina, il seguente flusso di lavoro è necessario per configurare e verificare le funzionalità di rendimento specifiche di Google Cloud Hyperdisk.

Crea un VolumeAttributesClass per definire i livelli di rendimento

Questa sezione definisce le risorse VolumeAttributesClass con i livelli di esempio denominati silver e gold.

1. Salva il seguente manifest come vac-classes.yaml:

   apiVersion: storage.k8s.io/v1
   kind: VolumeAttributesClass
   metadata:
     name: silver
   driverName: pd.csi.storage.gke.io
   parameters:
     iops: "3000"
     throughput: "188Mi"
   ---
   apiVersion: storage.k8s.io/v1
   kind: VolumeAttributesClass
   metadata:
     name: gold
   driverName: pd.csi.storage.gke.io
   parameters:
     iops: "6000"
     throughput: "345Mi"
   

2. Applica il manifest:

   kubectl apply -f vac-classes.yaml
   

Crea una StorageClass per Hyperdisk

Questa sezione definisce una risorsa StorageClass per il provisioning dei volumi Hyperdisk.

1. Salva il seguente manifest come hyperdisk-sc.yaml:

   apiVersion: storage.k8s.io/v1
   kind: StorageClass
   metadata:
     name: hyperdisk-example
   provisioner: pd.csi.storage.gke.io
   volumeBindingMode: WaitForFirstConsumer
   allowVolumeExpansion: true
   parameters:
     type: hyperdisk-balanced
   

2. Applica il manifest:

   kubectl apply -f hyperdisk-sc.yaml
   

Crea una PVC con un livello di prestazioni iniziale

Questa sezione crea un PVC e utilizza il livello iniziale denominato silver.

1. Salva il seguente manifest come vac-silver-pvc.yaml:

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: test-pv-claim
   spec:
     accessModes:
     - ReadWriteOnce
     storageClassName: hyperdisk-example
     volumeAttributesClassName: silver
     resources:
       requests:
         storage: 200Gi
   

2. Applica il manifest:

   kubectl apply -f vac-silver-pvc.yaml
   

3. Per eseguire il provisioning di un volume permanente, crea un pod che utilizzi la richiesta di volume permanente. StorageClass creato nella sezione precedente imposta volumeBindingMode: WaitForFirstConsumer, che ritarda il provisioning del volume finché un pod non utilizza la PVC. Salva il seguente manifest come test-pod.yaml:

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

4. Applica il manifest:

   kubectl apply -f test-pod.yaml
   

5. Per verificare le impostazioni delle prestazioni del disco, consulta Verificare le impostazioni delle prestazioni del disco nella console Google Cloud . Le IOPS sottoposte a provisioning devono essere 3000 e il throughput sottoposto a provisioning deve essere 188, rispettivamente.

Aggiorna la PVC per utilizzare un livello di prestazioni diverso

Questa sezione aggiorna il PVC in modo che utilizzi il livello gold anziché il livello silver.

1. Salva il seguente manifest come vac-gold-pvc.yaml:

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: test-pv-claim
   spec:
     accessModes:
     - ReadWriteOnce
     storageClassName: hyperdisk-example
     volumeAttributesClassName: gold
     resources:
       requests:
         storage: 200Gi
   

2. Applica il manifest:

   kubectl apply -f vac-gold-pvc.yaml
   

3. Per verificare che le impostazioni delle prestazioni del disco siano aggiornate, vedi Verificare le impostazioni delle prestazioni del disco nella console Google Cloud . Le IOPS sottoposte a provisioning devono essere 6000 e il throughput sottoposto a provisioning deve essere 345, rispettivamente.

Verifica le impostazioni delle prestazioni del disco nella console Google Cloud

Puoi verificare che le impostazioni di IOPS e throughput siano applicate al disco permanente controllando i dettagli del disco nella console Google Cloud .

1. Recupera il nome del disco:

   PV_NAME=$(kubectl get pvc test-pv-claim -o=jsonpath='{.spec.volumeName}')
   DISK_NAME=$(kubectl get pv $PV_NAME -o=jsonpath='{.spec.csi.volumeHandle}' | sed 's|.*/||')
   echo "Persistent disk name: $DISK_NAME"
   

2. Nella console Google Cloud , vai alla pagina Dischi.

   Vai a Dischi

3. Fai clic sul nome del disco permanente che corrisponde al nome del disco nell'output del passaggio precedente.

4. Nella pagina Dettagli disco, nella sezione Rendimento, visualizza IOPS sottoposte a provisioning e Throughput sottoposto a provisioning.

Per saperne di più, consulta Visualizza le impostazioni delle prestazioni di cui è stato eseguito il provisioning per Hyperdisk.

Considerazioni per la modifica dinamica

• Applicare di nuovo le configurazioni precedenti: se un PVC non può essere associato a una classe di attributi del volume a causa di un errore, ad esempio risorse non disponibili, puoi applicare di nuovo il PVC precedente in modo sicuro.
• Supporto delle quote:il control plane Kubernetes può applicare quote alle PVC che fanno riferimento a un VolumeAttributesClass specifico utilizzando scopeSelector in ResourceQuota.

Utilizza il driver CSI per il disco permanente di Compute Engine con tipi di file system non predefiniti

Il tipo di file system predefinito per i dischi permanenti Compute Engine in GKE è ext4. Puoi anche utilizzare il tipo di archiviazione xfs, purché sia supportato dall'immagine del nodo. Consulta Supporto dei driver di archiviazione per un elenco dei driver supportati per immagine del nodo.

L'esempio seguente mostra come utilizzare xfs come tipo di file system predefinito anziché ext4 con il driver CSI per il disco permanente di Compute Engine.

Crea una classe StorageClass

1. Salva il seguente manifest come file YAML denominato pd-xfs-class.yaml:

   apiVersion: storage.k8s.io/v1
   kind: StorageClass
   metadata:
     name: xfs-class
   provisioner: pd.csi.storage.gke.io
   parameters:
     # The type of Compute Engine persistent disk to provision.
     type: pd-balanced
     # Specify "xfs" as the filesystem type.
     csi.storage.k8s.io/fstype: xfs
   volumeBindingMode: WaitForFirstConsumer
   

2. Applica il manifest:

   kubectl apply -f pd-xfs-class.yaml
   

Crea un PersistentVolumeClaim

1. Salva il seguente manifest come pd-xfs-pvc.yaml:

   apiVersion: v1
   kind: PersistentVolumeClaim
   metadata:
     name: xfs-pvc
   spec:
     # References the StorageClass created earlier.
     storageClassName: xfs-class
     accessModes:
       - ReadWriteOnce
     resources:
       requests:
         # The amount of storage requested.
         storage: 10Gi
   

2. Applica il manifest:

   kubectl apply -f pd-xfs-pvc.yaml
   

Crea un pod che utilizza il volume

1. Salva il seguente manifest come pd-xfs-pod.yaml:

   apiVersion: v1
   kind: Pod
   metadata:
     name: pd-xfs-pod
   spec:
     containers:
     - name: cloud-sdk
       image: google/cloud-sdk:slim
       # Keep the container running for 1 hour.
       args: ["sleep","3600"]
       volumeMounts:
       # The path in the container where the volume will be mounted.
       - mountPath: /xfs
         name: xfs-volume
     # Define the volumes available to the containers in the Pod.
     volumes:
     - name: xfs-volume
       persistentVolumeClaim:
         # References the PersistentVolumeClaim created earlier.
         claimName: xfs-pvc
   

2. Applica il manifest:

   kubectl apply -f pd-xfs-pod.yaml
   

Verifica che il volume sia stato montato correttamente

1. Apri una sessione shell nel pod:

   kubectl exec -it pd-xfs-pod -- /bin/bash
   

2. Cerca le partizioni xfs:

   df -aTh --type=xfs
   

   L'output dovrebbe essere simile al seguente:

   Filesystem     Type  Size  Used Avail Use% Mounted on
   /dev/sdb       xfs    30G   63M   30G   1% /xfs
   

Visualizza i log del driver CSI per il disco permanente di Compute Engine

Puoi utilizzare Cloud Logging per visualizzare gli eventi relativi al driver CSI per il disco permanente di Compute Engine. I log possono aiutarti a risolvere i problemi.

Per saperne di più su Cloud Logging, consulta Visualizzazione dei log di GKE.

Per visualizzare i log del driver CSI per il disco permanente di Compute Engine, completa i seguenti passaggi:

1. Vai alla pagina Cloud Logging nella console Google Cloud .

   Vai a Cloud Logging

2. Per filtrare le voci di log in modo da mostrare solo quelle relative al driver CSI in esecuzione nel tuo spazio dei nomi, esegui la seguente query Cloud Logging:

    resource.type="k8s_container"
    resource.labels.project_id="PROJECT_ID"
    resource.labels.location="LOCATION"
    resource.labels.cluster_name="CLUSTER_NAME"
    resource.labels.namespace_name="kube-system"
    resource.labels.container_name="gce-pd-driver"
   

   Sostituisci quanto segue:

   • PROJECT_ID: il nome del progetto.
   • LOCATION: la regione o la zona Compute Engine del cluster.
   • CLUSTER_NAME: il nome del tuo cluster.

Problemi noti

Tipi di macchine non supportati

Se utilizzi la famiglia di macchine della serie C3, il tipo di disco permanente pd-standard non è supportato.

Pianificazione della compatibilità dello spazio di archiviazione Autopilot

Per i workload eseguiti in modalità Autopilot (in cluster Autopilot o cluster Standard che utilizzano le classi di computing Autopilot), i pod con archiviazione permanente collegata vengono pianificati solo su serie di macchine compatibili:

• Dischi permanenti legacy: i pod che utilizzano dischi pd-standard legacy vengono eseguiti solo sulle serie di macchine che li supportano, come i nodi E2.
• Hyperdisk: i pod che utilizzano l'archiviazione di nuova generazione come hyperdisk-balanced vengono eseguiti su serie di macchine più recenti, come i nodi C3.
• Stato In attesa: se configuri esplicitamente un pod per l'esecuzione su una serie di macchine più recente (ad esempio, utilizzando i selettori di nodi per richiedere nodi C3 o configurando una ComputeClass personalizzata), ma colleghi un disco pd-standard legacy, il pod rimane nello stato Pending a tempo indeterminato. Ciò si verifica perché GKE non riesce a trovare un nodo che soddisfi i vincoli di compatibilità del tipo di macchina e del disco. Quando selezioni esplicitamente una serie di macchine, sei responsabile di garantire la compatibilità di PersistentVolume e del disco.

Se provi a eseguire un pod su una macchina e il pod utilizza un tipo di disco permanente non supportato, sul pod verrà visualizzato un messaggio di avviso simile al seguente:

AttachVolume.Attach failed for volume "pvc-d7397693-5097-4a70-9df0-b10204611053" : rpc error: code = Internal desc = unknown Attach error: failed when waiting for zonal op: operation operation-1681408439910-5f93b68c8803d-6606e4ed-b96be2e7 failed (UNSUPPORTED_OPERATION): [pd-standard] features are not compatible for creating instance.

Se il tuo cluster ha più pool di nodi con famiglie di macchine diverse, puoi utilizzare contaminazioni dei nodi e affinità dei nodi per limitare i punti in cui è possibile pianificare i workload. Ad esempio, puoi utilizzare questo approccio per impedire l'esecuzione di un carico di lavoro utilizzando pd-standard su una famiglia di macchine non supportata.

Se utilizzi il tipo di disco permanente pd-extreme, devi assicurarti che il disco sia collegato a un'istanza VM con una forma di macchina adatta. Per saperne di più, consulta Supporto della forma della macchina.

Passaggi successivi

• Scopri come utilizzare l'espansione del volume.
• Scopri come utilizzare gli snapshot dei volumi.
• Scopri come utilizzare la clonazione dei volumi.
• Scopri come creare dischi permanenti regionali.
• Scopri di più sul driver su GitHub.