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 la gestione del 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'ultima 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.

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 del volume 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 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 minori di Kubernetes. Questa pianificazione delle uscite in genere comporta una cadenza di rilascio più rapida.

Prima di iniziare

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

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

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 disabiliti il driver, tutti i pod che al momento utilizzano volumi permanenti di proprietà del driver non vengono terminati. Inoltre, i nuovi pod che tenteranno di utilizzare questi PersistentVolume non riusciranno ad avviarsi.

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

Per i cluster Autopilot, StorageClass predefinita è standard-rwo, che utilizza il driver CSI per il 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 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 Persistent Disk nel parametro type:

  • pd-balanced
  • pd-ssd
  • pd-standard
  • pd-extreme (supportato su GKE 1.26 e versioni 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 dell'IOPS di provisioning che hai 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 risorsa 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 è omesso), viene eseguito il provisioning di un PersistentVolume supportato da 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 carico di lavoro (ad esempio un deployment o un 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

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 è 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 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

Crea un PersistentVolumeClaim

Dopo aver creato una StorageClass per Windows, puoi creare una PersistentVolumeClaim che fa riferimento a quella 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

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, inclusi IOPS e velocità effettiva. 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 PersistentVolumeClaim in modo che faccia riferimento al livello gold, il che comporta un aggiornamento dinamico delle impostazioni di rendimento del volume.

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 un oggetto 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 rendimento 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 il PVC per utilizzare un livello di rendimento 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 Prestazioni, 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, a condizione che l'immagine del nodo lo supporti. Consulta la sezione 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 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 per il 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 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 nello 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.

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 tuo cluster ha più pool di nodi con famiglie di macchine diverse, puoi utilizzare taint dei nodi e affinità dei nodi per limitare la posizione in cui possono essere pianificati i workload. Ad esempio, puoi utilizzare questo approccio per impedire l'esecuzione di un carico di lavoro 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 della forma della macchina.

Passaggi successivi