La version française est une traduction automatique. La version anglaise prévaut sur la française en cas de divergence.

Configurer les pools de stockage Google Cloud NetApp Volumes en mode ONTAP

10/30/2026 Contributeurs

À partir de Trident 26.06, vous pouvez configurer des backends existants ontap-san et ontap-nas pour provisionner du stockage sur Google Cloud NetApp Volumes (GCNV), dans des pools de stockage en mode ONTAP. Cette fonctionnalité est une Tech Preview.

Cette fonctionnalité est une Tech Preview dans Trident 26.10. Les fonctionnalités en avant-première technique ne sont pas prises en charge pour une utilisation en production. La fonctionnalité, les champs de configuration et la matrice prise en charge peuvent changer avant la disponibilité générale (GA).

Comment ça marche

Trident réutilise la logique de pilote existante ontap-san et ontap-nas et achemine les appels REST ONTAP via un point de terminaison proxy GCNV. Cette approche vous permet de provisionner et de gérer le stockage sur des clusters ONTAP hébergés sur GCNV tout en conservant les mêmes flux de travail opérationnels que pour un backend ONTAP direct. Le mode ONTAP n’introduit pas de nouveau pilote de stockage. Vous l’activez pour chaque backend en ajoutant un bloc de configuration gcnv à un backend ontap-san ou ontap-nas.

Le processus de provisionnement est le suivant :

PersistentVolumeClaim → Trident (ontap-san ou ontap-nas) → client REST ONTAP → proxy GCNV → cluster ONTAP dans le pool GCNV

Portée prise en charge et non prise en charge

Cette préversion technique prend en charge les éléments suivants :

Pilotes : ontap-san (iSCSI) et ontap-nas (NFS ou SMB).
Opérations de cycle de vie via le proxy : initialisation du backend, création et suppression de volumes, et flux REST ONTAP associés.
Modèles d'authentification : Workload Identity Pool (WIP), clé de compte de service et repli Application Default Credentials (ADC).

Les éléments suivants ne font pas partie du champ d'application de cet aperçu technique :

Les ontap-san-economy, ontap-nas-economy et ontap-nas-flexgroup pilotes.
Le chemin de personnalité ASA r2.
Solution de repli ZAPI. Le mode ONTAP utilise uniquement ONTAP REST.

Prérequis

Avant de configurer un backend en mode ONTAP, assurez-vous de disposer des éléments suivants :

Trident 26.06 ou version ultérieure.
Un pool de stockage GCNV en mode ONTAP dans votre projet et emplacement cibles.
Autorisations GCP IAM pour les opérations de proxy, adaptées à votre environnement.
Une configuration backend qui inclut proxyURL, projectNumber, location et poolID.
Pour les flux de travail SAN iSCSI, les prérequis iSCSI côté nœud et multipath de votre plateforme. Consultez "Préparez le nœud de travail".

Configurer le backend

A TridentBackendConfig nécessite credentials de faire référence à un Kubernetes Secret. Pour le mode ONTAP, le secret fournit les identifiants pour l'accès au proxy GCP, et non à ONTAP managementLIF / username / password. Selon la méthode d'authentification, il peut contenir des champs de clé de compte de service ou être vide. svm est facultatif: chaque pool GCNV en mode ONTAP possède actuellement une seule SVM, et Trident la déduit du pool si elle est omise.

Pour l'authentification par clé de compte de service, utilisez le même modèle que pour GCNV natif : champs non sensibles dans gcnv.apiKey, private_key et private_key_id dans le secret. Voir "Exemples de configuration de Google Cloud NetApp Volumes". Pour l'authentification par Workload Identity Pool ou GKE cloud identity, consultez les exemples dans Authentification.

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

Secret

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

N’incluez pas private_key ou private_key_id dans la TridentBackendConfig spécification : la CRD les rejette. Utilisez ontap-san avec le même gcnv et le même modèle d’identifiant pour le stockage bloc.

Authentification

Trident résout les identifiants pour l'accès au proxy dans l'ordre suivant :

Pool d’identités de workload (WIP)
Clé du compte de service
Informations d'identification par défaut de l'application (ADC)

Pour cette Tech Preview, veuillez suivre les pratiques suivantes :

Privilégiez Workload Identity Pool lorsqu'il est disponible.
N’intégrez pas les clés privées brutes dans les fichiers backend versionnés. Stockez les identifiants dans un secret Kubernetes.
Appliquer le principe du moindre privilège en matière de gestion des identités et des accès (IAM) au compte de service.

Le location dans le bloc gcnv doit correspondre à l'emplacement du pool : utilisez la zone pour un pool zonal et la région pour un pool régional.

Pool d’identités de workload

Utilisez gcnv.wipCredential pour la fédération explicite de comptes externes configurée sur le TridentBackendConfig. Sur OpenShift, Trident projette le jeton dans /var/run/secrets/wif-token/token ; il s'agit du seul chemin de jeton que Trident projette pour OpenShift WIF, utilisez-le donc pour credential_source.file. Installez Trident avec l'audience WIF comme décrit dans "Configurer Google Cloud NetApp Volumes avec Workload Identity Federation". Le champ credentials fait toujours référence à un Secret, mais le Secret ne doit pas contenir de 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

Pour GKE, configurez l'identité cloud de Trident lors de l'installation comme décrit dans "Utiliser GKE workload identity". Le backend utilise les informations d'identification par défaut de l'application (ADC) ; omettez gcnv.apiKey et gcnv.wipCredential. Le champ credentials fait toujours référence à un Secret, mais n'y mettez pas de 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>"

Comportement de validation et d'initialisation

Trident valide un backend en mode ONTAP lors de l'initialisation et échoue rapidement plutôt que de procéder à une initialisation partielle.

L'initialisation du backend échoue si un champ gcnv obligatoire est manquant, si le pilote n'est pas pris en charge pour le mode ONTAP ou si la résolution des identifiants échoue.

Limitations connues

Cette fonctionnalité est une Tech Preview. Le comportement et la matrice prise en charge peuvent changer avant GA.
Le mécanisme de repli ZAPI n'est pas utilisé en mode ONTAP.
Les exigences relatives au protocole et à la préparation des nœuds restent applicables. Par exemple, les workflows iSCSI nécessitent les prérequis côté nœud décrits dans "Préparez le nœud de travail".
Les contraintes existantes de l'environnement ONTAP et GCNV restent applicables.

Mise à niveau et compatibilité

Le mode ONTAP est optionnel pour chaque backend via le `gcnv`bloc de configuration :

Les systèmes back-end ONTAP non-GCNV existants ne sont pas affectés.
Les déploiements mixtes qui combinent des backends ONTAP directs et des backends proxy en mode ONTAP sont pris en charge grâce à une configuration au niveau du backend. Chaque backend est configuré indépendamment.
Pour cesser d'utiliser le mode ONTAP, supprimez ou remplacez les backends concernés. Vous n'avez pas besoin d'un commutateur global.

Et la suite ?

Appliquer le secret avant TBC ; utiliser kubectl apply et -n trident pour correspondre aux exemples.