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

Configurer Google Cloud NetApp Volumes pour les charges de travail SAN

11/03/2026 Contributeurs

Utilisez le google-cloud-netapp-volumes-san pilote pour provisionner des volumes de blocs iSCSI à partir des pools de stockage Google Cloud NetApp Volumes Flex Unified.

Le pilote SAN prend uniquement en charge les charges de travail par blocs. Pour provisionner des volumes NAS, utilisez le google-cloud-netapp-volumes pilote approprié.

Présentation

Le pilote provisionne des volumes à partir de pools de stockage Flex Unified et les présente aux nœuds Kubernetes en tant que périphériques de bloc iSCSI.

Le pilote prend en charge les environnements suivants :

Trident 26.02 et versions ultérieures
Google Kubernetes Engine (GKE) ou des clusters Red Hat OpenShift exécutés sur GCP
Google Cloud NetApp Volumes Flex Pools de stockage unifiés
Charges de travail basées sur iSCSI

À partir de Trident 26.10, le pilote SAN prend en charge Google Cloud Workload Identity Federation (WIF) sur les clusters OpenShift Container Platform autogérés (OCP, y compris les déploiements IPI) et les clusters OpenShift Dedicated (OSD) exécutés sur GCP. Pour connaître les prérequis de WIF et la configuration du backend, consultez "Utilisez la fédération d'identité de workload sur OpenShift". Utilisez le nom du pilote SAN et les paramètres de stockage Flex Unified sur cette page.

Configurer WIF pour le SAN

WIF échange un jeton projeté de compte de service Kubernetes contre des identifiants Google Cloud de courte durée. Trident utilise ces identifiants pour emprunter l’identité d’un compte de service Google Cloud lorsqu’il appelle l’API Google Cloud NetApp Volumes.

Configurez un pool d'identités de workload Google Cloud et un fournisseur OIDC pour le cluster OpenShift. L’émetteur du fournisseur doit correspondre à la revendication iss du jeton, et son mappage d’attributs doit mapper assertion.sub sur google.subject.

Installez Trident en spécifiant le nom de ressource du fournisseur comme audience WIF. Cela permet à Trident de projeter le jeton du compte de service du contrôleur à /var/run/secrets/wif-token/token.

Opérateur 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>"

Gouvernail

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

Utilisez la même audience pour l’installation de Trident et wipCredentialConfig.audience. Ne configurez pas non plus GKE cloudIdentity ou --cloud-identity. Ne modifiez pas le Deployment du contrôleur pour ajouter le jeton projeté ; le Trident operator peut remplacer cette modification.

Sur OpenShift Dedicated, le fournisseur OIDC peut être partagé avec d’autres composants OpenShift. Si la liste du fournisseur allowedAudiences est vide, Google accepte le nom de ressource canonique du fournisseur, avec ou sans le https:// préfixe, de sorte qu’aucune modification du fournisseur n’est nécessaire pour l’audience ci-dessus. Ne définissez pas de liste d’audience explicite uniquement pour Trident. Si le fournisseur a déjà des audiences explicites, ajoutez l’audience Trident tout en conservant toutes les valeurs existantes. Le remplacement de la liste peut empêcher d’autres composants OpenShift d’échanger des jetons.

Accordez au principal WIF du compte de service du contrôleur Trident le rôle roles/iam.workloadIdentityUser sur le compte de service Google Cloud que Trident empruntera. Pour le compte de service du contrôleur Trident par défaut, le sujet du jeton est system:serviceaccount:trident:trident-controller; utilisez le sujet configuré pour votre installation. Accordez au compte de service emprunté roles/netapp.admin, ou des autorisations équivalentes, sur le projet contenant les ressources Google Cloud NetApp Volumes.

Ajoutez la strophe suivante au spec du 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 configuration WIF est identique pour les deux pilotes GCNV. Le backend SAN doit toujours utiliser google-cloud-netapp-volumes-san et un pool de stockage Flex Unified pris en charge.

Pools de stockage Flex Unified

Les pools de stockage Flex Unified fournissent du stockage bloc utilisant le protocole iSCSI et sont nécessaires au provisionnement SAN :

Les pools régionaux Flex Unified sont pris en charge.
Les pools ZONAL Flex Unified sont pris en charge à partir de Trident 26.02.1.
Seul le niveau de service Flex est pris en charge pour les charges de travail SAN.

Le backend location doit correspondre à la région du pool Flex Unified. Si Trident ne trouve pas le pool, vérifiez la région, le réseau et le chemin d'accès aux ressources du pool.

Configurer 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

Créer un StorageClass

Après avoir configuré le backend SAN, créez un StorageClass qui référence le google-cloud-netapp-volumes-san driver.

Spécifiez le type de système de fichiers dans la StorageClass, et non dans le 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

Le pilote prend en charge les types de systèmes de fichiers suivants :

ext4 (défaut)
ext3
xfs

Le pilote SAN ne prend en charge que le niveau de service Flex et n'utilise pas les paramètres backend spécifiques au NAS tels que exportRule, unixPermissions, nasType, snapshotDir, nfsMountOptions ou les paramètres liés à la hiérarchisation.

Vérifier le provisionnement WIF

Appliquez le backend et vérifiez que TridentBackendConfig est lié et que sa dernière opération a réussi :

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

Créez un PVC à l’aide de la gcnv-san StorageClass de cette page et vérifiez qu’il atteint Bound. Cela valide ensemble l’échange WIF, l’emprunt d’identité du compte de service, les autorisations de Google Cloud NetApp Volumes et la sélection du pool SAN. Supprimez le PVC de test lorsque vous avez terminé.

En cas d’échec de la réconciliation du backend, consultez les journaux du contrôleur Trident :

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

Vérifiez les points suivants pour détecter les erreurs courantes :

En cas d' invalid_grant`erreur d'audience, comparez la revendication `aud du jeton avec les audiences autorisées du fournisseur OIDC et wipCredentialConfig.audience.
Pour une iam.serviceAccounts.getAccessToken erreur d'autorisation, vérifiez que le principal WIF du contrôleur Trident possède roles/iam.workloadIdentityUser sur le compte de service usurpé.
En cas d `netapp.storagePools.list'erreur d'autorisation, vérifiez que le compte de service usurpé dispose des autorisations Google Cloud NetApp Volumes requises sur le projet approprié.
Si le pool est introuvable, vérifiez que son emplacement et son type sont pris en charge, que la région du backend correspond à la région du pool et que le backend fait référence au réseau et au pool corrects.

Approvisionner des volumes de blocs

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)

Une méthode courante pour ROX consiste à cloner un volume ReadWriteOnce existant et à monter le clone en lecture seule.

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) — bloc brut uniquement

ReadWriteMany n'est pris en charge que lorsque volumeMode: Block.

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

Comportement du volume de bloc

Les volumes de blocs sont provisionnés en tant que LUN iSCSI et présentés aux nœuds Kubernetes en tant que périphériques de blocs.

Volumes de blocs :

Utilisez le protocole iSCSI
Prise en charge du système de fichiers et de la présentation des blocs bruts
Sont rattachés et gérés par Trident
Prise en charge de plusieurs modes d'accès Kubernetes

Modes d'accès

Les volumes de blocs provisionnés par Trident prennent en charge les modes d'accès suivants :

ReadWriteOnce (RWO)
ReadOnlyMany (ROX)
ReadWriteOncePod (RWOP)
ReadWriteMany (RWX), pris en charge uniquement lorsque volumeMode: Block

Comportement de volumeMode

Le `volumeMode`champ contrôle la façon dont un volume de bloc est exposé :

Filesystem Trident formate et monte le volume.
Block Trident attache le périphérique et l'expose comme un périphérique de bloc brut.

Opérations prises en charge

Volumes de blocs provisionnés à l'aide du pilote google-cloud-netapp-volumes-san prennent en charge :

Créer
Supprimer
Cloner
Snapshot
Redimensionner
Importer

Surcharge de taille du volume

Les volumes de blocs Google Cloud NetApp Volumes incluent des métadonnées internes. Par conséquent, la taille du périphérique visible par le noyau est inférieure à la capacité provisionnée.

Surcharge observée :

Environ 300 Kio lors de la création d'un volume
Jusqu'à environ 107 MiB après un redimensionnement

Google Cloud NetApp Volumes accepte les allocations de capacité en Gio entiers. Pour garantir que la taille utilisable du périphérique respecte ou dépasse la demande de PVC, Trident :

Arrondit la taille demandée au Gio entier supérieur.
Ajoute une mémoire tampon de 1 Gio.

Par exemple :

Demande de PVC : 100 Gio.
Capacité provisionnée: 101 GiB.
Capacité utilisable visible pour l'application : au moins 100 Gio.

Exemples de pods

Volume de bloc monté sur le système de fichiers (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

Périphérique de bloc brut (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

Comportement d’attachement et de montage

Pour les volumes SAN provisionnés à partir de Google Cloud NetApp Volumes :

Trident crée un Logical Unit Number (LUN) dans un pool de stockage Flex Unified.
Lors de la publication, Trident associe le LUN à un groupe d'hôtes par nœud.
Lors de la mise en scène des nœuds, Trident :
- Se connecte à la cible iSCSI
- Découvre le LUN
- Configure le multipath
Si `volumeMode: Filesystem`Trident le nécessite, Trident formate le périphérique et le monte.
Si volumeMode: Block Trident attache le périphérique et l'expose directement au pod sans le formater ni le monter.

Les volumes de blocs SAN ne prennent pas en charge le verrouillage distribué ni la coordination des écritures. Lorsqu'un volume de blocs est accédé par plusieurs nœuds (ReadWriteMany avec volumeMode: Block), l'application ou le système de fichiers doit gérer la concurrence.