Utilizzo del driver CSI per il disco permanente di Compute Engine

Google Kubernetes Engine (GKE) offre un modo semplice per eseguire automaticamente il deployment e gestire il driver Container Storage Interface (CSI) per il disco permanente di Compute Engine nei 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 viene eseguito l'upgrade del cluster all'ultima patch di GKE.

Vantaggi

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

  • Consente il deployment e la gestione automatici 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 saperne di più sulle CMEK in GKE, consulta Utilizzo delle 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 per il disco permanente di Compute Engine nei cluster che eseguono GKE versione 1.22 e successive. La clonazione dei volumi ti consente di creare un duplicato del volume in un momento specifico, di cui è stato eseguito il provisioning 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. Questa pianificazione delle release in genere comporta una cadenza di rilascio più rapida.

Prima di iniziare

Prima di iniziare, assicurati di aver eseguito le seguenti attività:

  • Abilita l'API Google Kubernetes Engine.
  • Abilita l'API Google Kubernetes Engine
  • Se vuoi 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 gcloud components update comando. Le versioni precedenti di gcloud CLI potrebbero non supportare l'esecuzione dei comandi in questo documento.

Abilitare 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 il Google Cloud CLI o la Cloud de Confiance console.

Per abilitare 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 Cloud de Confiance console.

    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.

Disabilitare il driver CSI per il disco permanente di Compute Engine

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

Se disabiliti il driver, tutti i pod che al momento utilizzano volumi permanenti di proprietà del driver non potranno essere terminati. Inoltre, i nuovi pod che tenteranno di utilizzare quei volumi permanenti non riusciranno ad avviarsi.

Per disabilitare 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 Cloud de Confiance console.

    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.

Utilizzare 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.

Creare un oggetto 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 il disco permanente SSD

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

Puoi trovare il nome delle StorageClass installate eseguendo il seguente comando:

kubectl get sc

Puoi anche installare un'altra StorageClass 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 una 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 dischi permanenti nel parametro type:

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

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

Se utilizzi l'opzione pd-extreme, devi anche aggiungere il campo provisioned-iops-on-create al manifest. Questo campo deve essere impostato sullo stesso valore delle 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 il seguente comando:

kubectl create -f pd-example-class.yaml

Creare un oggetto PersistentVolumeClaim

Puoi creare un oggetto PersistentVolumeClaim che fa riferimento alla 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 il seguente comando:

kubectl create -f pvc-example.yaml

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

Creare un pod che utilizza il volume

Quando utilizzi i pod con i PersistentVolume, ti consigliamo di utilizzare un controller di workload (ad esempio un deployment o un StatefulSet). Sebbene 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

Utilizzare 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 sia 1.19.7-gke.2000, 1.20.2-gke.2000 o successive.
  • Le versioni dei nodi siano 1.18.12-gke.1203, 1.19.6-gke.800 o successive.

Creare un oggetto StorageClass

La creazione di una 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

Creare un oggetto PersistentVolumeClaim

Dopo aver creato una StorageClass per Windows, puoi creare un oggetto 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

Creare un pod che utilizza il volume

L'esempio seguente utilizza il volume 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 il disco permanente di Compute Engine per modificare dinamicamente gli attributi del disco permanente, tra cui IOPS e throughput. Assicurati che la versione del cluster GKE sia 1.34 o successive.

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 throughput. Poi, crea una StorageClass, un oggetto PersistentVolumeClaim che fa riferimento al livello silver e un pod per utilizzare il volume. Infine, aggiorna PersistentVolumeClaim in modo che faccia riferimento al livello gold, che esegue un aggiornamento dinamico delle impostazioni delle prestazioni del volume.

Creare un oggetto VolumeAttributesClass per definire i livelli di prestazioni

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
    

Creare 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
    

Creare una PVC con un livello di prestazioni iniziale

Questa sezione crea una 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 utilizza la PVC. Il 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 Cloud de Confiance console. Le IOPS di cui è stato eseguito il provisioning devono essere 3000 e il throughput di cui è stato eseguito il provisioning deve essere 188, rispettivamente.

Aggiornare la PVC per utilizzare un livello di prestazioni diverso

Questa sezione aggiorna la 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, consulta Verificare le impostazioni delle prestazioni del disco nella Cloud de Confiance console. Le IOPS di cui è stato eseguito il provisioning devono essere 6000 e il throughput di cui è stato eseguito il provisioning deve essere 345, rispettivamente.

Verificare le impostazioni delle prestazioni del disco nella Cloud de Confiance console

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

  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 Cloud de Confiance console, 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 Prestazioni, visualizza IOPS di cui è stato eseguito il provisioning e Throughput di cui è stato eseguito il provisioning.

Per ulteriori informazioni, consulta Visualizzare le impostazioni delle prestazioni di cui è stato eseguito il provisioning per Hyperdisk.

Considerazioni per la modifica dinamica

  • Applicare di nuovo le configurazioni precedenti: se una PVC non può essere associata a una classe di attributi del volume a causa di un errore, ad esempio risorse non disponibili, puoi applicare di nuovo la PVC precedente in tutta sicurezza.
  • Supporto delle quote: il piano di controllo di Kubernetes può applicare le quote alle PVC che fanno riferimento a una VolumeAttributesClass specifica utilizzando scopeSelector in ResourceQuota.

Utilizzare 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 di Compute Engine in GKE è ext4. Puoi anche utilizzare il tipo di archiviazione xfs, a condizione che l'immagine del nodo lo supporti. Consulta Supporto dei driver di archiviazione per un elenco dei driver supportati dall'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.

Creare un oggetto 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
    

Creare un oggetto 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
    

Creare 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
    

Verificare 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
    

Visualizzare 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 Visualizzare i 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 Cloud de Confiance console.

    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 di 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 di 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.

Se tenti di eseguire un pod su una macchina e il pod utilizza un tipo di disco permanente non supportato, vedrai un messaggio di avviso simile al seguente emesso sul pod:

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 cluster ha più pool di nodi con famiglie di macchine diverse, puoi utilizzare i taint dei nodi e l'affinità dei nodi per limitare la pianificazione dei workload. Ad esempio, puoi utilizzare questo approccio per impedire l'esecuzione di un workload che utilizza 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 delle forme di macchine.

Passaggi successivi