Se proporciona el idioma español mediante traducción automática para su comodidad. En caso de alguna inconsistencia, el inglés precede al español.

Configura Google Cloud NetApp Volumes para cargas de trabajo SAN

02/27/2026 Colaboradores

PDF

Puedes configurar Trident para aprovisionar volúmenes de almacenamiento en bloque usando el protocolo iSCSI desde Google Cloud NetApp Volumes. Los volúmenes SAN se aprovisionan desde pools de almacenamiento Flex Unified usando el controlador de almacenamiento google-cloud-netapp-volumes-san.

Este controlador está dedicado a cargas de trabajo en bloque y no es compatible con protocolos NAS.

El google-cloud-netapp-volumes-san backend es necesario para aprovisionar volúmenes de bloques iSCSI. El google-cloud-netapp-volumes backend admite solo protocolos NAS y no puede usarse para cargas de trabajo SAN.

Volúmenes NAS y volúmenes de bloques iSCSI

Google Cloud NetApp Volumes es compatible tanto con NAS como con block storage, que difieren en cómo las aplicaciones acceden y gestionan los datos.

Los volúmenes NAS proporcionan almacenamiento basado en archivos y se montan como sistemas de archivos compartidos usando NFS o SMB. Estos volúmenes se suelen usar cuando varios pods o nodos necesitan acceso simultáneo a los mismos datos.

Los volúmenes de bloque iSCSI proporcionan almacenamiento en bloque sin procesar y se conectan a los nodos de Kubernetes como dispositivos de bloque. Cada volumen se aprovisiona como un Logical Unit Number (LUN) y se accede usando el protocolo iSCSI. El almacenamiento en bloque normalmente se usa cuando las cargas de trabajo requieren acceso a nivel de bloque o un comportamiento de E/S gestionado por la aplicación.

Puedes implementar cargas de trabajo orientadas a bloques en Google Kubernetes Engine usando almacenamiento iSCSI gestionado por Trident respaldado por pools de Flex Unified Google Cloud NetApp Volumes.

Esto se aplica a los siguientes entornos:

Trident 26.02 y posteriores
Google Kubernetes Engine (GKE)
Pools de almacenamiento Flex Unified de Google Cloud NetApp Volumes
cargas de trabajo basadas en bloques iSCSI

Sólo se admite el nivel de servicio Flex para cargas de trabajo SAN en Trident 26.02.

Descripción general de la arquitectura de almacenamiento

Para cargas de trabajo SAN, Trident aprovisiona almacenamiento en bloque creando iSCSI Logical Unit Numbers (LUNs) en grupos de almacenamiento Flex Unified.

Cada PersistentVolume de Kubernetes corresponde a un único LUN. Trident gestiona el ciclo de vida completo del LUN, incluida la creación, la asignación de hosts, la conexión y la limpieza.

Pools de almacenamiento unificado Flex

Los grupos de almacenamiento Flex Unified proporcionan almacenamiento en bloque usando el protocolo iSCSI y son necesarios para el aprovisionamiento SAN.

Para Trident 26.02:

Solo se admiten grupos Flex Unified REGIONAL
Los grupos ZONALES de Flex Unified son compatibles a partir de Trident 26.02.1
Solo se admite el nivel de servicio Flex para cargas de trabajo SAN

Volúmenes en bloque

Los volúmenes de bloques se aprovisionan como LUN iSCSI y se presentan a los nodos de Kubernetes como dispositivos de bloque.

Volúmenes en bloque:

Usa el protocolo iSCSI
Soporte para sistema de archivos y presentación de bloques sin procesar
Están adjuntos y gestionados por Trident
Soporta múltiples modos de acceso a Kubernetes

Modos de acceso

Los volúmenes en bloque aprovisionados por Trident admiten los siguientes modos de acceso:

ReadWriteOnce (RWO)
ReadOnlyMany (ROX)
ReadWriteOncePod (RWOP)
ReadWriteMany (RWX), compatible solo cuando volumeMode: Block

volumeMode comportamiento

El volumeMode campo controla cómo se expone un volumen de bloque:

Filesystem Trident formatea y monta el volumen.
Block Trident conecta el dispositivo y lo expone como un dispositivo de bloque sin procesar.

Configura un backend Trident SAN

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 para cargas de trabajo SAN

Después de configurar el backend SAN, crea un StorageClass que haga referencia al google-cloud-netapp-volumes-san driver.

El tipo de sistema de archivos se define en el StorageClass, no en el 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

Tipos de sistemas de archivos compatibles:

ext4 (predeterminado)
ext3
xfs

El controlador SAN solo es compatible con el nivel de servicio Flex y no utiliza parámetros de backend específicos de NAS como exportRule, unixPermissions, nasType, snapshotDir, nfsMountOptions o configuraciones relacionadas con el tiering.

Operaciones compatibles

Los volúmenes en bloque aprovisionados usando el controlador google-cloud-netapp-volumes-san admiten:

Crear
Borrar
Clonar
Snapshot
Cambie el tamaño
Importar

Provisiona volúmenes en bloque

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 patrón común para ROX es clonar un volumen ReadWriteOnce existente y montar el clon como de solo lectura.

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 bloque en bruto

ReadWriteMany solo se admite cuando volumeMode: Block.

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

Comportamiento de la sobreaprovisionamiento de GiB extra

Google Cloud NetApp Volumes los volúmenes en bloque incluyen una sobrecarga interna de metadatos. Esta sobrecarga reduce el tamaño del dispositivo visible desde el kernel en comparación con la capacidad provisionada.

Las pruebas muestran:

Aproximadamente 300 KiB de sobrecarga en la creación inicial
Hasta aproximadamente 107 MiB de sobrecarga después de un redimensionamiento

Porque Google Cloud NetApp Volumes acepta solo asignaciones de GiB enteros, Trident se asegura de que el tamaño utilizable del dispositivo siempre cumpla o supere la solicitud de PVC:

Redondeando el tamaño solicitado al siguiente GiB entero
Agregando un búfer adicional de 1 GiB

Ejemplo:

Solicitud de PVC: 100 GiB
Tamaño aprovisionado en Google Cloud NetApp Volumes: 101 GiB
Espacio útil visible para la aplicación: al menos 100 GiB

Esto garantiza que las aplicaciones siempre reciban la capacidad solicitada, incluso después de tener en cuenta la sobrecarga interna de metadatos.

Ejemplos de pods

Volumen de bloque montado en el sistema de archivos (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 de bloque 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

Comportamiento de attach y mount

Para volúmenes SAN aprovisionados desde Google Cloud NetApp Volumes:

Trident crea un Logical Unit Number (LUN) en un grupo de almacenamiento Flex Unified.
Durante la publicación, Trident asigna el LUN a un grupo de hosts por nodo.
Durante la puesta en escena del nodo, Trident:
- Inicia sesión en el target iSCSI
- Descubre el LUN
- Configura multivía
Si volumeMode: Filesystem, Trident formatea el dispositivo si es necesario y lo monta.
Si volumeMode: Block, Trident conecta el dispositivo y lo expone directamente al pod sin formatear ni montar.

Los volúmenes de bloques SAN no proporcionan bloqueo distribuido ni coordinación de escritura. Cuando un volumen de bloques es accedido por varios nodos (ReadWriteMany con volumeMode: Block), la aplicación o el sistema de archivos debe gestionar la concurrencia.