Die deutsche Sprachversion wurde als Serviceleistung für Sie durch maschinelle Übersetzung erstellt. Bei eventuellen Unstimmigkeiten hat die englische Sprachversion Vorrang.

Konfigurieren von Google Cloud NetApp Volumes für SAN-Workloads

05/07/2026 Beitragende

PDFs

Sie können Trident so konfigurieren, dass Block-Storage-Volumes über das iSCSI-Protokoll von Google Cloud NetApp Volumes bereitgestellt werden. SAN-Volumes werden mithilfe des google-cloud-netapp-volumes-san Speichertreibers aus Flex Unified Storage Pools bereitgestellt.

Dieser Treiber ist für Block-Workloads ausgelegt und unterstützt keine NAS-Protokolle.

Das google-cloud-netapp-volumes-san Backend ist erforderlich, um iSCSI-Blockvolumes bereitzustellen. Das google-cloud-netapp-volumes Backend unterstützt nur NAS-Protokolle und kann nicht für SAN-Workloads verwendet werden.

Überblick

Trident unterstützt Google Cloud NetApp Volumes SAN (iSCSI)-Workloads mithilfe des google-cloud-netapp-volumes-san Treibers.

SAN-Volumes werden aus Flex Unified-Speicherpools bereitgestellt und den Kubernetes-Knoten als iSCSI-Blockgeräte präsentiert.

Dies gilt für die folgenden Umgebungen:

Trident 26.02 und später
Google Kubernetes Engine (GKE) oder Red Hat OpenShift
Google Cloud NetApp Volumes Flex – Einheitliche Speicherpools
iSCSI-basierte Workloads

Flex Unified Speicherpools

Flex Unified-Speicherpools bieten Blockspeicher über das iSCSI-Protokoll und sind für die SAN-Bereitstellung erforderlich:

Flex Unified REGIONAL-Pools werden unterstützt.
Flex Unified ZONAL-Pools werden ab Trident 26.02.1 unterstützt.
Für SAN-Workloads wird ausschließlich die Serviceebene Flex unterstützt.

Konfigurieren Sie ein Trident SAN-Backend

apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: gcnv-san
  namespace: trident
spec:
  version: 1
  storageDriverName: google-cloud-netapp-volumes-san
  projectNumber: "<project-number>"
  location: "<region>"
  sdkTimeout: "600"
  storage:
  - labels:
      cloud: gcp
      performance: flex
    network: "<vpc-network>"
    serviceLevel: Flex

Erstellen Sie eine StorageClass

Nach der Konfiguration des SAN-Backends erstellen Sie eine StorageClass, die auf den google-cloud-netapp-volumes-san Treiber verweist.

Der Dateisystemtyp wird in der StorageClass definiert, nicht im Backend.

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: gcnv-san
provisioner: csi.trident.netapp.io
parameters:
  backendType: "google-cloud-netapp-volumes-san"
  fsType: "ext4"
allowVolumeExpansion: true

Unterstützte Dateisystemtypen:

ext4 (Standard)
ext3
xfs

Der SAN-Treiber unterstützt ausschließlich das Flex-Servicelevel und verwendet keine NAS-spezifischen Backend-Parameter wie exportRule, unixPermissions, nasType, snapshotDir, nfsMountOptions oder tiering-bezogene Einstellungen.

Block-Volumes bereitstellen

ReadWriteOnce (RWO)

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: gcnv-san-rwo
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 100Gi
  storageClassName: gcnv-san

ReadWriteOncePod (RWOP)

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: gcnv-san-rwop
spec:
  accessModes:
    - ReadWriteOncePod
  resources:
    requests:
      storage: 100Gi
  storageClassName: gcnv-san

ReadOnlyMany (ROX)

Ein gängiges Muster für ROX ist es, ein vorhandenes ReadWriteOnce-Volume zu klonen und den Klon als schreibgeschützt einzubinden.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: gcnv-san-rox
spec:
  accessModes:
    - ReadOnlyMany
  resources:
    requests:
      storage: 100Gi
  storageClassName: gcnv-san
  dataSource:
    kind: PersistentVolumeClaim
    name: gcnv-san-rwo

ReadWriteMany (RWX) — nur Rohdatenblock

ReadWriteMany wird nur unterstützt, wenn volumeMode: Block.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: gcnv-san-raw-rwx
spec:
  accessModes:
    - ReadWriteMany
  volumeMode: Block
  resources:
    requests:
      storage: 100Gi
  storageClassName: gcnv-san

Blockvolumenverhalten

Block-Volumes werden als iSCSI-LUNs bereitgestellt und den Kubernetes-Knoten als Blockgeräte präsentiert.

Block-Volumes:

Verwenden Sie das iSCSI-Protokoll
Unterstützung der Dateisystem- und Rohblockdarstellung
Werden von Trident angehängt und verwaltet
Mehrere Kubernetes-Zugriffsmodi unterstützen

Zugriffsmodi

Von Trident bereitgestellte Block-Volumes unterstützen die folgenden Zugriffsmodi:

ReadWriteOnce (RWO)
ReadOnlyMany (ROX)
ReadWriteOncePod (RWOP)
ReadWriteMany (RWX), wird nur unterstützt, wenn volumeMode: Block

volumeMode-Verhalten

Das volumeMode Feld steuert, wie ein Blockvolumen angezeigt wird:

Filesystem Trident formatiert und mountet das Volume.
Block Trident verbindet das Gerät und stellt es als Raw-Blockgerät bereit.

Unterstützte Operationen

Blockvolumes, die mithilfe des google-cloud-netapp-volumes-san Treibers bereitgestellt werden:

Erstellen
Löschen
Klonen
Snapshot
Größe Ändern
Importieren

Zusätzliches GiB-Überprovisionierungsverhalten

Google Cloud NetApp Volumes Blockvolumes beinhalten einen internen Metadaten-Overhead. Dieser Overhead reduziert die vom Kernel sichtbare Gerätegröße im Vergleich zur bereitgestellten Kapazität.

Tests zeigen:

Ungefähr 300 KiB Overhead bei der erstmaligen Erstellung
Bis zu ca. 107 MiB Overhead nach einer Größenänderung

Da Google Cloud NetApp Volumes nur ganze GiB-Zuweisungen akzeptiert, stellt Trident sicher, dass die nutzbare Gerätegröße die PVC-Anforderung immer erfüllt oder übertrifft, indem:

Aufrunden der angeforderten Größe auf das nächste ganze GiB
Hinzufügen eines zusätzlichen 1 GiB Puffers

Beispiel:

PVC-Anfrage: 100 GiB
Bereitgestellte Größe in Google Cloud NetApp Volumes: 101 GiB
Für die Anwendung sichtbarer nutzbarer Speicherplatz: mindestens 100 GiB

Pod-Beispiele

Dateisystemgebundenes Blockvolume (RWO)

apiVersion: v1
kind: Pod
metadata:
  name: app-rwo
spec:
  containers:
  - name: app
    image: ubuntu:22.04
    command: ["sleep", "infinity"]
    volumeMounts:
    - name: data
      mountPath: /mnt/data
  volumes:
  - name: data
    persistentVolumeClaim:
      claimName: gcnv-san-rwo

Raw-Block-Gerät (RWX)

apiVersion: v1
kind: Pod
metadata:
  name: app-raw-rwx
spec:
  containers:
  - name: app
    image: ubuntu:22.04
    command: ["sleep", "infinity"]
    volumeDevices:
    - name: data
      devicePath: /dev/xda
  volumes:
  - name: data
    persistentVolumeClaim:
      claimName: gcnv-san-raw-rwx

Anfüge- und Einhängeverhalten

Für SAN-Volumes, die von Google Cloud NetApp Volumes bereitgestellt wurden:

Trident erstellt eine Logical Unit Number (LUN) in einem Flex Unified Speicherpool.
Während der Veröffentlichung ordnet Trident die LUN einer Hostgruppe pro Knoten zu.
Während der Knoten-Staging-Phase führt Trident Folgendes aus:
- Meldet sich am iSCSI-Ziel an
- Entdeckt die LUN
- Konfiguriert Multipath
Wenn volumeMode: Filesystem erforderlich, formatiert Trident das Gerät und bindet es ein.
Wenn `volumeMode: Block`Trident das Gerät anschließt, wird es ohne Formatierung oder Einbindung direkt dem Pod bereitgestellt.

SAN-Blockvolumes bieten keine verteilte Sperrung oder Schreibkoordination. Wenn auf ein Blockvolume von mehreren Knoten (ReadWriteMany mit volumeMode: Block) zugegriffen wird, muss die Anwendung oder das Dateisystem die Parallelität verwalten.