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

11/03/2026 Beitragende

PDFs

Mit dem `google-cloud-netapp-volumes-san`Treiber lassen sich iSCSI-Block-Volumes aus Google Cloud NetApp Volumes Flex Unified Storage-Pools provisionieren.

Der SAN-Treiber unterstützt nur Block-Workloads. Der google-cloud-netapp-volumes Treiber dient zur Provisionierung von NAS Volumes.

Überblick

Der Treiber provisioniert Volumes aus Flex Unified Storage-Pools und präsentiert sie den Kubernetes-Knoten als iSCSI-Blockgeräte.

Der Treiber unterstützt die folgenden Umgebungen:

Trident 26.02 und später
Google Kubernetes Engine (GKE), oder Red Hat OpenShift Cluster, die auf GCP ausgeführt werden
Google Cloud NetApp Volumes Flex – Einheitliche Speicherpools
iSCSI-basierte Workloads

Ab Trident 26.10 unterstützt der SAN-Treiber Google Cloud Workload Identity Federation (WIF) auf selbstverwalteten OpenShift Container Platform (OCP, einschließlich IPI-Bereitstellungen) und OpenShift Dedicated (OSD) Clustern, die auf GCP ausgeführt werden. Informationen zu den WIF-Voraussetzungen und zur Backend-Konfiguration enthält "Verwendung der Workload Identity Federation auf OpenShift". Für diese Seite gelten der SAN-Treibername und die Flex Unified Storage Einstellungen.

Konfiguration von WIF für SAN

WIF tauscht ein projiziertes Kubernetes-Dienstkontotoken gegen kurzlebige Google Cloud-Anmeldeinformationen aus. Trident verwendet diese Anmeldeinformationen, um beim Aufruf der Google Cloud NetApp Volumes API die Identität eines Google Cloud-Dienstkontos anzunehmen.

Für den OpenShift Cluster ist ein Google Cloud Workload Identity Pool und ein OIDC-Provider einzurichten. Der Aussteller des Providers muss mit dem Claim iss des Tokens übereinstimmen, und seine Attributzuordnung muss assertion.sub auf google.subject erfassen.

Die Installation von Trident erfolgt mit dem Ressourcennamen des Anbieters als WIF-Zielgruppe. Dadurch projiziert Trident das Token des Controller-Dienstkontos unter /var/run/secrets/wif-token/token.

Betreiber von Trident

apiVersion: trident.netapp.io/v1
kind: TridentOrchestrator
metadata:
  name: trident
spec:
  namespace: trident
  cloudProvider: GCP
  gcpWIFAudience: "//iam.googleapis.com/projects/<wif-pool-project-number>/locations/global/workloadIdentityPools/<pool-id>/providers/<provider-id>"

Helm

helm install trident <trident-operator-package> \
  --namespace trident \
  --create-namespace \
  --set cloudProvider=GCP \
  --set-string gcpWIFAudience="//iam.googleapis.com/projects/<wif-pool-project-number>/locations/global/workloadIdentityPools/<pool-id>/providers/<provider-id>"

Tridentctl

tridentctl install \
  --namespace trident \
  --cloud-provider GCP \
  --gcp-wif-audience "//iam.googleapis.com/projects/<wif-pool-project-number>/locations/global/workloadIdentityPools/<pool-id>/providers/<provider-id>"

Für die Trident Installation und wipCredentialConfig.audience sollte dieselbe Zielgruppe verwendet werden. Auch GKE cloudIdentity oder --cloud-identity sollte nicht konfiguriert werden. Ein Patch zum Hinzufügen des projizierten Tokens zur Controller Deployment sollte vermieden werden; der Trident operator kann diese Änderung überschreiben.

Auf OpenShift Dedicated kann der OIDC-Provider mit anderen OpenShift Komponenten gemeinsam verwendet werden. Ist die allowedAudiences`Providerliste leer, akzeptiert Google den kanonischen Ressourcennamen des Providers mit oder ohne das Präfix `https://, sodass für die oben genannte Zielgruppe keine Änderung des Providers erforderlich ist. Es sollte keine explizite Zielgruppenliste nur für Trident festgelegt werden. Falls der Provider bereits explizite Zielgruppen besitzt, fügen Sie die Trident Zielgruppe hinzu und behalten Sie dabei alle vorhandenen Werte bei. Das Ersetzen der Liste kann andere OpenShift Komponenten daran hindern, Tokens auszutauschen.

Dem WIF-Prinzipal für das Trident Controller Dienstkonto wird die roles/iam.workloadIdentityUser`Rolle für das Google Cloud Dienstkonto zugewiesen, als das Trident auftritt. Beim standardmäßigen Trident Controller Dienstkonto ist das Token-Subjekt `system:serviceaccount:trident:trident-controller; zu verwenden ist das für Ihre Installation konfigurierte Subjekt. Dem imitierten Dienstkonto werden roles/netapp.admin oder gleichwertige Berechtigungen für das Projekt gewährt, das die Google Cloud NetApp Volumes Ressourcen enthält.

Der folgende Abschnitt ist dem spec des SAN Backends hinzuzufügen:

wipCredentialConfig:
  type: external_account
  audience: "//iam.googleapis.com/projects/<wif-pool-project-number>/locations/global/workloadIdentityPools/<pool-id>/providers/<provider-id>"
  subject_token_type: urn:ietf:params:oauth:token-type:jwt
  token_url: https://sts.googleapis.com/v1/token
  credential_source:
    file: /var/run/secrets/wif-token/token
  service_account_impersonation_url: https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/<service-account-email>:generateAccessToken

Die WIF-Konfiguration ist für beide GCNV-Treiber identisch. Das SAN-Backend muss weiterhin google-cloud-netapp-volumes-san sowie einen unterstützten Flex Unified Storage-Pool verwenden.

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.

Das Backend location muss mit der Region des Flex Unified Pools übereinstimmen. Falls Trident den Pool nicht findet, ist eine Überprüfung der Region, des Netzwerks und des Ressourcenpfads des Pools erforderlich.

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.

Die Angabe des Dateisystemtyps erfolgt in der StorageClass, 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

Der Treiber unterstützt die folgenden 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.

Überprüfung der WIF Provisionierung

Anwendung des Backends und Überprüfung, ob die TridentBackendConfig gebunden ist und der letzte Vorgang erfolgreich war:

oc apply -f <backend-file>.yaml
oc -n trident get tridentbackendconfig <backend-name> -o yaml

Zum Test wird mithilfe der gcnv-san StorageClass auf dieser Seite eine PVC erstellt und überprüft, ob sie Bound erreicht. Dadurch werden der WIF-Austausch, die Dienstkonto-Impersonation, die Berechtigungen für Google Cloud NetApp Volumes und die Auswahl des SAN-Pools zusammen validiert. Nach Abschluss erfolgt das Löschen der Test-PVC.

Falls der Backend-Abgleich fehlschlägt, ist eine Prüfung der Protokolle des Trident Controllers erforderlich:

oc -n trident logs deploy/trident-controller -c trident-main --tail=400

Folgendes ist auf häufige Fehler zu prüfen:

Bei einem invalid_grant`Zielgruppenfehler ist der `aud`Anspruch des Tokens mit den vom OIDC-Anbieter zugelassenen Zielgruppen `wipCredentialConfig.audience zu vergleichen.
Bei einem iam.serviceAccounts.getAccessToken Berechtigungsfehler ist zu überprüfen, ob der WIF Principal des Trident Controllers roles/iam.workloadIdentityUser über die erforderlichen Berechtigungen für das imitierte Dienstkonto verfügt.
Bei einem netapp.storagePools.list Berechtigungsfehler ist zu prüfen, ob das verwendete Dienstkonto im richtigen Projekt über die erforderlichen Berechtigungen für Google Cloud NetApp Volumes verfügt.
Wird der Pool nicht gefunden, ist zu prüfen, ob sein Standort und Typ unterstützt werden, ob die Backend-Region mit der Pool-Region übereinstimmt und ob das Backend auf das richtige Netzwerk und den richtigen Pool verweist.

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

Overhead der Volume-Größe

Google Cloud NetApp Volumes Blockvolumes beinhalten internen Metadaten-Overhead. Daher ist die für den Kernel sichtbare Gerätegröße kleiner als die bereitgestellte Kapazität.

Beobachteter Overhead:

Beim Erstellen eines Volumes werden etwa 300 KiB benötigt
Bis zu ca. 107 MiB nach einer Größenänderung

Google Cloud NetApp Volumes akzeptiert Kapazitätszuweisungen in ganzen GiB. Um sicherzustellen, dass die nutzbare Gerätegröße die PVC-Anforderung erfüllt oder übersteigt, führt Trident Folgendes aus:

Die angeforderte Größe wird auf das nächste ganze GiB aufgerundet.
Fügt einen 1 GiB großen Puffer hinzu.

Beispiel:

PVC-Anforderung: 100 GiB.
Bereitgestellte Kapazität: 101 GiB.
Für die Applikation sichtbare nutzbare Kapazität: 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.