Cloud Storage-Buckets als sitzungsspezifische CSI-Volumes bereitstellen

In dieser Anleitung erfahren Sie, wie Sie sitzungsspezifische CSI-Volumes verwenden, die von Ihren Cloud Storage-Buckets unterstützt werden, um Speicherressourcen für Ihre Kubernetes Pods oder Jobs in Google Kubernetes Engine (GKE) automatisch zu verwalten. Sitzungsspezifische CSI-Volumes sind an den Pod- oder Joblebenszyklus gebunden. Sie müssen PersistentVolume- und PersistentVolumeClaim-Objekte nicht manuell verarbeiten.

Diese Anleitung richtet sich an Plattformadministratoren und -operatoren, die die Speicherverwaltung für ihre GKE-Anwendungen vereinfachen möchten.

Machen Sie sich vor dem Lesen dieser Seite mit sitzungsspezifischen CSI-Volumes, Kubernetes-Pods und -Jobs sowie Cloud Storage-Buckets vertraut.

Wenn Sie bereits mit PersistentVolumes vertraut sind und Konsistenz mit Ihren vorhandenen Bereitstellungen wünschen, die auf diesem Ressourcentyp basieren, lesen Sie Cloud Storage-Buckets als nichtflüchtige Volumes bereitstellen.

Hinweis

Prüfen Sie, ob die folgenden Voraussetzungen erfüllt sind:

So funktioniert sitzungsspezifischer CSI-Speicher für Cloud Storage-Buckets

Sitzungsspezifische CSI-Volumes vereinfachen die Speicherverwaltung für Ihre Anwendungen in GKE. Sie definieren sitzungsspezifische CSI-Volumes direkt in der Pod- oder Jobspezifikation. Durch die Verwendung von sitzungsspezifischen CSI-Volumes sind keine separaten PersistentVolume- und PersistentVolumeClaim-Objekte erforderlich.

Die Verwendung eines sitzungsspezifischen CSI-Volumes umfasst die folgenden Vorgänge:

  1. Speicherdefinition: Sie geben den Speicher in der YAML -Datei des Pods oder Jobs an, einschließlich des zu verwendenden CSI-Treibers und aller erforderlichen Parameter. Für den CSI-Treiber für Cloud Storage FUSE geben Sie den Bucket-Namen und andere relevante Details an.

    Optional können Sie die Leistung Ihres CSI-Treibers mit dem Datei-Caching optimieren. Datei-Caching kann die App-Leistung von GKE verbessern, indem häufig aufgerufene Cloud Storage-Dateien auf einer schnelleren Festplatte zwischengespeichert werden.

    Außerdem können Sie die Funktion für den parallelen Download verwenden, um das Lesen großer Dateien aus Cloud Storage für Downloads mit mehreren Threads zu beschleunigen. Mit dieser Funktion können Sie die Ladezeiten von Modellen verbessern, insbesondere bei Lesevorgängen von mehr als 1 GB.

  2. Treiberaufruf: Wenn Sie den Pod oder Job erstellen, erkennt GKE die Anfrage für das sitzungsspezifische Volume und ruft den CSI-Treiber für Cloud Storage FUSE auf.

  3. Volume-Bereitstellung und -Anhängen: Der CSI-Treiber stellt das sitzungsspezifische CSI-Volume bereit (das auf den zugrunde liegenden Cloud Storage-Bucket verweist) und macht es für den Pod oder Job verfügbar, sodass Ihre Anwendung darauf zugreifen kann. Mit Bereitstellungsoptionen können Sie die Bereitstellung von Buckets im Dateisystem optimieren. Sie können auch Volume-Attribute verwenden, um ein bestimmtes Verhalten des CSI-Treibers für Cloud Storage FUSE zu konfigurieren.

  4. Lebenszyklusverwaltung: Das sitzungsspezifische Volume ist für die Lebensdauer von dem Pod oder Job vorhanden. Wenn der Pod gelöscht wird oder der Job abgeschlossen ist, übernimmt der CSI-Treiber automatisch die Bereinigung und die Bereitstellung des Volumes.

Sitzungsspezifisches CSI-Volume anhängen

Folgen Sie dieser Anleitung, je nachdem, ob Sie das sitzungsspezifische CSI-Volume an einen Pod oder Job anhängen möchten.

Pod

So hängen Sie das sitzungsspezifische CSI-Volume in einem Pod an:

  1. Erstellen Sie ein Pod-YAML-Manifest mit der folgenden Spezifikation:

    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"

    Ersetzen Sie die folgenden Werte:

    • NAMESPACE: Der Kubernetes-Namespace, in dem Sie den Pod bereitstellen möchten.
    • KSA_NAME: Der Name des Kubernetes -Dienstkontos, das Sie beim Konfigurieren des Zugriffs auf die Cloud Storage-Buckets angegeben haben.
    • BUCKET_NAME: Der Name des Cloud Storage-Bucket, den Sie beim Konfigurieren des Zugriffs auf die Cloud Storage-Buckets angegeben haben. Sie können einen Unterstrich (_) angeben, um alle Buckets bereitzustellen, auf die das Kubernetes-Dienstkonto zugreifen kann. Weitere Informationen finden Sie unter Dynamische Bereitstellung in der Dokumentation zu Cloud Storage FUSE.

    Das Beispielmanifest zeigt diese erforderlichen Einstellungen:

    • metadata.annotations: Die Annotation gke-gcsfuse/volumes: "true" ist erforderlich. Optionale Annotationen finden Sie unter Sidecar-Container konfigurieren.
    • spec.volumes[n].csi.driver: Verwenden Sie gcsfuse.csi.storage.gke.io als Namen für den CSI-Treiber.

    Optional können Sie diese Variablen anpassen:

    • spec.terminationGracePeriodSeconds: Standardmäßig ist dieser Wert auf 30 festgelegt. Wenn Sie große Dateien in den Cloud Storage-Bucket schreiben müssen, erhöhen Sie diesen Wert, damit Cloud Storage FUSE genügend Zeit hat, um die Daten nach dem Beenden Ihrer Anwendung zu leeren. Weitere Informationen finden Sie im Blog Kubernetes best practices: terminating with grace.
    • spec.volumes[n].csi.volumeAttributes.mountOptions: Übergeben Sie Bereitstellungsoptionen an Cloud Storage FUSE. Geben Sie die Flags in einem String durch Kommas getrennt ohne Leerzeichen an.
    • spec.volumes[n].csi.volumeAttributes: Übergeben Sie zusätzliche Volume-Attribute an Cloud Storage FUSE.
    • spec.volumes[n].csi.readOnly: Geben Sie „true“ an, wenn alle Volume-Bereitstellungen schreibgeschützt sind.
    • spec.containers[n].volumeMounts[m].readOnly: Geben Sie „true“ an, wenn nur eine bestimmte Volume-Bereitstellung schreibgeschützt ist.

  2. Führen Sie den folgenden Befehl aus, um das Manifest auf Ihren Cluster anzuwenden:

    kubectl apply -f FILE_PATH

    Ersetzen Sie FILE_PATH durch den Pfad zu Ihrer YAML-Datei.

Pod (Datei-Caching)

So hängen Sie das sitzungsspezifische CSI-Volume mit Datei-Caching in einem Pod an:

  1. Erstellen Sie einen Cluster oder Knotenpool mit sitzungsspezifischem lokalen SSD-Speicher. Folgen Sie dazu der Anleitung unter Cluster oder Knotenpool mit sitzungsspezifischem lokalen SSD-Speicher erstellen.

  2. Erstellen Sie ein Pod-YAML-Manifest mit der folgenden Spezifikation:

    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
        gcloud storage cp /test_files gs://BUCKET_NAME --recursive
  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,file-cache:max-size-mb:-1"

    Ersetzen Sie die folgenden Werte:

    • NAMESPACE: Der Kubernetes-Namespace, in dem Sie den Pod bereitstellen möchten.
    • KSA_NAME: Der Name des Kubernetes Dienstkontos, das Sie beim Konfigurieren des Zugriffs auf die Cloud Storage-Buckets angegeben haben.

    • BUCKET_NAME: Der Name des Cloud Storage-Bucket, den Sie beim Konfigurieren des Zugriffs auf die Cloud Storage-Buckets angegeben haben. Sie können einen Unterstrich (_) angeben, um alle Buckets bereitzustellen, auf die das Kubernetes-Dienstkonto zugreifen kann. Weitere Informationen finden Sie unter Dynamische Bereitstellung in der Dokumentation zu Cloud Storage FUSE.

      Im Beispielmanifest generiert der Init-Container „data-loader“ 1.000 Dateien mit einer Größe von 64 KiB und lädt sie in einen Cloud Storage-Bucket hoch. Der Hauptcontainer data-validator liest alle Dateien zweimal aus dem Bucket und protokolliert die Dauer.

  3. Führen Sie den folgenden Befehl aus, um das Manifest auf Ihren Cluster anzuwenden:

    kubectl apply -f FILE_PATH

    Ersetzen Sie FILE_PATH durch den Pfad zu Ihrer YAML-Datei.

  4. Führen Sie folgenden Befehl aus, um sich die Logausgabe anzeigen zu lassen:

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

    Ersetzen Sie NAMESPACE durch den Namespace Ihrer Arbeitslast.

    Die Ausgabe sollte in etwa so aussehen:

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

    Die Ausgabe zeigt, dass der zweite Lesevorgang mit lokalem Cache viel schneller erfolgt als der erste Lesevorgang mit Cache-Fehler.

Pod (paralleler Download)

So hängen Sie das sitzungsspezifische CSI-Volume mit parallelem Download in einem Pod an:

  1. Erstellen Sie ein Pod-YAML-Manifest mit der folgenden Spezifikation:

    apiVersion: v1
kind: Pod
metadata:
  name: gcs-fuse-csi-example-ephemeral 
  namespace: NAMESPACE
  annotations:
    gke-gcsfuse/volumes: "true"
    gke-gcsfuse/ephemeral-storage-limit: "50Gi" 
spec:
  containers:
  ...
  volumes:
  - name: gcs-fuse-csi-ephemeral 
    csi:
      driver: gcsfuse.csi.storage.gke.io
      volumeAttributes:
        bucketName: BUCKET_NAME
        mountOptions: "implicit-dirs,file-cache:enable-parallel-downloads:true,file-cache:max-size-mb:-1"
        fileCacheCapacity: "-1"

    Ersetzen Sie die folgenden Werte:

    • NAMESPACE: Der Kubernetes-Namespace, in dem Sie den Pod bereitstellen möchten.
    • BUCKET_NAME: Der Name des Cloud Storage-Bucket, den Sie beim Konfigurieren des Zugriffs auf die Cloud Storage-Buckets angegeben haben. Sie können einen Unterstrich (_) angeben, um alle Buckets bereitzustellen, auf die das Kubernetes-Dienstkonto zugreifen kann. Weitere Informationen finden Sie unter Dynamische Bereitstellung in der Dokumentation zu Cloud Storage FUSE.

  2. Führen Sie den folgenden Befehl aus, um das Manifest auf Ihren Cluster anzuwenden:

    kubectl apply -f FILE_PATH

    Ersetzen Sie FILE_PATH durch den Pfad zu Ihrer YAML-Datei.

Job

So hängen Sie das sitzungsspezifische CSI-Volume in einem Job an:

  1. Erstellen Sie ein Job-YAML-Manifest mit der folgenden Spezifikation:

    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

    Ersetzen Sie die folgenden Werte:

    • NAMESPACE: Der Kubernetes-Namespace, in dem Sie den Pod bereitstellen.
    • KSA_NAME: Der Name des Kubernetes Dienstkontos, das Sie beim Konfigurieren des Zugriffs auf die Cloud Storage-Buckets angegeben haben.
    • BUCKET_NAME: Der Name des Cloud Storage-Bucket, den Sie beim Konfigurieren des Zugriffs auf die Cloud Storage-Buckets angegeben haben. Sie können einen Unterstrich (_) angeben, um alle Buckets bereitzustellen, auf die das Kubernetes-Dienstkonto zugreifen kann. Weitere Informationen finden Sie unter Dynamische Bereitstellung in der Dokumentation zu Cloud Storage FUSE.

    Das Beispielmanifest zeigt diese erforderlichen Einstellungen:

    • metadata.annotations: Die Annotation gke-gcsfuse/volumes: "true" ist erforderlich. Optionale Annotationen finden Sie unter Sidecar-Container konfigurieren.
    • spec.volumes[n].csi.driver: Verwenden Sie gcsfuse.csi.storage.gke.io als Namen für den CSI-Treiber.

    Optional können Sie diese Variablen anpassen:

    • spec.volumes[n].csi.volumeAttributes.mountOptions: Übergeben Sie Bereitstellungsoptionen an Cloud Storage FUSE. Geben Sie die Flags in einem String durch Kommas getrennt ohne Leerzeichen an.
    • spec.volumes[n].csi.volumeAttributes: Übergeben Sie zusätzliche Volume-Attribute an Cloud Storage FUSE.
    • spec.volumes[n].csi.readOnly: Geben Sie „true“ an, wenn alle Volume-Bereitstellungen schreibgeschützt sind.
    • spec.containers[n].volumeMounts[m].readOnly: Geben Sie „true“ an, wenn nur eine bestimmte Volume-Bereitstellung schreibgeschützt ist.

  2. Führen Sie den folgenden Befehl aus, um das Manifest auf Ihren Cluster anzuwenden:

    kubectl apply -f FILE_PATH

    Ersetzen Sie FILE_PATH durch den Pfad zu Ihrer YAML-Datei.

Denselben Cloud Storage-Bucket mit verschiedenen sitzungsspezifischen CSI-Volumes bereitstellen

Optional können Sie mehrere sitzungsspezifische CSI-Volumes verwenden, die von demselben Cloud Storage-Bucket unterstützt werden. Hängen Sie dazu zwei oder mehr Volumes an, die an verschiedenen Bereitstellungspfaden auf denselben Bucket-Namen verweisen. Ein Anwendungsfall könnte darin bestehen, verschiedene sitzungsspezifische CSI-Volumes mit unterschiedlichen Bereitstellungsoptionen für denselben Pod bereitzustellen, wobei jedes sitzungsspezifische Volume auf denselben Cloud Storage-Bucket verweist. Das folgende Beispiel zeigt ein Pod-Manifest, das diese Funktion verwendet:

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
        volumeMounts:
        - name: gcs-fuse-csi-ephemeral-with-mo
          mountPath: /data2
      volumes:
      - name: gcs-fuse-csi-ephemeral
        csi:
          driver: gcsfuse.csi.storage.gke.io
          volumeAttributes:
            bucketName: BUCKET_NAME
      - name: gcs-fuse-csi-ephemeral-with-mo
        csi:
          driver: gcsfuse.csi.storage.gke.io
          volumeAttributes:
            bucketName: BUCKET_NAME
            mountOptions: "implicit-dirs"
      restartPolicy: Never
  backoffLimit: 1

Probleme beheben

Weitere Informationen zur Fehlerbehebung beim CSI-Treiber für Cloud Storage FUSE finden Sie unter der Anleitung zur Fehlerbehebung in der Dokumentation zum GitHub-Projekt.

Nächste Schritte