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

Konfiguration von Google Cloud NetApp Volumes ONTAP-mode Speicherpools

10/30/2026 Beitragende

PDFs

Ab Trident 26.06 können bestehende ontap-san und ontap-nas Backends so konfiguriert werden, dass sie Speicher auf Google Cloud NetApp Volumes (GCNV) ONTAP-mode Speicherpools bereitstellen. Diese Funktion ist eine Tech Preview.

Diese Funktion ist eine Tech Preview in Trident 26.10. Tech Preview Funktionen sind für den Produktiveinsatz nicht unterstützt. Die Funktionalität, die Konfigurationsfelder und die unterstützte Matrix können sich vor der allgemeinen Verfügbarkeit (GA) ändern.

So funktioniert es

Trident nutzt die bestehende ontap-san und ontap-nas Treiberlogik wieder und leitet ONTAP REST-Aufrufe über einen GCNV-Proxy-Endpunkt weiter. Mit diesem Ansatz ist die Bereitstellung und Verwaltung von Speicher auf GCNV-gehosteten ONTAP Clustern möglich, wobei die gleichen Betriebsabläufe wie bei einem direkten ONTAP Backend erhalten bleiben. ONTAP-mode führt keinen neuen Speichertreiber ein. Die Aktivierung erfolgt pro Backend durch Hinzufügen eines gcnv Konfigurationsblocks zu einem ontap-san oder ontap-nas Backend.

Der Bereitstellungspfad ist wie folgt:

PersistentVolumeClaim → Trident (ontap-san oder ontap-nas) → ONTAP REST Client → GCNV Proxy → ONTAP Cluster im GCNV Pool

Unterstützter und nicht unterstützter Scope

Diese technische Vorschau unterstützt Folgendes:

Treiber: ontap-san (iSCSI) und ontap-nas (NFS oder SMB).
Lebenszyklusoperationen über den Proxy: Backend-Initialisierung, Volume-Erstellung und -Löschung sowie zugehörige ONTAP REST-Flows.
Authentifizierungsmodelle: Workload Identity Pool (WIP), Dienstkontoschlüssel und Application Default Credentials (ADC) Fallback.

Die folgenden Punkte sind nicht Teil dieser Tech Preview:

Die ontap-san-economy, ontap-nas-economy und ontap-nas-flexgroup-Treiber.
Der ASA r2 Persönlichkeitspfad.
ZAPI Fallback. ONTAP-Modus verwendet ausschließlich ONTAP REST.

Voraussetzungen

Bevor Sie ein ONTAP Mode-Backend konfigurieren, ist Folgendes erforderlich:

Trident 26.06 oder später.
Ein GCNV ONTAP-Mode-Speicherpool in Ihrem Zielprojekt und Standort.
GCP IAM-Berechtigungen für Proxy-Operationen, passend für Ihre Umgebung festgelegt.
Eine Backend-Konfiguration, die proxyURL, projectNumber, location und poolID umfasst.
Für iSCSI SAN-Workflows gelten die iSCSI- und Multipath-Voraussetzungen auf Knotenseite für Ihre Plattform. Siehe "Bereiten Sie den Knoten „Worker“ vor".

Das Backend konfigurieren

A TridentBackendConfig erfordert credentials die Referenz auf ein Kubernetes Secret. Im ONTAP Modus stellt das Secret die Anmeldedaten für den GCP-Proxy-Zugriff bereit, nicht ONTAP managementLIF / username / password. Abhängig vom Authentifizierungsverfahren kann es Dienstkontoschlüsselfelder enthalten oder leer sein. svm ist optional: Jeder Pool im GCNV ONTAP Modus hat derzeit eine SVM, und Trident leitet sie vom Pool ab, wenn sie weggelassen wird.

Für die Authentifizierung mit Dienstkontoschlüsseln wird dasselbe Muster wie bei nativem GCNV verwendet: nicht sensible Felder in gcnv.apiKey, private_key und private_key_id im Secret. Weitere Informationen finden sich in "Beispiele für die Konfiguration von Google Cloud NetApp Volumes". Für die Authentifizierung mit Workload Identity Pool oder GKE cloud identity finden sich Beispiele in Authentifizierung.

ontap-san Backend

apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: gcnv-ontap-san
  namespace: trident
spec:
  version: 1
  storageDriverName: ontap-san
  backendName: gcnv-ontap-san
  credentials:
    name: gcnv-sa-secret
    type: secret
  gcnv:
    proxyURL: "https://netapp.googleapis.com"
    projectNumber: "<project-number>"
    location: "<pool-location>"
    poolID: "<pool-id>"
  svm: "<svm-name>"

ontap-nas Backend

apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: gcnv-ontap-nas
  namespace: trident
spec:
  version: 1
  storageDriverName: ontap-nas
  backendName: gcnv-ontap-nas
  credentials:
    name: gcnv-sa-secret
    type: secret
  gcnv:
    proxyURL: "https://netapp.googleapis.com"
    projectNumber: "<project-number>"
    location: "<pool-location>"
    poolID: "<pool-id>"
    apiKey:
      type: service_account
      project_id: "<project-id>"
      client_email: "<service-account-email>"
      client_id: "<client-id>"
      auth_uri: "https://accounts.google.com/o/oauth2/auth"
      token_uri: "https://oauth2.googleapis.com/token"
      auth_provider_x509_cert_url: "https://www.googleapis.com/oauth2/v1/certs"
      client_x509_cert_url: "<client-x509-cert-url>"
  svm: "<svm-name>"

Geheim

apiVersion: v1
kind: Secret
metadata:
  name: gcnv-sa-secret
  namespace: trident
type: Opaque
stringData:
  private_key_id: "<private-key-id>"
  private_key: |
    -----BEGIN PRIVATE KEY-----
    <private-key>
    -----END PRIVATE KEY-----

Setzen Sie private_key oder private_key_id nicht in die TridentBackendConfig-Spezifikation, da die CRD sie ablehnt. ontap-san sollte mit demselben gcnv- und Anmeldeinformationsmuster für Blockspeicher verwendet werden.

Authentifizierung

Trident löst die Anmeldeinformationen für den Proxy-Zugriff in der folgenden Reihenfolge auf:

Workload Identity Pool (WIP)
Dienstkontoschlüssel
Standardanmeldeinformationen für Anwendungen (ADC)

Für diese Tech Preview gelten die folgenden Vorgehensweisen:

Sofern verfügbar, ist der Workload Identity Pool die bevorzugte Option.
Rohformatige private Schlüssel sollten nicht in versionskontrollierte Backend-Dateien eingebettet werden. Anmeldeinformationen sollten in einem Kubernetes-Secret gespeichert werden.
Für das Dienstkonto gilt eine IAM-Bereichsbegrenzung nach dem Least-Privilege-Prinzip.

Der location im gcnv Block muss mit dem Standort des Pools übereinstimmen: Bei einem zonalen Pool ist die Zone anzugeben, bei einem regionalen Pool die Region.

Workload Identity-Pool

Zum Einsatz kommt gcnv.wipCredential für den expliziten Verbund externer Konten, der auf dem TridentBackendConfig konfiguriert ist. Auf OpenShift projiziert Trident das Token unter /var/run/secrets/wif-token/token; dies ist der einzige Tokenpfad, den Trident für OpenShift WIF projiziert, daher wird er für credential_source.file verwendet. Die Installation von Trident mit der WIF audience erfolgt wie in"Konfigurieren von Google Cloud NetApp Volumes mit Workload Identity Federation" beschrieben. Das credentials Feld verweist weiterhin auf ein Secret, aber das Secret darf kein private_key enthalten.

apiVersion: v1
kind: Secret
metadata:
  name: gcnv-ontap-empty
  namespace: trident
type: Opaque
---
apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: gcnv-ontap-nas-wip
  namespace: trident
spec:
  version: 1
  storageDriverName: ontap-nas
  backendName: gcnv-ontap-nas-wip
  useREST: true
  nasType: nfs
  nfsMountOptions: nfsvers=4.1
  credentials:
    name: gcnv-ontap-empty
    type: secret
  gcnv:
    proxyURL: "https://netapp.googleapis.com"
    projectNumber: "<project-number>"
    location: "<pool-location>"
    poolID: "<pool-id>"
    wipCredential:
      type: external_account
      audience: "//iam.googleapis.com/projects/<wif-pool-project-number>/locations/global/workloadIdentityPools/<wif-pool-id>/providers/<provider-id>"
      subject_token_type: "urn:ietf:params:oauth:token-type:jwt"
      token_url: "https://sts.googleapis.com/v1/token"
      service_account_impersonation_url: "https://iamcredentials.googleapis.com/v1/projects/-/serviceAccounts/<service-account-email>:generateAccessToken"
      credential_source:
        file: "/var/run/secrets/wif-token/token"

GKE Cloud-Identität

Für GKE erfolgt die Konfiguration von Tridents Cloud-Identität bei der Installation wie in "Verwendung der GKE Workload Identity" beschrieben. Das Backend verwendet Application Default Credentials (ADC); sowohl gcnv.apiKey als auch gcnv.wipCredential werden weggelassen. Das credentials`Feld verweist weiterhin auf ein Secret, es darf jedoch kein `private_key darin eingetragen werden.

apiVersion: v1
kind: Secret
metadata:
  name: gcnv-ontap-empty
  namespace: trident
type: Opaque
---
apiVersion: trident.netapp.io/v1
kind: TridentBackendConfig
metadata:
  name: gcnv-ontap-nas-wi
  namespace: trident
spec:
  version: 1
  storageDriverName: ontap-nas
  backendName: gcnv-ontap-nas-wi
  useREST: true
  nasType: nfs
  nfsMountOptions: nfsvers=4.1
  credentials:
    name: gcnv-ontap-empty
    type: secret
  gcnv:
    proxyURL: "https://netapp.googleapis.com"
    projectNumber: "<project-number>"
    location: "<pool-location>"
    poolID: "<pool-id>"

Validierungs- und Initialisierungsverhalten

Trident validiert ein ONTAP-Modus-Backend während der Initialisierung und schlägt sofort fehl, anstatt es nur teilweise zu initialisieren.

Die Backend-Initialisierung schlägt fehl, wenn ein erforderliches gcnv Feld fehlt, der Treiber für den ONTAP-Modus nicht unterstützt wird oder die Auflösung der Anmeldeinformationen fehlschlägt.

Bekannte Einschränkungen

Diese Funktion ist eine Tech Preview. Das Verhalten und die unterstützte Matrix können sich vor GA ändern.
ZAPI-Fallback wird im ONTAP Modus nicht verwendet.
Die Anforderungen an Protokoll und Knotenbereitschaft gelten weiterhin. Beispielsweise erfordern iSCSI-Workflows die knotenseitigen Voraussetzungen, die in "Bereiten Sie den Knoten „Worker“ vor" beschrieben sind.
Die bestehenden Einschränkungen der ONTAP- und GCNV-Umgebung gelten weiterhin.

Upgrade und Kompatibilität

Der ONTAP Modus ist pro Backend über den gcnv Konfigurationsblock optional aktivierbar:

Bestehende ONTAP Backends, die nicht zu GCNV gehören, sind davon nicht betroffen.
Gemischte Bereitstellungen, die direkte ONTAP Backends und Proxy-Backends im ONTAP Modus kombinieren, werden durch eine Konfiguration auf Backend-Ebene unterstützt. Jedes Backend wird unabhängig konfiguriert.
Die Verwendung des ONTAP Modus lässt sich durch Entfernen oder Ersetzen der betroffenen Backends beenden. Ein globaler Schalter ist nicht erforderlich.

Was kommt als Nächstes?

Das Secret wird vor TBC angewendet; zum Abgleich mit den Beispielen dienen kubectl apply und -n trident.