Skip to main content

Configure Google Cloud NetApp Volumes for SAN workloads

Contributors joan-ing

You can configure Trident to provision block storage volumes using the iSCSI protocol from Google Cloud NetApp Volumes. SAN volumes are provisioned from Flex Unified storage pools by using the google-cloud-netapp-volumes-san storage driver.

Note This driver is dedicated to block workloads and does not support NAS protocols.
Note The google-cloud-netapp-volumes-san backend is required to provision iSCSI block volumes. The google-cloud-netapp-volumes backend supports NAS protocols only and cannot be used for SAN workloads.

Overview

Trident supports Google Cloud NetApp Volumes SAN (iSCSI) workloads using the google-cloud-netapp-volumes-san driver.

SAN volumes are provisioned from Flex Unified storage pools and presented to Kubernetes nodes as iSCSI block devices.

This applies to the following environments:

  • Trident 26.02 and later

  • Google Kubernetes Engine (GKE) or Red Hat OpenShift

  • Google Cloud NetApp Volumes Flex Unified storage pools

  • iSCSI-based workloads

Flex Unified storage pools

Flex Unified storage pools provide block storage using the iSCSI protocol and are required for SAN provisioning:

  • Flex Unified REGIONAL pools are supported.

  • Flex Unified ZONAL pools are supported starting with Trident 26.02.1.

  • Only the Flex service level is supported for SAN workloads.

Configure a Trident SAN backend

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

Create a StorageClass

After configuring the SAN backend, create a StorageClass that references the google-cloud-netapp-volumes-san driver.

The filesystem type is defined in the StorageClass, not in the 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

Supported filesystem types:

  • ext4 (default)

  • ext3

  • xfs

Note The SAN driver supports only the Flex service level and does not use NAS-specific backend parameters such as exportRule, unixPermissions, nasType, snapshotDir, nfsMountOptions, or tiering-related settings.

Provision block volumes

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)

A common pattern for ROX is to clone an existing ReadWriteOnce volume and mount the clone as read-only.

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

ReadWriteMany is supported only when volumeMode: Block.

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

Block volume behavior

Block volumes are provisioned as iSCSI LUNs and presented to Kubernetes nodes as block devices.

Block volumes:

  • Use the iSCSI protocol

  • Support filesystem and raw block presentation

  • Are attached and managed by Trident

  • Support multiple Kubernetes access modes

Access modes

Block volumes provisioned by Trident support the following access modes:

  • ReadWriteOnce (RWO)

  • ReadOnlyMany (ROX)

  • ReadWriteOncePod (RWOP)

  • ReadWriteMany (RWX), supported only when volumeMode: Block

volumeMode behavior

The volumeMode field controls how a block volume is exposed:

  • Filesystem
    Trident formats and mounts the volume.

  • Block
    Trident attaches the device and exposes it as a raw block device.

Supported operations

Block volumes provisioned using the google-cloud-netapp-volumes-san driver support:

  • Create

  • Delete

  • Clone

  • Snapshot

  • Resize

  • Import

Extra GiB overprovisioning behavior

Google Cloud NetApp Volumes block volumes include internal metadata overhead. This overhead reduces the kernel-visible device size compared to the provisioned capacity.

Testing shows:

  • Approximately 300 KiB overhead on initial creation

  • Up to approximately 107 MiB overhead after a resize

Because Google Cloud NetApp Volumes accepts only whole-GiB allocations, Trident ensures that the usable device size always meets or exceeds the PVC request by:

  • Rounding the requested size up to the next whole GiB

  • Adding an additional 1 GiB buffer

Example:

  • PVC request: 100 GiB

  • Provisioned size in Google Cloud NetApp Volumes: 101 GiB

  • Usable space visible to the application: at least 100 GiB

Pod examples

Filesystem-mounted block volume (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

Raw block device (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

Attach and mount behavior

For SAN volumes provisioned from Google Cloud NetApp Volumes:

  • Trident creates a Logical Unit Number (LUN) in a Flex Unified storage pool.

  • During publish, Trident maps the LUN to a per-node host group.

  • During node staging, Trident:

    • Logs in to the iSCSI target

    • Discovers the LUN

    • Configures multipath

  • If volumeMode: Filesystem, Trident formats the device if required and mounts it.

  • If volumeMode: Block, Trident attaches the device and exposes it directly to the pod without formatting or mounting.

Note SAN block volumes do not provide distributed locking or write coordination. When a block volume is accessed by multiple nodes (ReadWriteMany with volumeMode: Block), the application or filesystem must manage concurrency.