Sidecar-Container für den Cloud Storage FUSE CSI-Treiber für GKE konfigurieren

In dieser Anleitung wird beschrieben, wie Sie Ressourcen für den Sidecar-Container des Cloud Storage FUSE CSI-Treibers konfigurieren, einschließlich der Einrichtung eines privaten Images, eines benutzerdefinierten Schreibpuffers und eines benutzerdefinierten Lesecache-Volumes. In der Regel müssen Sie diese Einstellungen nicht ändern.

Der Cloud Storage FUSE-CSI-Treiber verwendet einen anpassbaren Sidecar-Container, um Cloud Storage-Buckets effizient bereitzustellen und darauf zuzugreifen. Durch die Konfiguration des Sidecars können Sie die Anwendungsleistung und die Ressourcennutzung optimieren. Dies kann zu einem schnelleren Datenzugriff, kürzeren Verarbeitungszeiten und einem potenziell geringeren Gesamtresourcenverbrauch für Ihre Anwendung führen.

Diese Anleitung richtet sich an Entwickler, Administratoren und Architekten, die die Leistung, Sicherheit und Effizienz ihrer Anwendungen optimieren möchten, die mit GKE interagieren.

Bevor Sie diese Seite lesen, sollten Sie mit den Grundlagen von Cloud Storage, Kubernetes und Containerisierung vertraut sein.

Funktionsweise des Sidecar-Containers

Der Cloud Storage FUSE CSI-Treiber verwendet einen Sidecar-Container, um Cloud Storage-Buckets bereitzustellen, damit sie für Kubernetes-Anwendungen als lokale Dateisysteme zugänglich sind. Dieser Sidecar-Container namens gke-gcsfuse-sidecar wird zusammen mit dem Arbeitslastcontainer im selben Pod ausgeführt. Wenn der Treiber die Annotation gke-gcsfuse/volumes: "true" in einer Pod-Spezifikation erkennt, wird der Sidecar-Container automatisch eingefügt. Dieser Sidecar-Container-Ansatz trägt dazu bei, die Sicherheit zu gewährleisten und Ressourcen effektiv zu verwalten.

Der Sidecar-Container übernimmt die Komplexität der Bereitstellung der Cloud Storage-Buckets und bietet Dateisystemzugriff auf die Anwendungen, ohne dass Sie die Cloud Storage FUSE-Laufzeit direkt verwalten müssen. Sie können Ressourcenlimits für den Sidecar-Container mit Annotationen wie gke-gcsfuse/cpu-limit und gke-gcsfuse/memory-limit konfigurieren. Das Sidecar-Container-Modell sorgt auch dafür, dass die Cloud Storage FUSE-Instanz an den Lebenszyklus der Arbeitslast gebunden ist, sodass sie nicht unnötig Ressourcen verbraucht. Das bedeutet, dass der Sidecar-Container automatisch beendet wird, wenn die Arbeitslastcontainer beendet werden, insbesondere bei Job-Arbeitslasten oder Pods mit einem RestartPolicy von Never.

Istio-Kompatibilität

Der Sidecar-Container des Cloud Storage FUSE CSI-Treibers und Istio können gleichzeitig in Ihrem Pod ausgeführt werden. Der Sidecar-Proxy von Istio verwaltet den Netzwerkverkehr, während der CSI-Sidecar den Speicherzugriff optimiert. So können Ihre Anwendungen effizient mit Google Cloud Storage interagieren und profitieren von einer besseren Leistung und Beobachtbarkeit.

Benutzerdefinierten Schreib-Zwischenspeicher konfigurieren

Cloud Storage FUSE stellt Schreibvorgänge in einem lokalen Verzeichnis bereit und lädt sie dann bei close- oder fsync-Vorgängen in Cloud Storage hoch.

In diesem Abschnitt wird beschrieben, wie Sie ein benutzerdefiniertes Zwischenspeicher-Volume für die Schreibvorgangzwischenspeicherung in Cloud Storage FUSE konfigurieren. Dieses Szenario kann zutreffen, wenn Sie das Standardvolume emptyDir für Cloud Storage FUSE ersetzen müssen, um die Dateien in Schreibvorgängen zu stagen. Das ist nützlich, wenn Sie Dateien mit mehr als 10 GiB in Autopilot-Clustern schreiben müssen.

Sie können jeden vom Cloud Storage FUSE CSI-Treiber unterstützten Speichertyp für das Datei-Caching angeben, z. B. eine lokale SSD, einen auf Persistent Disk basierenden Speicher und eine RAM-Disk (Arbeitsspeicher). GKE verwendet das angegebene Volume für die Zwischenspeicherung von Dateischreibvorgängen. Weitere Informationen zu diesen Optionen finden Sie unter Speicher für das Sichern Ihres Dateicache auswählen.

Wenn Sie das benutzerdefinierte Zwischenspeicher-Volume verwenden möchten, müssen Sie fsGroup ungleich null angeben.

Im folgenden Beispiel wird gezeigt, wie Sie einen vordefinierten PersistentVolumeClaim als Puffervolume verwenden können:

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

Ersetzen Sie Folgendes:

  • FS_GROUP: die fsGroup-ID.
  • BUFFER_VOLUME_PVC ist der Name des vordefinierten PVC.

Benutzerdefiniertes Lese-Cache-Volume konfigurieren

In diesem Abschnitt wird beschrieben, wie Sie ein benutzerdefiniertes Cache-Volume für das Lese-Caching in Cloud Storage FUSE konfigurieren.

Dieses Szenario kann zutreffen, wenn Sie das Standardvolume emptyDir für Cloud Storage FUSE ersetzen müssen, um die Dateien bei Lesevorgängen zu cachen. Sie können jeden von GKE unterstützten Speichertyp angeben, z. B. einen PersistentVolumeClaim. GKE verwendet das angegebene Volume für das Dateicaching. Dies ist nützlich, wenn Sie Dateien mit einer Größe von mehr als 10 GiB in Autopilot-Clustern im Cache speichern müssen. Wenn Sie das benutzerdefinierte Cache-Volume verwenden möchten, müssen Sie fsGroup ungleich null angeben.

Im folgenden Beispiel wird gezeigt, wie Sie einen vordefinierten PersistentVolumeClaim als Cache-Volume verwenden können:

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

Ersetzen Sie Folgendes:

  • FS_GROUP: die fsGroup-ID.
  • CACHE_VOLUME_PVC ist der Name des vordefinierten PersistentVolumeClaim.

Privates Image für den Sidecar-Container konfigurieren

In diesem Abschnitt wird beschrieben, wie Sie das Sidecar-Container-Image verwenden, wenn Sie es in einer privaten Container-Registry hosten. Dieses Szenario kann zutreffen, wenn Sie aus Sicherheitsgründen private Knoten verwenden müssen.

So konfigurieren und verwenden Sie das private Sidecar-Container-Image:

  1. In dieser GKE-Kompatibilitätstabelle finden Sie ein kompatibles öffentliches Sidecar-Container-Image.
  2. Rufen Sie es in Ihrer lokalen Umgebung ab und übertragen Sie es in Ihre private Container Registry.

  3. Geben Sie im Manifest einen Container mit dem Namen gke-gcsfuse-sidecar an, der nur das Feld „image“ enthält. GKE verwendet das angegebene Sidecar-Container-Image, um die Injektion des Sidecar-Containers vorzubereiten.

    Hier ein Beispiel:

    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.

    Ersetzen Sie dabei Folgendes:

    • PRIVATE_REGISTRY: Ihre private Container-Registry.
    • PRIVATE_IMAGE_TAG: durch Ihr privates Sidecar-Container-Image-Tag.

Ressourcen für Sidecar-Container konfigurieren

Standardmäßig ist der gke-gcsfuse-sidecar-Container mit den folgenden Ressourcenanfragen und ‑limits für Standard- und Autopilot-Cluster konfiguriert:

Anfragen:

  • 250 mCPU
  • 256 MiB Arbeitsspeicher
  • Sitzungsspezifischer 5 GiB-Speicher

Grenzwerte (GKE-Version 1.29.1-gke.1670000 und höher):

  • Unbegrenzte CPU
  • Unbegrenzter Speicher
  • Unbegrenzter flüchtiger Speicher

Limits (vor GKE-Version 1.29.1-gke.1670000):

  • 250 mCPU
  • 256 MiB Arbeitsspeicher
  • Sitzungsspezifischer 5 GiB-Speicher

Standardmäßig ist der gke-gcsfuse-metadata-prefetch-Container mit den folgenden Ressourcenanfragen und ‑limits für Standard- und Autopilot-Cluster konfiguriert:

Anfragen:

  • 10 mCPU
  • 10 MiB Arbeitsspeicher
  • 10 MiB sitzungsspezifischer Speicher

Beschränkungen:

  • 50 mCPU
  • 250 MiB Arbeitsspeicher
  • Unbegrenzter flüchtiger Speicher

In Standard- und Autopilot-Clustern können Sie die Standardwerte überschreiben. Wie GKE Containerressourcen verarbeitet, hängt vom Betriebsmodus des Clusters ab:

  • Standardcluster: Wenn eine der Anfragen oder Limits festgelegt und die andere nicht festgelegt ist, werden die Ressourcenlimits und -anfragen der Pods auf denselben Wert gesetzt. Wenn sowohl Anforderungen als auch Limits festgelegt sind, verwenden Pods die von Ihnen angegebenen genauen Ressourcenanforderungen und ‑limits. Wenn Sie keine Werte festlegen, werden die oben beschriebenen Standardressourcen direkt angewendet.
  • Autopilot-Cluster: Wenn eine der Anfragen oder Limits festgelegt und die andere nicht festgelegt ist, werden die Ressourcenlimits und -anfragen der Pods auf denselben Wert gesetzt. Unter Ressourcenlimits in Autopilot festlegen erfahren Sie, wie sich Ressourcenüberschreibungen und die festgelegten Standardressourcenwerte auf das Pod-Verhalten auswirken.

Wenn Sie die Standardwerte für den gke-gcsfuse-sidecar-Container überschreiben möchten, können Sie optional die Annotation gke-gcsfuse/[cpu-limit|memory-limit|ephemeral-storage-limit|cpu-request|memory-request|ephemeral-storage-request] angeben, wie im folgenden Beispiel gezeigt:

Wenn Sie die Standardwerte für den gke-gcsfuse-metadata-prefetch-Container (ab GKE-Version 1.32.3-gke.1717000) überschreiben möchten, können Sie optional die Annotation gke-gcsfuse/[metadata-prefetch-cpu-limit|metadata-prefetch-memory-limit|metadata-prefetch-ephemeral-storage-limit|metadata-prefetch-cpu-request|metadata-prefetch-memory-request|metadata-prefetch-ephemeral-storage-request] angeben, wie im folgenden Beispiel gezeigt:

apiVersion: v1
kind: Pod
metadata:
  annotations:
    gke-gcsfuse/volumes: "true"

    # gke-gcsfuse-sidecar overrides
    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

    # gke-gcsfuse-metadata-prefetch overrides
    gke-gcsfuse/metadata-prefetch-cpu-limit: "10"
    gke-gcsfuse/metadata-prefetch-memory-limit: 10Gi
    gke-gcsfuse/metadata-prefetch-ephemeral-storage-limit: 1Ti
    gke-gcsfuse/metadata-prefetch-cpu-request: 500m
    gke-gcsfuse/metadata-prefetch-memory-request: 1Gi
    gke-gcsfuse/metadata-prefetch-ephemeral-storage-request: 50Gi

Mit dem Wert "0" können Sie alle Ressourcenlimits oder -anforderungen aufheben. Beachten Sie jedoch, dass für den gke-gcsfuse-sidecar-Container bereits alle Limits (cpu-limit, memory-limit und ephemeral-storage-limit) aufgehoben sind und für den gke-gcsfuse-metadata-prefetch-Container bereits ephemeral-storage-limit aufgehoben ist. Das Festlegen dieser Limits auf "0" in einem Cluster mit GKE-Version 1.32.3-gke.1717000 oder höher hätte also keine Auswirkungen.

Wenn Sie beispielsweise gke-gcsfuse/metadata-prefetch-memory-limit: "0" festlegen, wird das Speicherlimit des Containers gke-gcsfuse-metadata-prefetch nicht festgelegt. Das ist nützlich, wenn Sie sich nicht sicher sind, wie viele Ressourcen die Funktion zum Vorabrufen von Metadaten für Ihre Arbeitslasten benötigt, und möchten, dass das Vorabrufen von Metadaten alle verfügbaren Ressourcen auf einem Knoten verbraucht.

Logging-Ausführlichkeit konfigurieren

Standardmäßig werden im gke-gcsfuse-sidecar-Container Logs auf den Ebenen info und error generiert. Für die Fehlerbehebung oder eine detailliertere Analyse müssen Sie jedoch möglicherweise die Ausführlichkeit der Protokollierung anpassen. In diesem Abschnitt wird beschrieben, wie Sie den Logging-Level erhöhen oder verringern.

Sie können entweder Bereitstellungsoptionen verwenden, um die Ausführlichkeit des Loggings zu konfigurieren, oder die Möglichkeit des CSI-Treibers nutzen, Volumenattributwerte in die erforderlichen gcsfuse-Konfigurationseinstellungen zu übersetzen.

Fügen Sie in das Manifest des Ziel-Pods die folgenden Konfigurationen ein:

      volumeAttributes:
        bucketName: BUCKET_NAME
        mountOptions: "implicit-dirs"
        gcsfuseLoggingSeverity:  LOGGING_SEVERITY

Wenn Sie die Bereitstellungsoptionen verwenden möchten, fügen Sie dem Ziel-Pod-Manifest die folgende Konfiguration hinzu:

  mountOptions: "logging:severity:LOGGING_SEVERITY"

Ersetzen Sie Folgendes:

  • BUCKET_NAME: Name Ihres Cloud Storage-Buckets.
  • LOGGING_SEVERITY: einer der folgenden Werte, je nach Ihren Anforderungen:
    • trace
    • debug
    • info
    • warning
    • error

Nachdem der Pod bereitgestellt wurde, initiiert der CSI-Treiber gcsfuse mit der neu konfigurierten Logging-Ebene.

Mit dem folgenden Filter können Sie prüfen, ob der Schweregrad der Protokollierung angewendet wird:

resource.labels.container_name="gke-gcsfuse-sidecar"
resource.type="k8s_container"
resource.labels.pod_name="POD_NAME"
"severity:"

Nächste Schritte