La versione in lingua italiana fornita proviene da una traduzione automatica. Per eventuali incoerenze, fare riferimento alla versione in lingua inglese.

Configura i pool di storage in modalità ONTAP di Google Cloud NetApp Volumes

10/30/2026 Collaboratori

PDF

A partire da Trident 26.06, puoi configurare backend esistenti ontap-san e ontap-nas backend per effettuare il provisioning dello storage su Google Cloud NetApp Volumes (GCNV) pool di storage in modalità ONTAP. Questa funzionalità è una Tech Preview.

Questa funzionalità è una Tech Preview in Trident 26.10. Le funzionalità Tech Preview non sono supportate per l'utilizzo in produzione. La funzionalità, i campi di configurazione e la matrice supportata possono cambiare prima della disponibilità generale (GA).

Come funziona

Trident riutilizza la logica del driver esistente ontap-san e ontap-nas e instrada le chiamate REST ONTAP attraverso un endpoint proxy GCNV. Questo approccio ti permette di eseguire il provisioning e gestire lo storage su cluster ONTAP ospitati da GCNV mantenendo gli stessi flussi di lavoro operativi che usi per un backend ONTAP diretto. La modalità ONTAP non introduce un nuovo driver di storage. La abiliti per ogni backend aggiungendo un blocco di configurazione gcnv a un backend ontap-san o ontap-nas.

Il percorso di provisioning è il seguente:

PersistentVolumeClaim → Trident (ontap-san o ontap-nas) → client REST ONTAP → proxy GCNV → cluster ONTAP nel pool GCNV

Ambito supportato e non supportato

Questa anteprima tecnica supporta le seguenti funzionalità:

Driver: ontap-san (iSCSI) e ontap-nas (NFS o SMB).
Operazioni del ciclo di vita tramite proxy: inizializzazione del backend, creazione ed eliminazione dei volumi e relativi flussi REST ONTAP.
Modelli di autenticazione: Workload Identity Pool (WIP), chiave dell'account di servizio e fallback alle Application Default Credentials (ADC).

I seguenti elementi sono esclusi dall'ambito di questa Tech Preview:

I ontap-san-economy, ontap-nas-economy e ontap-nas-flexgroup driver.
Il percorso di personalità ASA r2.
Ripiego ZAPI. La modalità ONTAP usa solo ONTAP REST.

Prerequisiti

Prima di configurare un backend in modalità ONTAP, assicurati di avere quanto segue:

Trident 26.06 o versioni successive.
Un pool di storage GCNV ONTAP-mode nel tuo progetto e nella posizione di destinazione.
Autorizzazioni IAM di GCP per le operazioni proxy, con ambito appropriato per il tuo ambiente.
Una configurazione di backend che include proxyURL, projectNumber, location e poolID.
Per i flussi di lavoro SAN iSCSI, i prerequisiti iSCSI e multipath lato nodo per la tua piattaforma. Consulta "Preparare il nodo di lavoro".

Configura il backend

A TridentBackendConfig`richiede `credentials`di fare riferimento a un Kubernetes Secret. Per la modalità ONTAP, il secret fornisce le credenziali per l'accesso al proxy GCP, non ONTAP `managementLIF / username / password. A seconda del metodo di autenticazione, può contenere campi della chiave dell'account di servizio o essere vuoto. `svm`è facoltativo: ogni pool GCNV in modalità ONTAP attualmente ha un SVM e Trident lo ricava dal pool quando viene omesso.

Per l'autenticazione con chiave dell'account di servizio, usa lo stesso schema di GCNV nativo: campi non sensibili in gcnv.apiKey, private_key e private_key_id nel secret. Vedi "Esempi di configurazione di Google Cloud NetApp Volumes". Per l'autenticazione con Workload Identity Pool o GKE cloud identity, vedi gli esempi in Autenticazione.

backend ontap-san

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>"

backend ontap-nas

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>"

Segreto

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-----

Non mettere private_key o private_key_id nella TridentBackendConfig spec: il CRD li rifiuta. Usa ontap-san con lo stesso gcnv e lo stesso modello di credenziali per storage a blocchi.

Autenticazione

Trident risolve le credenziali per l'accesso proxy nel seguente ordine:

Workload Identity Pool (WIP)
Chiave dell'account di servizio
Credenziali predefinite dell'applicazione (ADC)

Per questa Tech Preview, segui le seguenti procedure:

Preferisci Workload Identity Pool dove è disponibile.
Non incorporare chiavi private raw nei file di backend sottoposti a controllo di versione. Archivia le credenziali in un secret di Kubernetes.
Applica all'account di servizio un ambito IAM con privilegi minimi.

Il location valore nel gcnv blocco deve corrispondere alla posizione del pool di storage: usa la zona per un pool zonale e la regione per un pool regionale.

Pool di identità dei carichi di lavoro

Usa gcnv.wipCredential per la federazione esplicita dell'account esterno configurata su TridentBackendConfig. Su OpenShift, Trident proietta il token in /var/run/secrets/wif-token/token; questo è l'unico percorso del token che Trident proietta per OpenShift WIF, quindi usalo per credential_source.file. Installa Trident con l'audience WIF come descritto in "Configura Google Cloud NetApp Volumes con Workload Identity Federation". Il credentials campo fa ancora riferimento a un Secret, ma il Secret non deve contenere un private_key.

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"

identità cloud GKE

Per GKE, configura l'identità cloud di Trident durante l'installazione come descritto in "Usa l'identità del carico di lavoro GKE". Il backend utilizza le credenziali predefinite dell'applicazione (ADC); ometti sia gcnv.apiKey che gcnv.wipCredential. Il campo credentials`fa ancora riferimento a un Secret, ma non inserirvi un `private_key.

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>"

Comportamento di validazione e inizializzazione

Trident valida un backend in modalità ONTAP durante l'inizializzazione e si arresta immediatamente invece di inizializzarsi solo parzialmente.

L'inizializzazione del backend non riesce se manca un campo gcnv obbligatorio, se il driver non è supportato per la modalità ONTAP o se la risoluzione delle credenziali non riesce.

Limitazioni note

Questa funzionalità è una Tech Preview. Il comportamento e la matrice supportata possono cambiare prima della GA.
Il fallback ZAPI non viene utilizzato in modalità ONTAP.
I requisiti relativi al protocollo e alla predisposizione del nodo rimangono validi. Ad esempio, i flussi di lavoro iSCSI richiedono i prerequisiti lato nodo descritti in "Preparare il nodo di lavoro".
Le limitazioni dell'ambiente ONTAP e GCNV esistenti rimangono valide.

Aggiornamento e compatibilità

La modalità ONTAP è opzionale per ciascun backend tramite il gcnv blocco di configurazione:

I backend ONTAP esistenti non GCNV non sono interessati.
Le implementazioni miste che combinano backend ONTAP diretti e backend proxy in modalità ONTAP sono supportate tramite la configurazione a livello di backend. Configuri ciascun backend in modo indipendente.
Per interrompere l'utilizzo di ONTAP-mode, rimuovi o sostituisci i backend interessati. Non è necessario alcuno switch globale.

Quali sono le prossime novità?

Applica il secret prima di TBC; usa kubectl apply e -n trident per allinearti agli esempi.