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

Configura Google Cloud NetApp Volumes per carichi di lavoro SAN

11/03/2026 Collaboratori

PDF

Usa il google-cloud-netapp-volumes-san driver per eseguire il provisioning di volumi a blocchi iSCSI dai pool di storage Flex Unified di Google Cloud NetApp Volumes.

Il driver SAN supporta solo carichi di lavoro a blocchi. Per eseguire il provisioning dei volumi NAS, usa il google-cloud-netapp-volumes driver.

Panoramica

Il driver effettua il provisioning dei volumi dai pool di storage Flex Unified e li presenta ai nodi Kubernetes come dispositivi a blocchi iSCSI.

Il driver supporta i seguenti ambienti:

Trident 26.02 e versioni successive
Google Kubernetes Engine (GKE) o cluster Red Hat OpenShift in esecuzione su GCP
Google Cloud NetApp Volumes Flex pool di storage unificati
Carichi di lavoro basati su iSCSI

A partire da Trident 26.10, il driver SAN supporta Google Cloud Workload Identity Federation (WIF) sui cluster OpenShift Container Platform (OCP, incluse le distribuzioni IPI) autogestiti e OpenShift Dedicated (OSD) in esecuzione su GCP. Per i prerequisiti di WIF e la configurazione del backend, vedi "Usa la federazione delle identità dei carichi di lavoro su OpenShift". Usa il nome del driver SAN e le impostazioni di storage Flex Unified in questa pagina.

Configura WIF per SAN

WIF scambia un token dell'account di servizio Kubernetes proiettato con credenziali Google Cloud di breve durata. Trident utilizza queste credenziali per impersonare un account di servizio Google Cloud quando chiama l'API di Google Cloud NetApp Volumes.

Configura un Google Cloud Workload Identity Pool e un provider OIDC per il cluster OpenShift. L'issuer del provider deve corrispondere al claim iss del token e la sua mappatura degli attributi deve mappare assertion.sub su google.subject.

Installa Trident con il nome della risorsa del provider come audience WIF. Questo fa sì che Trident proietti il token dell'account di servizio del controller in /var/run/secrets/wif-token/token.

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

Timone

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

Usa lo stesso pubblico per l'installazione di Trident e wipCredentialConfig.audience. Non configurare anche GKE cloudIdentity o --cloud-identity. Non applicare patch al Deployment del controller per aggiungere il token proiettato; il Trident operator può sovrascrivere questa modifica.

Su OpenShift Dedicated, il provider OIDC può essere condiviso con altri componenti di OpenShift. Se l'elenco del provider allowedAudiences è vuoto, Google accetta il nome canonico della risorsa del provider, con o senza il https:// prefisso, quindi non è necessario modificare il provider per il pubblico indicato sopra. Non impostare un elenco di destinatari esplicito solo per Trident. Se il provider ha già destinatari espliciti, aggiungi il destinatario di Trident mantenendo tutti i valori esistenti. La sostituzione dell'elenco può impedire ad altri componenti di OpenShift di scambiare token.

Assegna all'entità WIF per l'account di servizio del controller Trident il roles/iam.workloadIdentityUser ruolo nell'account di servizio Google Cloud che Trident impersonerà. Per l'account di servizio del controller Trident predefinito, il soggetto del token è system:serviceaccount:trident:trident-controller; utilizza il soggetto configurato per la tua installazione. Assegna all'account di servizio impersonato roles/netapp.admin, o autorizzazioni equivalenti, nel progetto che contiene le risorse Google Cloud NetApp Volumes.

Aggiungi la seguente sezione alla spec del backend SAN:

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

La configurazione WIF è la stessa per entrambi i driver GCNV. Il backend SAN deve comunque utilizzare google-cloud-netapp-volumes-san e un pool di storage Flex Unified supportato.

Pool di storage unificati Flex

I pool di storage Flex Unified forniscono storage a blocchi utilizzando il protocollo iSCSI e sono necessari per il provisioning SAN:

Sono supportati i pool regionali Flex Unified.
I pool Flex Unified ZONAL sono supportati a partire da Trident 26.02.1.
Per i carichi di lavoro SAN è supportato esclusivamente il livello di servizio Flex.

Il backend location deve corrispondere alla regione del pool Flex Unified. Se Trident non trova il pool, verifica la regione, la rete e il percorso delle risorse del pool.

Configura un backend SAN Trident

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

Crea un StorageClass

Dopo aver configurato il backend SAN, crea una StorageClass che fa riferimento al driver google-cloud-netapp-volumes-san.

Specifica il tipo di filesystem in StorageClass, non nel 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

Il driver supporta i seguenti tipi di filesystem:

ext4 (predefinito)
ext3
xfs

Il driver SAN supporta solo il livello di servizio Flex e non utilizza parametri backend specifici del NAS come exportRule, unixPermissions, nasType, snapshotDir, nfsMountOptions o impostazioni relative al tiering.

Verifica il provisioning WIF

Applica il backend e verifica che TridentBackendConfig sia associato e che la sua ultima operazione sia andata a buon fine:

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

Crea un PVC utilizzando lo gcnv-san StorageClass di questa pagina e verifica che raggiunga Bound. Questo convalida contemporaneamente lo scambio WIF, l'impersonificazione dell'account di servizio, le autorizzazioni di Google Cloud NetApp Volumes e la selezione del pool SAN. Elimina il PVC di test al termine.

Se la riconciliazione del backend non riesce, esamina i log del controller Trident:

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

Verifica la presenza dei seguenti errori comuni:

Per un invalid_grant errore di audience, confronta la claim del token aud con le audience consentite del provider OIDC e wipCredentialConfig.audience.
Per un iam.serviceAccounts.getAccessToken errore di autorizzazione, verifica che il principal WIF del controller Trident abbia roles/iam.workloadIdentityUser sull'account di servizio impersonato.
Per un netapp.storagePools.list errore di autorizzazione, verifica che l'account di servizio impersonato disponga delle autorizzazioni necessarie per Google Cloud NetApp Volumes nel progetto corretto.
Se non trovi il pool, verifica che la sua posizione e il suo tipo siano supportati, che la regione del backend corrisponda a quella del pool e che il backend faccia riferimento alla rete e al pool corretti.

Effettuare il provisioning dei volumi a blocchi

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)

Un modello comune per ROX è clonare un volume ReadWriteOnce esistente e montare il clone come di sola lettura.

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) — solo raw block

ReadWriteMany è supportato solo quando volumeMode: Block.

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

Comportamento del volume a blocchi

I volumi a blocchi vengono forniti come LUN iSCSI e presentati ai nodi Kubernetes come dispositivi a blocchi.

Volumi a blocchi:

Utilizzare il protocollo iSCSI
Supporta la presentazione sia del file system che dei blocchi raw
Sono allegati e gestiti da Trident
Supporta più modalità di accesso a Kubernetes

Modalità di accesso

I volumi a blocchi forniti da Trident supportano le seguenti modalità di accesso:

ReadWriteOnce (RWO)
ReadOnlyMany (ROX)
ReadWriteOncePod (RWOP)
ReadWriteMany (RWX), supportato solo quando volumeMode: Block

Comportamento di volumeMode

Il volumeMode campo controlla come viene esposto un volume di blocco:

Filesystem Trident formatta e monta il volume.
Block Trident collega il dispositivo e lo espone come raw block device.

Operazioni supportate

Volumi a blocchi forniti utilizzando il google-cloud-netapp-volumes-san driver support:

Crea
Elimina
Clona
Snapshot
Ridimensionare
Importare

Overhead delle dimensioni del volume

I volumi a blocchi di Google Cloud NetApp Volumes includono overhead interno dei metadati. Di conseguenza, la dimensione del dispositivo visibile al kernel è inferiore alla capacità di provisioning.

Overhead osservato:

Circa 300 KiB quando crei un volume
Fino a circa 107 MiB dopo il ridimensionamento

Google Cloud NetApp Volumes accetta allocazioni di capacità in GiB interi. Per garantire che la dimensione utilizzabile del dispositivo soddisfi o superi la richiesta del PVC, Trident:

Arrotonda la dimensione richiesta al GiB intero successivo.
Aggiunge un buffer da 1 GiB.

Ad esempio:

Richiesta PVC: 100 GiB.
Capacità allocata: 101 GiB.
Capacità utilizzabile visibile all'applicazione: almeno 100 GiB.

Esempi di pod

Volume a blocchi montato sul filesystem (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

Dispositivo a blocchi raw (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

Comportamento di attach e mount

Per i volumi SAN forniti da Google Cloud NetApp Volumes:

Trident crea un Logical Unit Number (LUN) in un pool di storage Flex Unified.
Durante la pubblicazione, Trident mappa la LUN su un gruppo host per nodo.
Durante la messa in scena del nodo, Trident:
- Accede all'iSCSI target
- Scopre il LUN
- Configura multipath
Se volumeMode: Filesystem, Trident formatta il dispositivo se necessario e lo monta.
Se volumeMode: Block, Trident collega il dispositivo e lo espone direttamente al pod senza formattarlo o montarlo.

I volumi a blocchi SAN non forniscono blocco distribuito o coordinamento delle scritture. Quando un volume a blocchi è accessibile da più nodi (ReadWriteMany con volumeMode: Block), l'applicazione o il file system devono gestire la concorrenza.