Accedi ai bucket Cloud Storage con il driver CSI di Cloud Storage FUSE


File system nello spazio utente (FUSE) è un'interfaccia utilizzata per esportare un file system nel kernel Linux. Cloud Storage FUSE consente di montare bucket Cloud Storage come file system in modo che le applicazioni possano accedere agli oggetti in un bucket utilizzando operazioni comuni di I/O file (ad es. apertura, lettura, scrittura, chiusura) anziché utilizzare API specifiche del cloud.

Il driver CSI di Cloud Storage FUSE consente di utilizzare l'API Kubernetes per consumare bucket Cloud Storage preesistenti come volumi. Le tue applicazioni può caricare e scaricare oggetti utilizzando la semantica del file system FUSE di Cloud Storage FUSE. Il driver CSI di Cloud Storage FUSE offre un'esperienza completamente gestita basata sul sistema open source Driver CSI di Google Cloud Storage FUSE.

Il driver supporta in modo nativo i seguenti modi per configurare Volumi supportati da Cloud Storage:

Puoi utilizzare il driver CSI di Cloud Storage FUSE con la memorizzazione dei file nella cache per migliorare le prestazioni di lettura delle applicazioni che gestiscono file di piccole dimensioni dai bucket Cloud Storage. La funzionalità di cache dei file di Cloud Storage FUSE è una cache di lettura basata su client che consente di letture ripetute dei file affinché vengano fornite più rapidamente dallo spazio di archiviazione della cache di tua scelta. Puoi scegliere tra una gamma di opzioni di archiviazione per la cache di lettura, come SSD locali e archiviazione basata su Persistent Disk, in base alle tue esigenze di rapporto prezzo/prestazioni. Devi attivare l'opzione per abilitare la memorizzazione nella cache dei file con il driver CSI di Cloud Storage FUSE. Per saperne di più sulle best practice per la memorizzazione nella cache, consulta Prestazioni e best practice di Cloud Storage FUSE.

Vantaggi

  • Il driver CSI di Cloud Storage FUSE sul tuo cluster attiva il deployment automatico e la gestione del conducente. Il driver funziona sia su Standard Autopilot.
  • Il driver CSI di Cloud Storage FUSE non necessita di un accesso privilegiato, come richiesto dai client FUSE. Ciò consente una migliore strategia di sicurezza.
  • Il supporto dei volumi temporanei CSI semplifica configurazione e gestione del volume eliminando la necessità di PersistentVolumeClaim e gli oggetti PersistentVolume.
  • Il driver CSI di Cloud Storage FUSE supporta ReadWriteMany, ReadOnlyMany, e le modalità di accesso ReadWriteOnce.
  • Puoi utilizzare la Federazione delle identità per i carichi di lavoro per GKE. per gestire l'autenticazione e al contempo avere un controllo granulare sul modo in cui I pod accedono agli oggetti Cloud Storage. Quando si utilizza la federazione delle identità per i carichi di lavoro, è richiesto un accesso uniforme a livello di bucket per i carichi di lavoro di lettura e scrittura.
  • Se esegui l'addestramento e la gestione dei carichi di lavoro ML con framework come Ray, PyTorch, Spark e TensorFlow: portabilità e semplicità forniti dal driver CSI di Cloud Storage FUSE, che consentono di eseguire i carichi di lavoro direttamente sui tuoi cluster GKE senza ulteriori modifiche al codice.
  • Puoi leggere oggetti Cloud Storage con la memorizzazione nella cache dei file abilitata per migliorare le prestazioni di lettura. Per saperne di più sui vantaggi della memorizzazione nella cache dei file, consulta la documentazione di Cloud Storage FUSE.
  • Puoi consumare volumi Cloud Storage FUSE in container init.

Prima di iniziare

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

  • Attiva l'API Google Kubernetes Engine.
  • Abilita l'API Google Kubernetes Engine .
  • Se vuoi utilizzare Google Cloud CLI per questa attività, install e poi initialize con gcloud CLI. Se hai già installato gcloud CLI, scarica la versione più recente eseguendo gcloud components update.

Limitazioni

Requisiti

Per utilizzare il driver CSI di Cloud Storage FUSE, i cluster devono soddisfare i seguenti requisiti requisiti:

Abilita il driver CSI di Cloud Storage FUSE

Per creare un cluster Standard con il driver CSI di Cloud Storage FUSE abilitata, puoi utilizzare gcloud CLI:

gcloud container clusters create CLUSTER_NAME \
    --addons GcsFuseCsiDriver \
    --cluster-version=VERSION \
    --location=LOCATION \
    --workload-pool=PROJECT_ID.svc.id.goog

Sostituisci quanto segue:

  • CLUSTER_NAME: il nome del tuo cluster.
  • VERSION: il numero di versione GKE. Devi selezionare la versione 1.24 o successiva.
  • LOCATION: la località di Compute Engine per il cluster.
  • PROJECT_ID: il tuo ID progetto.

Per abilitare il driver su un cluster Standard esistente, utilizza Comando gcloud container clusters update:

gcloud container clusters update CLUSTER_NAME \
    --update-addons GcsFuseCsiDriver=ENABLED \
    --location=LOCATION

Sostituisci quanto segue:

Dopo aver abilitato il driver CSI di Cloud Storage FUSE, puoi utilizzarlo in Volumi Kubernetes specificando il nome del driver e del provisioner: gcsfuse.csi.storage.gke.io.

Configura l'accesso ai bucket Cloud Storage utilizzando la federazione delle identità per i carichi di lavoro GKE per GKE

Per rendere i bucket Cloud Storage accessibili dal tuo cluster GKE utilizzando la federazione delle identità per i carichi di lavoro per GKE, segui questi passaggi. Consulta Configurare le applicazioni per utilizzare la federazione delle identità per i carichi di lavoro per GKE per ulteriori informazioni.

  1. Richiedi le credenziali per il tuo cluster:

    gcloud container clusters get-credentials CLUSTER_NAME \
        --location=LOCATION
    

    Sostituisci quanto segue:

    • CLUSTER_NAME: il nome del cluster in cui è abilitata la federazione delle identità per i carichi di lavoro per GKE.
    • LOCATION: la località di Compute Engine per il cluster.
  2. Crea uno spazio dei nomi da utilizzare per Kubernetes ServiceAccount. Puoi anche utilizza lo spazio dei nomi default o qualsiasi spazio dei nomi esistente.

    kubectl create namespace NAMESPACE
    

    Sostituisci quanto segue:

    • NAMESPACE: il nome dello spazio dei nomi Kubernetes per Kubernetes ServiceAccount.
  3. Crea un ServiceAccount Kubernetes da utilizzare per l'applicazione. Puoi utilizzare anche qualsiasi ServiceAccount Kubernetes esistente in qualsiasi spazio dei nomi, l'account di servizio Kubernetes default.

    kubectl create serviceaccount KSA_NAME \
        --namespace NAMESPACE
    

    Sostituisci quanto segue:

    • KSA_NAME: il nome del tuo nuovo account di servizio Kubernetes.
    • NAMESPACE: il nome dello spazio dei nomi Kubernetes per Kubernetes ServiceAccount.
  4. Concedi uno dei ruoli IAM per Cloud Storage all'account di servizio di Kubernetes.

    Puoi concedere il ruolo al tuo ServiceAccount Kubernetes solo accedi a uno specifico bucket Cloud Storage utilizzando il comando seguente:

    gcloud storage buckets add-iam-policy-binding gs://BUCKET_NAME \
        --member "principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/subject/ns/NAMESPACE/sa/KSA_NAME" \
        --role "ROLE_NAME"
    

    Sostituisci quanto segue:

    • BUCKET_NAME: il nome del bucket Cloud Storage.
    • PROJECT_NUMBER: il numero numerico del progetto del tuo cluster GKE. Per trovare il numero del progetto, consulta Identificazione dei progetti.
    • PROJECT_ID: l'ID progetto del tuo cluster GKE.
    • NAMESPACE: il nome dello spazio dei nomi Kubernetes per Kubernetes ServiceAccount.
    • KSA_NAME: il nome del tuo nuovo account di servizio Kubernetes.
    • ROLE_NAME: il ruolo IAM da assegnare all'account di servizio di Kubernetes.
      • Per i carichi di lavoro di sola lettura, utilizza il ruolo Visualizzatore oggetti Storage (roles/storage.objectViewer).
      • Per i carichi di lavoro di lettura e scrittura, utilizza il ruolo Utente oggetti Storage (roles/storage.objectUser).

    Facoltativamente, puoi concedere il ruolo al tuo ServiceAccount Kubernetes per accedere a tutti i bucket Cloud Storage del progetto utilizzando il seguente comando:

    gcloud projects add-iam-policy-binding GCS_PROJECT \
        --member "principal://iam.googleapis.com/projects/PROJECT_NUMBER/locations/global/workloadIdentityPools/PROJECT_ID.svc.id.goog/subject/ns/NAMESPACE/sa/KSA_NAME" \
        --role "ROLE_NAME"
    

    Sostituisci quanto segue:

    • GCS_PROJECT: l'ID progetto dei tuoi bucket Cloud Storage.
    • PROJECT_NUMBER: il numero numerico del progetto del tuo cluster GKE. Per trovare il numero del progetto, consulta Identificazione dei progetti.
    • PROJECT_ID: l'ID progetto del tuo cluster GKE.
    • NAMESPACE: il nome dello spazio dei nomi Kubernetes per Kubernetes ServiceAccount.
    • KSA_NAME: il nome del tuo nuovo account di servizio Kubernetes.
    • ROLE_NAME: il ruolo IAM da assegnare all'account di servizio di Kubernetes.
      • Per i carichi di lavoro di sola lettura, utilizza il ruolo Visualizzatore oggetti Storage (roles/storage.objectViewer).
      • Per i carichi di lavoro di lettura e scrittura, utilizza il ruolo Utente oggetti Storage (roles/storage.objectUser).

Preparati a montare i bucket Cloud Storage FUSE

Questa sezione illustra come preparare il montaggio di Cloud Storage FUSE. nei tuoi cluster.

Specifica le annotazioni dei pod

Il driver CSI si basa sulle annotazioni dei pod per identificare se il pod utilizza volumi supportati da Cloud Storage. Se il conducente rileva le annotazioni necessarie, inserisce un container collaterale denominato gke-gcsfuse-sidecar nel pod del carico di lavoro. Le istanze Cloud Storage FUSE vengono eseguite all'interno del container collaterale e montare i bucket Cloud Storage per il carico di lavoro.

Per abilitare il driver CSI al montaggio dei bucket Cloud Storage, assicurati di specifica l'annotazione gke-gcsfuse/volumes: "true" nella specifica del pod, sotto il campo metadata. Se vuoi che i tuoi volumi supportati da Cloud Storage essere consumato da altri tipi di carichi di lavoro Kubernetes (ad esempio, Job, Deployment oppure StatefulSet), assicurati di configurare le annotazioni nel campo spec.template.metadata.annotations.

Configura le risorse per il container collaterale

Per impostazione predefinita, il container collaterale è configurato con le seguenti richieste di risorse: con limiti per le risorse non impostati:

  • 250m CPU
  • 256 MiB di memoria
  • 5 GiB di spazio di archiviazione temporaneo

Per sovrascrivere questi valori, puoi specificare l'annotazione gke-gcsfuse/[cpu-limit|memory-limit|ephemeral-storage-limit|cpu-request|memory-request|ephemeral-storage-request] come mostrato nell'esempio seguente:

apiVersion: v1
kind: Pod
metadata:
  annotations:
    gke-gcsfuse/volumes: "true"
    gke-gcsfuse/cpu-limit: "10"
    gke-gcsfuse/memory-limit: 10Gi
    gke-gcsfuse/ephemeral-storage-limit: 1Ti
    gke-gcsfuse/cpu-request: 500m
    gke-gcsfuse/memory-request: 1Gi
    gke-gcsfuse/ephemeral-storage-request: 50Gi

Per decidere la quantità di risorse da allocare, tieni presente quanto segue:

  • Se imposti solo una delle annotazioni relative alla richiesta o ai limiti di risorse, GKE applica gli stessi valori per la richiesta e il limite di risorse.
  • Se il pod del carico di lavoro utilizza più volumi Cloud Storage, il file collaterale le risorse del container sono condivise da più istanze Cloud Storage FUSE. Se questo applicabile al tuo caso, ti consigliamo di aumentare l'allocazione delle risorse per come i volumi di Cloud Storage.
  • Alloca più CPU al container collaterale se i tuoi carichi di lavoro hanno bisogno di un numero maggiore e la velocità effettiva effettiva. Una CPU insufficiente causerà la limitazione di Cloud Storage FUSE.
  • Se i carichi di lavoro devono elaborare un numero elevato di file e Cloud Storage FUSE memorizzazione nella cache dei metadati è abilitata, aumenta l'allocazione della memoria del container collaterale. Il consumo di memoria di Cloud Storage FUSE per la memorizzazione nella cache dei metadati è proporzionale il numero di file, ma non le loro dimensioni. Una memoria insufficiente causerà errori di esaurimento della memoria di Cloud Storage FUSE e l'arresto anomalo dell'applicazione del carico di lavoro.
  • Per la memorizzazione nella cache di file, Cloud Storage FUSE memorizza per impostazione predefinita i file una directory temporanea locale. Stima quanto spazio libero richiede il tuo carico di lavoro di memorizzazione nella cache e aumenta di conseguenza il limite di spazio di archiviazione temporaneo. Per scoprire di più, consulta gli attributi del volume.
  • Per le operazioni di scrittura, Cloud Storage FUSE per impostazione predefinita archivia i file in una cartella prima che i file vengano caricati nel bucket Cloud Storage. Stima di spazio libero necessario al carico di lavoro per la gestione temporanea durante la scrittura file di grandi dimensioni e aumenta il limite di spazio di archiviazione temporaneo di conseguenza. Per scoprire di più, consulta la sezione semantica di lettura/scrittura. nella documentazione GitHub di Cloud Storage FUSE.
  • Puoi utilizzare il valore "0" per annullare l'impostazione di limiti di risorse o richieste sui cluster standard. Ad esempio, l'annotazione gke-gcsfuse/memory-limit: "0" lascia il container collaterale limite di memoria vuoto con la richiesta di memoria predefinita. È utile quando non puoi decidere l'importo di risorse di cui Cloud Storage FUSE ha bisogno per i tuoi carichi di lavoro e vuoi che Cloud Storage FUSE e consumano tutte le risorse disponibili su un nodo. Dopo aver calcolato i requisiti delle risorse per Cloud Storage FUSE in base alle metriche del carico di lavoro, puoi impostare limiti appropriati.

Configura un'immagine privata per il container collaterale

Questa sezione descrive come utilizzare l'immagine container collaterale se ospiti in un Container Registry privato. Questo scenario potrebbe verificarsi se devi utilizzare per motivi di sicurezza o se il cluster ha accesso limitato nella rete internet pubblica. Per configurare e utilizzare l'immagine container del sidecar privato, segui questi passaggi:

  1. Consulta questa pagina per cercare un'immagine container collaterale pubblica compatibile.

  2. Esegui il pull nel tuo ambiente locale ed eseguine il push al Container Registry privato.

  3. Nel file manifest, specifica un container denominato gke-gcsfuse-sidecar solo con il campo image. GKE utilizzerà il file collaterale specificato dell'immagine container per prepararsi all'inserimento del container collaterale. Ecco un esempio:

apiVersion: v1
kind: Pod
metadata:
  annotations:
    gke-gcsfuse/volumes: "true"
spec:
  containers:
  - name: gke-gcsfuse-sidecar
    image: PRIVATE_REGISTRY/gcs-fuse-csi-driver-sidecar-mounter:PRIVATE_IMAGE_TAG
  - name: main # your main workload container.

Sostituisci quanto segue:

  • PRIVATE_REGISTRY: il tuo Container Registry privato.
  • PRIVATE_IMAGE_TAG: il tuo container sidecar privato .

Configura un volume del buffer di scrittura personalizzato per il container collaterale

Questa sezione descrive come configurare un volume di buffer personalizzato per il buffering di scrittura di Cloud Storage FUSE. Questo scenario potrebbe verificarsi se devi sostituire quello predefinito Volume emptyDir per Cloud Storage FUSE per collocare i file in operazioni di scrittura. Puoi specificare qualsiasi tipo di spazio di archiviazione supportato da GKE, ad esempio un PersistentVolumeClaim, e GKE utilizzerà il volume specificato per il buffering di scrittura dei file. Questo è utile se devi scrivere file di dimensioni superiori a 10 GiB su cluster Autopilot. Per utilizzare il volume del buffer personalizzato, devi specificare un valore fsGroup diverso da zero. L'esempio seguente mostra come utilizzare una PVC predefinita come volume del buffer:

apiVersion: v1
kind: Pod
metadata:
  annotations:
    gke-gcsfuse/volumes: "true"
spec:
  securityContext:
    fsGroup: FS_GROUP
  containers:
  ...
  volumes:
  - name: gke-gcsfuse-buffer
    persistentVolumeClaim:
      claimName: BUFFER_VOLUME_PVC

Sostituisci quanto segue:

  • FS_GROUP: l'ID fsGroup.
  • BUFFER_VOLUME_PVC: il nome predefinito dell'oggetto PVC.

Configura un volume personalizzato della cache di lettura per il container collaterale

Questa sezione descrive come configurare un volume di cache personalizzato per la memorizzazione nella cache di lettura di Cloud Storage FUSE. Questo scenario potrebbe verificarsi se devi sostituire quello predefinito Volume emptyDir per Cloud Storage FUSE per memorizzare nella cache i file nelle operazioni di lettura. Puoi specificare qualsiasi tipo di spazio di archiviazione supportato da GKE, ad esempio un PersistentVolumeClaim, e GKE utilizzerà il volume specificato per la memorizzazione nella cache dei file. Questo è utile se devi memorizzare nella cache file più grandi di 10 GiB su cluster Autopilot. Per utilizzare il volume della cache personalizzato, devi specificare un valore fsGroup diverso da zero. L'esempio seguente mostra come utilizzare una PVC predefinita come volume della cache:

apiVersion: v1
kind: Pod
metadata:
  annotations:
    gke-gcsfuse/volumes: "true"
spec:
  securityContext:
    fsGroup: FS_GROUP
  containers:
  ...
  volumes:
  - name: gke-gcsfuse-cache
    persistentVolumeClaim:
      claimName: CACHE_VOLUME_PVC

Sostituisci quanto segue:

  • FS_GROUP: l'ID fsGroup.
  • CACHE_VOLUME_PVC: il nome predefinito dell'oggetto PVC.

Esegui il provisioning del tuo volume come volume temporaneo CSI

I volumi temporanei CSI supportati dai bucket Cloud Storage sono collegati al pod lifecycle. Con questo approccio al provisioning, non è necessario mantenere Gli oggetti PersistentVolume e PersistentVolumeClaim associati Bucket Cloud Storage dopo la terminazione del pod.

Consuma il volume di archiviazione temporanea CSI in un pod

  1. Salva il seguente manifest YAML:

    apiVersion: v1
    kind: Pod
    metadata:
      name: gcs-fuse-csi-example-ephemeral
      namespace: NAMESPACE
      annotations:
        gke-gcsfuse/volumes: "true"
    spec:
      terminationGracePeriodSeconds: 60
      containers:
      - image: busybox
        name: busybox
        command: ["sleep"]
        args: ["infinity"]
        volumeMounts:
        - name: gcs-fuse-csi-ephemeral
          mountPath: /data
          readOnly: true
      serviceAccountName: KSA_NAME
      volumes:
      - name: gcs-fuse-csi-ephemeral
        csi:
          driver: gcsfuse.csi.storage.gke.io
          readOnly: true
          volumeAttributes:
            bucketName: BUCKET_NAME
            mountOptions: "implicit-dirs"
            gcsfuseLoggingSeverity: warning
    

    L'esempio precedente mostra come specificare il bucket Cloud Storage in linea nel manifest del pod. L'esempio include i seguenti campi:

    • metadata.annotations: l'annotazione gke-gcsfuse/volumes: "true" è obbligatoria. Consulta Configurazione delle risorse per il container collaterale per annotazioni facoltative.
    • spec.terminationGracePeriodSeconds: facoltativo. Il valore predefinito è 30. Se devi scrivere file di grandi dimensioni nel bucket Cloud Storage, aumenta questo valore per assicurarti Cloud Storage FUSE ha tempo sufficiente per lo svuotamento dei dati dopo l'applicazione esce. Per saperne di più, vedi Best practice di Kubernetes: chiusura con tolleranza.
    • spec.serviceAccountName: utilizza lo stesso ServiceAccount Kubernetes dell' Configura l'accesso ai bucket Cloud Storage utilizzando la federazione delle identità per i carichi di lavoro GKE per GKE.
    • spec.volumes[n].csi.driver: usa gcsfuse.csi.storage.gke.io come Nome driver CSI.
    • spec.volumes[n].csi.volumeAttributes.bucketName: specifica il tuo Nome del bucket Cloud Storage FUSE. Puoi specificare un trattino basso (_) per montare tutti bucket a cui Kubernetes ServiceAccount può accedere. Per saperne di più, consulta Montaggio dinamico nella documentazione di Cloud Storage FUSE.
    • spec.volumes[n].csi.volumeAttributes.mountOptions: facoltativo. Superato opzioni di montaggio in Cloud Storage FUSE. Specifica i flag in uno stringhe separate da virgole, senza spazi.
    • spec.volumes[n].csi.volumeAttributes: facoltativo. Passa ad altro attributi di volume a Cloud Storage FUSE.
    • spec.volumes[n].csi.readOnly: facoltativo. Specifica true se tutto il volume sono di sola lettura.
    • spec.containers[n].volumeMounts[m].readOnly: facoltativo. Specifica true se solo il montaggio di un volume specifico è di sola lettura.
  2. Applica il manifest al cluster:

    kubectl apply -f FILE_PATH
    

    Sostituisci FILE_PATH con il percorso del file YAML.

Utilizza il volume di archiviazione temporanea CSI in un carico di lavoro di un job

  1. Salva il seguente manifest YAML:

    apiVersion: batch/v1
    kind: Job
    metadata:
      name: gcs-fuse-csi-job-example
      namespace: NAMESPACE
    spec:
      template:
        metadata:
          annotations:
            gke-gcsfuse/volumes: "true"
        spec:
          serviceAccountName: KSA_NAME
          containers:
          - name: writer
            image: busybox
            command:
              - "/bin/sh"
              - "-c"
              - touch /data/test && echo $(date) >> /data/test && sleep 10
            volumeMounts:
            - name: gcs-fuse-csi-ephemeral
              mountPath: /data
          - name: reader
            image: busybox
            command:
              - "/bin/sh"
              - "-c"
              - sleep 10 && cat /data/test
            volumeMounts:
            - name: gcs-fuse-csi-ephemeral
              mountPath: /data
              readOnly: true
          volumes:
          - name: gcs-fuse-csi-ephemeral
            csi:
              driver: gcsfuse.csi.storage.gke.io
              volumeAttributes:
                bucketName: BUCKET_NAME
          restartPolicy: Never
      backoffLimit: 1
    

    Sostituisci quanto segue:

    Il manifest esegue il deployment di un job che utilizza un FUSE di Cloud Storage. tramite un volume temporaneo CSI.

  2. Applica il manifest al cluster:

    kubectl apply -f FILE_PATH
    

    Sostituisci FILE_PATH con il percorso del file YAML.

Se utilizzi il driver CSI in un carico di lavoro Job o se il pod RestartPolicy è Never, il container collaterale uscirà automaticamente dopo tutti gli altri vengono chiusi i container dei carichi di lavoro.

Per altri esempi, consulta la sezione Applicazioni di esempio nella documentazione del progetto GitHub.

Esegui il provisioning del volume utilizzando il provisioning statico

Con il provisioning statico si creano uno o più oggetti PersistentVolume (PV) contenenti i dettagli dei completamente gestito di Google Cloud. I pod nei cluster possono quindi consumare lo spazio di archiviazione PersistentVolumeClaims (PVC).

crea un PersistentVolume

  1. Salva il seguente manifest YAML:

    apiVersion: v1
    kind: PersistentVolume
    metadata:
      name: gcs-fuse-csi-pv
    spec:
      accessModes:
      - ReadWriteMany
      capacity:
        storage: 5Gi
      storageClassName: example-storage-class
      mountOptions:
        - implicit-dirs
      csi:
        driver: gcsfuse.csi.storage.gke.io
        volumeHandle: BUCKET_NAME
        volumeAttributes:
          gcsfuseLoggingSeverity: warning
    

    Il manifest di esempio mostra come definire un PersistentVolume di archiviazione dei bucket Cloud Storage. L'esempio include i seguenti campi:

    • spec.csi.driver: usa gcsfuse.csi.storage.gke.io come nome del driver CSI.
    • spec.csi.volumeHandle: specifica il nome del bucket Cloud Storage. Puoi passare un trattino basso (_) per montare tutti i bucket di cui Kubernetes ServiceAccount configurate per l'accesso. Per ulteriori informazioni, vedi Montaggio dinamico nella documentazione di Cloud Storage FUSE.
    • spec.mountOptions: facoltativo. Passa le opzioni di montaggio a Cloud Storage FUSE.
    • spec.csi.volumeAttributes: facoltativo. Passa gli attributi di volume a Cloud Storage FUSE.
  2. Applica il manifest al cluster:

    kubectl apply -f FILE_PATH
    

    Sostituisci FILE_PATH con il percorso del file YAML.

crea un PersistentVolumeClaim

  1. Salva il seguente manifest YAML:

    apiVersion: v1
    kind: PersistentVolumeClaim
    metadata:
      name: gcs-fuse-csi-static-pvc
      namespace: NAMESPACE
    spec:
      accessModes:
      - ReadWriteMany
      resources:
        requests:
          storage: 5Gi
      volumeName: gcs-fuse-csi-pv
      storageClassName: example-storage-class
    

    Il manifest di esempio mostra come definire un oggetto per vincolare il PersistentVolume. L'esempio include i seguenti campi:

    • metadata.namespace: specifica lo spazio dei nomi PersistentVolumeClaim coerente con lo spazio dei nomi del carico di lavoro.
    • spec.volumeName: specifica il nome del PersistentVolume.

    Per associare un PersistentVolume a un PersistentVolumeClaim, assicurati di seguire queste linee guida:

    • I campi spec.storageClassName nei manifest PV e PVC devono corrispondere. storageClassName non deve fare riferimento a un oggetto StorageClass esistente. Per vincolare la rivendicazione in un volume, puoi utilizzare il nome che preferisci, ma non è possibile lasciarlo vuoto.
    • I campi spec.accessModes nei manifest PV e PVC devono corrispondere.
    • spec.capacity.storage sul manifest del PersistentVolume deve corrispondere spec.resources.requests.storage sul manifest di PersistentVolumeClaim. Poiché i bucket Cloud Storage non hanno limiti di dimensione, puoi inserire qualsiasi numero per la capacità, ma non può essere vuoto.
  2. Applica il manifest al cluster:

    kubectl apply -f FILE_PATH
    

    Sostituisci FILE_PATH con il percorso del file YAML.

utilizza il volume da un PersistentVolumeClaim

  1. Salva il seguente manifest YAML:

    apiVersion: v1
    kind: Pod
    metadata:
      name: gcs-fuse-csi-example-static-pvc
      namespace: NAMESPACE
      annotations:
        gke-gcsfuse/volumes: "true"
    spec:
      containers:
      - image: busybox
        name: busybox
        command: ["sleep"]
        args: ["infinity"]
        volumeMounts:
        - name: gcs-fuse-csi-static
          mountPath: /data
          readOnly: true
      serviceAccountName: KSA_NAME
      volumes:
      - name: gcs-fuse-csi-static
        persistentVolumeClaim:
          claimName: gcs-fuse-csi-static-pvc
          readOnly: true
    

    L'esempio mostra come definire un pod che utilizza una Bucket Cloud Storage FUSE tramite un PersistentVolumeClaim. L'esempio include i seguenti campi:

  2. Applica il manifest al cluster:

    kubectl apply -f FILE_PATH
    

    Sostituisci FILE_PATH con il percorso del file YAML.

Per altri esempi, consulta la sezione Applicazioni di esempio nella documentazione del progetto GitHub.

Consuma i tuoi volumi con la memorizzazione nella cache dei file abilitata

Per impostazione predefinita, la funzionalità di memorizzazione nella cache dei file è disabilitata su GKE. Per attivare e controllare la memorizzazione nella cache dei file, utilizza l'attributo volume fileCacheCapacity.

GKE utilizza un volume emptyDir per Cloud Storage FUSE di memorizzazione nella cache supportata dal disco di avvio della VM del nodo. Se attivi SSD locale sul nodo, GKE usa l'SSD locale per eseguire il backup di emptyDir volume.

Puoi configurare un volume personalizzato della cache di lettura per il container collaterale. per sostituire il volume emptyDir predefinito per la memorizzazione nella cache dei file nelle operazioni di lettura. Per le famiglie di VM con CPU e GPU che supportano gli SSD locali, consigliamo di utilizzare lo spazio di archiviazione SSD locale. Per le famiglie TPU o Autopilot, consigliamo di usare Disco permanente bilanciato o disco permanente SSD.

Utilizza un volume di archiviazione temporanea CSI con memorizzazione nella cache dei file abilitata

esegui il deployment di un pod che utilizza un bucket Cloud Storage FUSE tramite un volume temporaneo CSI. con la memorizzazione nella cache di file, segui questi passaggi:

  1. Crea un cluster o un pool di nodi con archiviazione temporanea supportata da SSD locali.

    Segui la documentazione di GKE per creare un cluster o un pool di nodi con archiviazione temporanea supportata da SSD locali.

  2. Salva il seguente manifest YAML:

    apiVersion: v1
    kind: Pod
    metadata:
      name: gcs-fuse-csi-file-cache-example
      namespace: NAMESPACE
      annotations:
        gke-gcsfuse/volumes: "true"
        gke-gcsfuse/ephemeral-storage-limit: "50Gi"
    spec:
      nodeSelector:
        cloud.google.com/gke-ephemeral-storage-local-ssd: "true"
      restartPolicy: Never
      initContainers:
      - name: data-loader
        image: gcr.io/google.com/cloudsdktool/google-cloud-cli:slim
        resources:
          limits:
            cpu: 500m
            memory: 1Gi
          requests:
            cpu: 500m
            memory: 1Gi
        command:
          - "/bin/sh"
          - "-c"
          - |
            mkdir -p /test_files
            for i in $(seq 1 1000); do dd if=/dev/zero of=/test_files/file_$i.txt bs=1024 count=64; done
            gsutil -m cp -r /test_files gs://BUCKET_NAME
      containers:
      - name: data-validator
        image: busybox
        resources:
          limits:
            cpu: 500m
            memory: 512Mi
          requests:
            cpu: 500m
            memory: 512Mi
        command:
          - "/bin/sh"
          - "-c"
          - |
            echo "first read with cache miss"
            time cat /data/test_files/file_* > /dev/null
    
            echo "second read from local cache"
            time cat /data/test_files/file_* > /dev/null
        volumeMounts:
        - name: gcs-fuse-csi-ephemeral
          mountPath: /data
      serviceAccountName: KSA_NAME
      volumes:
      - name: gcs-fuse-csi-ephemeral
        csi:
          driver: gcsfuse.csi.storage.gke.io
          volumeAttributes:
            bucketName: BUCKET_NAME
            mountOptions: "implicit-dirs"
            fileCacheCapacity: "10Gi"
    

    Sostituisci quanto segue:

    Il container di inizializzazione data-loader genera 1000 file di dimensioni pari a 64 KiB. carica i file in un bucket Cloud Storage. Il container principale data-validator legge tutti i file dal bucket due volte e registra la durata.

  3. Applica il manifest al cluster:

    kubectl apply -f FILE_PATH
    

    Sostituisci FILE_PATH con il percorso del file YAML.

  4. Per visualizzare l'output del log, esegui questo comando:

    kubectl logs -n NAMESPACE gcs-fuse-csi-file-cache-example -c data-validator
    

    Sostituisci NAMESPACE con lo spazio dei nomi del tuo carico di lavoro.

    L'output è simile al seguente:

    first read with cache miss
    real    0m 54.68s
    ...
    second read from local cache
    real    0m 0.38s
    ...
    

    L'output mostra che la seconda lettura con la cache locale è molto più veloce di la prima lettura con fallimento della cache.

Configura il modo in cui vengono montati i bucket Cloud Storage FUSE

Questa sezione descrive come configurare i volumi Cloud Storage FUSE.

Opzioni di montaggio

Il driver CSI di Cloud Storage FUSE supporta le opzioni di montaggio per configurare la modalità I bucket Cloud Storage sono montati sul file system locale. Per per l'elenco completo delle opzioni di montaggio supportate, vedi consulta la documentazione sull'interfaccia a riga di comando gcsfuse.

Puoi specificare i flag di montaggio nei seguenti modi:

  • Nel campo spec.mountOptions di un manifest PersistentVolume, se il provisioning statico.
  • Nel campo spec.volumes[n].csi.volumeAttributes.mountOptions, se e usare i volumi temporanei CSI.

Attributi del volume

Il driver CSI di Cloud Storage FUSE non consente di specificare direttamente File di configurazione di Cloud Storage FUSE. Puoi configurare alcuni dei campi del file di configurazione utilizzando i seguenti attributi di volume. I valori vengono convertiti nei campi del file di configurazione.

  • gcsfuseLoggingSeverity

    • Descrizione: la gravità dei log che vuoi che vengano generati da Cloud Storage FUSE. espresso come enum. Se usi già debug_fuse, debug_fs, o debug_gcs, questa nuova configurazione verrà impostata automaticamente su trace. Questo attributo del volume viene convertito nel campo del file di configurazione logging:severity.

    • Valori validi (ordinati dalla gravità più bassa a quella più alta):

      • trace
      • debug
      • info
      • warning
      • error
    • Valore predefinito: info.

  • fileCacheCapacity

    • Descrizione: la dimensione massima utilizzabile dalla cache dei file. Se un valore diverso da zero questo attributo di volume consente la memorizzazione nella cache dei file in Cloud Storage FUSE. Questo attributo del volume viene convertito nel campo del file di configurazione file-cache:max-size-mb.

    • Valori validi:

      • i valori Quantità, ad esempio 500Mi, 10Gi.
      • "-1": per utilizzare l'intera capacità disponibile del volume di cache.
      • "0": la cache del file è disattivata.
    • Valore predefinito: "0".

  • fileCacheForRangeRead

    • Descrizione: indica se l'oggetto completo deve essere scaricato in modo asincrono. e archiviato nella directory della cache di Cloud Storage FUSE al termine della prima lettura da un offset diverso da zero. Deve essere impostato su "true" se prevedi di eseguire diverse letture casuali o letture parziali. Questo attributo del volume viene convertito nel campo del file di configurazione file-cache:cache-file-for-range-read.

    • Valori validi:

      • Valori booleani in formato stringa: "true", "false".
    • Valore predefinito: "false".

  • metadataStatCacheCapacity

    • Descrizione: la dimensione massima utilizzabile dalla cache delle statistiche. La cache delle statistiche è sempre interamente conservata in memoria. Se usi già l'opzione di montaggio stat-cache-capacity, il valore sarà comunque rispettato e verrà tradotto in modo appropriato in questa nuova configurazione. Questo attributo del volume viene convertito nel campo del file di configurazione metadata-cache:stat-cache-max-size-mb.

    • Valori validi:

      • i valori Quantità, ad esempio 500Mi, 1Gi.
      • "-1": per consentire alla cache delle statistiche di utilizzare la memoria necessaria.
      • "0": la cache delle statistiche è disabilitata.
      • Utilizza il valore predefinito 32Mi se il carico di lavoro riguarda fino a 20.000 file. Se il carico di lavoro è superiore a 20.000 file, aumenta la dimensione in base ai valori di 10 MiB per ogni 6000 file aggiuntivi, una media di ~1500 byte per file.
    • Valore predefinito: 32Mi.

  • metadataTypeCacheCapacity

    • Descrizione: la dimensione massima per directory che il tipo di cache può utilizzare. La cache dei tipi è sempre interamente conservata in memoria. Questo attributo del volume viene convertito nel campo del file di configurazione metadata-cache:type-cache-max-size-mb.

    • Valori validi:

      • i valori Quantità, ad esempio 500Mi, 1Gi.
      • "-1": per consentire al tipo di cache di utilizzare la memoria necessaria.
      • "0": il tipo di cache è disabilitato.
      • Utilizza il valore predefinito 4Mi se il numero massimo di file in un la singola directory del bucket che stai montando contiene al massimo 20.000 file. Se il numero massimo di file all'interno di una singola directory che stai montando contiene più di 20.000 file, aumenta la dimensione di 1 MiB ogni 5000 file, in media circa 200 byte per file.
    • Valore predefinito: 4Mi.

  • metadataCacheTTLSeconds

    • Descrizione: la durata (TTL) in secondi delle voci di metadati memorizzate nella cache. Se usi già le opzioni di montaggio stat-cache-ttl o type-cache-ttl, i valori continueranno a essere rispettati e verranno tradotti in modo appropriato in questa nuova configurazione. Questo attributo del volume viene convertito nel campo del file di configurazione metadata-cache:ttl-secs.

    • Valori validi:

      • Valori interi in formato stringa, ad esempio "600".
      • "-1": ignora una scadenza TTL e pubblica il file dalla cache ogni volta che è disponibile.
      • "0": assicura che venga letto il file più aggiornato. Utilizzo un valore 0 invia una chiamata di metadati Get per verificare che l'oggetto del file nella cache corrisponda a quanto archiviato in Cloud Storage.
    • Valore predefinito: "60".

Puoi specificare gli attributi del volume nei seguenti modi:

  • Nel campo spec.csi.volumeAttributes di un manifest PersistentVolume, se il provisioning statico.
  • Nel campo spec.volumes[n].csi.volumeAttributes, se e usare i volumi temporanei CSI.

Considerazioni

Tieni presente le seguenti considerazioni quando configuri i montaggi:

  • I seguenti flag non sono consentiti: app-name, temp-dir, foreground, log-file, log-format, key-file, token-url e reuse-token-from-url.
  • Cloud Storage FUSE non rende visibili le directory implicite per impostazione predefinita. A rendi visibili queste directory, puoi attivare il flag di montaggio implicit-dirs. Per ulteriori informazioni, consulta File e directory nella documentazione GitHub di Cloud Storage FUSE.
  • Se utilizzi un contesto di sicurezza per il pod o container oppure, se l'immagine container utilizza un utente o un gruppo non root, devi impostare i flag di montaggio uid e gid. Devi utilizzare anche file-mode e dir-mode monta i flag per impostare le autorizzazioni del file system. Tieni presente che non puoi eseguire i comandi chmod, chown o chgrp su un File system Cloud Storage FUSE, in modo da montare uid, gid, file-mode e dir-mode sono necessari per fornire accesso a un utente o un gruppo non root.
  • Se vuoi solo montare una directory nel bucket anziché l'intero bucket, passa il percorso relativo della directory utilizzando only-dir=relative/path/to/the/bucket/root flag.
  • Per ottimizzare il comportamento della memorizzazione nella cache di Cloud Storage FUSE, configura gli attributi di volume. Per maggiori dettagli, consulta la documentazione sulla memorizzazione nella cache di Cloud Storage FUSE.
  • Se devi specificare il numero massimo di connessioni TCP consentite per server, puoi specificare questo numero massimo utilizzando il flag max-conns-per-host. Il numero massimo di connessioni TCP che definisci diventa effettivo quando --client-protocol è impostato su http1. Il valore predefinito è 0, che indica nessun limite per le connessioni TCP (limitate dalle specifiche della macchina).
  • Se devi configurare le opzioni di montaggio del kernel Linux, puoi passare utilizzando il flag o. Ad esempio, se non vuoi consentire l'esecuzione diretta di file binari sul file system montato, imposta il flag o=noexec. Ogni opzione richiede un flag separato, ad esempio o=noexec,o=noatime. Sono consentite solo le seguenti opzioni: exec, noexec, atime, noatime, sync, async e dirsync.
  • Se devi risolvere problemi di Cloud Storage FUSE, imposta debug_fuse, debug_fs e debug_gcs. Se viene specificata una delle tre opzioni, l'attributo del volume gcsfuseLoggingSeverity viene impostato automaticamente su trace.
  • Il driver CSI di Cloud Storage FUSE non consente di modificare il campo cache-dir nella File di configurazione di Cloud Storage FUSE, utilizza l'attributo di volume fileCacheCapacity per attivare o disattivare la memorizzazione nella cache dei file. Per sostituire il volume emptyDir predefinito per la memorizzazione nella cache dei file: puoi configurare un volume della cache personalizzato per il container collaterale.

Disabilita il driver CSI di Cloud Storage FUSE

Non puoi disabilitare il driver CSI di Cloud Storage FUSE nei cluster Autopilot.

Puoi disabilitare il driver CSI di Cloud Storage FUSE su un ambiente Standard esistente utilizzando Google Cloud CLI.

gcloud container clusters update CLUSTER_NAME \
    --update-addons GcsFuseCsiDriver=DISABLED

Sostituisci CLUSTER_NAME con il nome del tuo cluster.

Risoluzione dei problemi

Per risolvere i problemi riscontrati durante l'utilizzo del driver CSI di Cloud Storage FUSE, consulta la Guida alla risoluzione dei problemi nella documentazione del progetto GitHub.

Passaggi successivi