Accede a instancias de Managed Lustre existentes en GKE con el controlador Managed Lustre CSI

En esta guía, se describe cómo puedes conectarte a una instancia de Managed Lustre existente con el controlador de CSI de Managed Lustre. Esto te permite acceder a las instancias de Managed Lustre existentes como volúmenes para tus cargas de trabajo con estado, de una manera controlada y predecible.

Compatibilidad con multi-NIC para redes de alto rendimiento

En los clústeres de GKE que ejecutan la versión 1.35.2-gke.1842000 o una posterior, el controlador de CSI de Managed Lustre está habilitado de forma predeterminada para usar todas las tarjetas de interfaz de red (NIC) disponibles y aumentar la capacidad de procesamiento. Esta compatibilidad agrega ancho de banda distribuyendo el tráfico de almacenamiento de TCP entre tus interfaces de red.

Para usar la compatibilidad con varias NIC, tus nodos deben cumplir con los siguientes requisitos:

  • NIC estándar para TCP: Tus nodos deben usar NIC estándar, como la NIC virtual de Google (gVNIC) o VirtIO-Net, para controlar el tráfico de almacenamiento de TCP.
  • Misma VPC: Todas las NIC estándar deben residir en la misma red de VPC.
  • Consideraciones sobre RDMA: Tus nodos también pueden tener NIC de RDMA conectadas. Sin embargo, el controlador de CSI de Managed Lustre solo usa las NIC estándar para el tráfico de almacenamiento de TCP.

Si deseas inhabilitar la compatibilidad con varias NIC, consulta Inhabilita varias NIC para Lustre.

Puertos de comunicación de Lustre

El controlador de CSI de Managed Lustre de GKE usa diferentes puertos para la comunicación con las instancias de Managed Lustre, según la versión del clúster de GKE y las configuraciones existentes de Managed Lustre.

  • Puerto predeterminado (recomendado): En los clústeres de GKE nuevos que ejecutan la versión 1.33.2-gke.4780000 o una posterior, el controlador usa el puerto 988 para la comunicación de Lustre de forma predeterminada.

  • Puerto heredado (obsoleto): Usa el puerto 6988 agregando la marca --enable-legacy-lustre-port a tus comandos gcloud en las siguientes situaciones:

    • Versiones anteriores de GKE: Si tu clúster de GKE ejecuta una versión anterior a la 1.33.2-gke.4780000, la marca --enable-legacy-lustre-port soluciona un conflicto de puertos con el gke-metadata-server en los nodos de GKE.
    • Instancias de Lustre existentes: Si te conectas a una instancia de Managed Lustre existente que se creó con la marca gke-support-enabled, debes incluir --enable-legacy-lustre-port en tus comandos gcloud, independientemente de la versión del clúster. Sin esta marca, tu clúster de GKE no podrá activar la instancia de Lustre existente.

Puedes configurar los clústeres nuevos y existentes para que usen el puerto predeterminado 988 o el puerto heredado 6988.

Antes de comenzar

Antes de comenzar, asegúrate de haber realizado las siguientes tareas:

  • Habilita la API de Google Cloud Managed Lustre y la API de Google Kubernetes Engine.
    • Habilita las APIs
  • Para usar Google Cloud CLI en esta tarea, instala y, luego, inicializa la gcloud CLI. Si ya instalaste gcloud CLI, ejecuta el comando gcloud components update para obtener la versión más reciente. Es posible que las versiones anteriores de gcloud CLI no admitan la ejecución de los comandos de este documento.

Configura variables de entorno

Configura las siguientes variables de entorno:

export CLUSTER_NAME=CLUSTER_NAME
export PROJECT_ID=PROJECT_ID
export NETWORK_NAME=LUSTRE_NETWORK
export LOCATION=ZONE

Reemplaza lo siguiente:

  • CLUSTER_NAME: el nombre del clúster
  • PROJECT_ID: Es el ID del proyecto de Google Cloud .
  • LUSTRE_NETWORK: Es la red de nube privada virtual compartida en la que residen el clúster de GKE y la instancia de Managed Lustre.
  • ZONE: Es la zona geográfica de tu clúster de GKE, por ejemplo, us-central1-a.

Configura el controlador de CSI de Managed Lustre

En esta sección, se explica cómo habilitar e inhabilitar el controlador de CSI de Managed Lustre.

Habilita el controlador de CSI de Managed Lustre en un clúster de GKE nuevo

En las siguientes secciones, se describe cómo habilitar el controlador de CSI de Managed Lustre en un clúster de GKE nuevo.

Usa el puerto predeterminado 988

Para habilitar el controlador de CSI de Managed Lustre cuando crees un clúster de GKE nuevo que ejecute la versión 1.33.2-gke.4780000 o una posterior, ejecuta el siguiente comando:

Autopilot

gcloud container clusters create-auto "${CLUSTER_NAME}" \
    --location=${LOCATION} \
    --network="${NETWORK_NAME}" \
    --cluster-version=${CLUSTER_VERSION} \
    --enable-lustre-csi-driver

Estándar

gcloud container clusters create "${CLUSTER_NAME}" \
    --location=${LOCATION} \
    --network="${NETWORK_NAME}" \
    --cluster-version=${CLUSTER_VERSION} \
    --addons=LustreCsiDriver

Usa el puerto heredado 6988

Para habilitar el controlador de CSI de Managed Lustre cuando creas un clúster de GKE nuevo que ejecuta una versión anterior a la 1.33.2-gke.4780000, ejecuta el siguiente comando:

Autopilot

gcloud container clusters create-auto "${CLUSTER_NAME}" \
    --location=${LOCATION} \
    --network="${NETWORK_NAME}" \
    --cluster-version=${CLUSTER_VERSION} \
    --enable-lustre-csi-driver \
    --enable-legacy-lustre-port

Estándar

gcloud container clusters create "${CLUSTER_NAME}" \
    --location=${LOCATION} \
    --network="${NETWORK_NAME}" \
    --cluster-version=${CLUSTER_VERSION} \
    --addons=LustreCsiDriver \
    --enable-legacy-lustre-port

Habilita el controlador de CSI de Managed Lustre en clústeres de GKE existentes

En las siguientes secciones, se describe cómo habilitar el controlador de CSI de Managed Lustre en clústeres de GKE existentes.

Usa el puerto predeterminado 988

Para habilitar el controlador de CSI de Managed Lustre en un clúster de GKE existente que ejecute la versión 1.33.2-gke.4780000 o una posterior, ejecuta el siguiente comando:

  gcloud container clusters update ${CLUSTER_NAME} \
      --location=${LOCATION} \
      --update-addons=LustreCsiDriver=ENABLED

Usa el puerto heredado 6988

Para habilitar el controlador de CSI de Managed Lustre en un clúster de GKE existente, es posible que debas usar el puerto heredado 6988 agregando la marca --enable-legacy-lustre-port. Esta marca es obligatoria en las siguientes situaciones:

  • Si tu clúster de GKE se ejecuta en una versión anterior a la 1.33.2-gke.4780000.

  • Si tienes la intención de conectar este clúster a una instancia de Managed Lustre existente que se creó con la marca gke-support-enabled.

    gcloud container clusters update ${CLUSTER_NAME} \
    --location=${LOCATION} \
    --enable-legacy-lustre-port

Se requiere una actualización de nodos en los clústeres existentes

Habilitar el controlador de CSI de Managed Lustre en clústeres existentes puede activar la recreación de nodos para actualizar los módulos de kernel necesarios para el cliente de Managed Lustre. Para que estén disponibles de inmediato, te recomendamos que actualices tus grupos de nodos de forma manual.

Los clústeres de GKE en un canal de versiones se actualizan según su lanzamiento programado, que puede tardar varias semanas según tu período de mantenimiento. Si usas una versión estática de GKE, debes actualizar manualmente tus grupos de nodos.

Hasta que se complete la actualización del nodo, el Pod del controlador de CSI podría fallar en un bucle en los nodos pendientes de actualización. Si ves un error Operation not permitted en los registros del Pod del controlador de CSI, esto indica que se requiere la actualización o la recreación del nodo.

Después de la actualización del grupo de nodos, es posible que los nodos de CPU parezcan usar una imagen de GPU en la consola de Google Cloud o en el resultado de la CLI. Se espera que esto suceda. La imagen de GPU se reutiliza en los nodos de CPU para instalar de forma segura los módulos de kernel de Managed Lustre. No se te cobrará por el uso de la GPU.

Crea un grupo de nodos con varias NIC (opcional)

Para usar redes de alto rendimiento, debes crear un grupo de nodos con un tipo de instancia que admita múltiples interfaces de red. La compatibilidad con multi-NIC está habilitada de forma predeterminada en los clústeres de GKE que ejecutan la versión 1.35.2-gke.1842000 o una posterior. Asegúrate de que tus interfaces de red secundarias residan en la misma red de VPC que tu interfaz principal.

Ejecuta el comando siguiente:

gcloud container node-pools create NODE_POOL_NAME \
    --cluster=CLUSTER_NAME \
    --location=LOCATION \
    --machine-type=MACHINE_TYPE \
    --enable-gvnic \
    --additional-node-network network=NETWORK_NAME,subnetwork=SECONDARY_SUBNET

Reemplaza lo siguiente:

  • NODE_POOL_NAME: es el nombre de tu grupo de nodos.
  • CLUSTER_NAME: El nombre de tu clúster.
  • LOCATION: Es la región o la zona de tu clúster.
  • MACHINE_TYPE: Es el tipo de máquina para el grupo de nodos, como a3-megagpu-8g, que suele usarse con multi-NIC para obtener un alto rendimiento. La función de varias NIC es compatible con cualquier tipo de máquina.
  • NETWORK_NAME: Es el nombre de la red de VPC.
  • SECONDARY_SUBNET: el nombre de la subred secundaria.

Inhabilita la multi-NIC en Lustre

Si bien se recomienda la compatibilidad con multi-NIC para las cargas de trabajo de alto rendimiento, es posible que quieras inhabilitarla en situaciones específicas. Por ejemplo, es posible que no quieras distribuir el tráfico de Lustre entre todas las interfaces de hardware disponibles o que necesites aislar los problemas de conectividad en una sola ruta de red para solucionar problemas.

Nota: Si inhabilitas la compatibilidad con multi-NIC en los nodos en ejecución, es posible que debas volver a crear o actualizar manualmente tus grupos de nodos para que se aplique este cambio.

Para un clúster

Para inhabilitar las redes de alto rendimiento en todo el clúster, usa la marca --disable-multi-nic-lustre cuando crees o actualices el clúster. Por ejemplo:

gcloud container clusters update CLUSTER_NAME \
    --location=LOCATION \
    --disable-multi-nic-lustre

Reemplaza lo siguiente:

  • CLUSTER_NAME: El nombre de tu clúster.
  • LOCATION: Es la región o la zona de tu clúster.

Para un grupo de nodos

Para inhabilitar las redes de alto rendimiento en un grupo de nodos específico, actualiza el grupo de nodos para establecer la etiqueta lustre.csi.storage.gke.io/multi-nic en false:

gcloud container node-pools update NODE_POOL_NAME \
--cluster=CLUSTER_NAME \
--zone=LOCATION \
--node-labels=lustre.csi.storage.gke.io/multi-nic=false

Reemplaza lo siguiente:

  • NODE_POOL_NAME: es el nombre de tu grupo de nodos.
  • CLUSTER_NAME: El nombre de tu clúster.
  • LOCATION: Es la zona de tu clúster.

Inhabilita el controlador de CSI de Managed Lustre

Puedes inhabilitar el controlador de CSI de Managed Lustre en un clúster de GKE existente con Google Cloud CLI.

gcloud container clusters update ${CLUSTER_NAME} \
    --location=${LOCATION} \
    --update-addons=LustreCsiDriver=DISABLED

Después de inhabilitar el controlador de CSI, GKE vuelve a crear los nodos de forma automática y desinstala los módulos de kernel de Managed Lustre.

Accede a una instancia de Managed Lustre existente con el controlador de CSI de Managed Lustre

Si ya aprovisionaste una instancia de Managed Lustre en la misma red que tu clúster de GKE, puedes seguir estas instrucciones para aprovisionar de forma estática un PersistentVolume que haga referencia a tu instancia.

En las siguientes secciones, se describe el proceso típico para acceder a una instancia de Managed Lustre existente con el controlador CSI de Managed Lustre:

  1. Crea un PersistentVolume que haga referencia a la instancia de Managed Lustre.
  2. Usa un objeto PersistentVolumeClaim para acceder al volumen
  3. Crea una carga de trabajo que consuma el volumen

Crea un PersistentVolume

  1. Para ubicar tu instancia de Managed Lustre, ejecuta el siguiente comando.

    gcloud lustre instances list \
    --project=${PROJECT_ID} \
    --location=${LOCATION}

    El resultado debería ser similar al siguiente. Antes de continuar con el siguiente paso, asegúrate de anotar el nombre de la instancia de Managed Lustre, el sistema de archivos y los campos mountPoint.

    capacityGib: '9000'
createTime: '2025-04-28T22:42:11.140825450Z'
filesystem: testlfs
gkeSupportEnabled: true
mountPoint: 10.90.1.4@tcp:/testlfs
name: projects/my-project/locations/us-central1-a/instances/my-lustre
network: projects/my-project/global/networks/default
perUnitStorageThroughput: '1000'
state: ACTIVE
updateTime: '2025-04-28T22:51:41.559098631Z'

  2. Guarda el siguiente manifiesto como un archivo llamado lustre-pv.yaml:

    apiVersion: v1
kind: PersistentVolume
metadata:
  name: lustre-pv
spec:
  storageClassName: "STORAGE_CLASS_NAME"
  capacity:
    storage: 9000Gi
  accessModes:
    - ReadWriteMany
  persistentVolumeReclaimPolicy: Retain
  volumeMode: Filesystem
  claimRef:
    namespace: default
    name: lustre-pvc
  csi:
    driver: lustre.csi.storage.gke.io
    volumeHandle: "PROJECT_ID/LOCATION/INSTANCE_NAME"
    volumeAttributes:
      ip: IP_ADDRESS
      filesystem: FILESYSTEM

    Reemplaza lo siguiente:

    • storageClassName: Es el nombre de tu StorageClass. El valor puede ser una cadena vacía, pero debe cumplir con la especificación de tu PersistentVolumeClaim.
    • volumeHandle: Es el identificador de este volumen.
      • PROJECT_ID: Es el ID del proyecto de Google Cloud .
      • LOCATION: la ubicación zonal de tu instancia de Lustre. Debes especificar una zona compatible para el controlador de CSI de Managed Lustre.
      • INSTANCE_NAME: Es el nombre de tu instancia de Lustre.
    • ip: Es la dirección IP de tu instancia de Lustre. Obtienes esto del campo mountPoint en el resultado del comando anterior.
    • filesystem: Es el nombre del sistema de archivos de tu instancia de Managed Lustre.

    Para obtener la lista completa de los campos que se admiten en el objeto PersistentVolume, consulta la documentación de referencia del controlador de CSI de Managed Lustre.

  3. Ejecuta el siguiente comando para crear el PersistentVolume:

    kubectl apply -f lustre-pv.yaml

Usa el PersistentVolumeClaim para acceder al volumen

Puedes crear un recurso PersistentVolumeClaim que haga referencia a la StorageClass del controlador de CSI de Managed Lustre.

En el siguiente archivo de manifiesto, se muestra un ejemplo de cómo crear un PersistentVolumeClaim en el modo de acceso ReadWriteMany, que hace referencia a la StorageClass que creaste antes.

  1. Guarda el siguiente manifiesto como un archivo llamado lustre-pvc.yaml:

    kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: lustre-pvc
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: "STORAGE_CLASS_NAME"
  volumeName: lustre-pv
  resources:
    requests:
      storage: STORAGE_SIZE

    Reemplaza STORAGE_SIZE por el tamaño de almacenamiento, por ejemplo, 9000Gi. Debe coincidir con la especificación de tu PersistentVolume.

  2. Ejecuta el siguiente comando para crear la PersistentVolumeClaim:

    kubectl create -f lustre-pvc.yaml

Crea una carga de trabajo que consuma el volumen

En esta sección, se muestra cómo crear un Pod que consuma el recurso PersistentVolumeClaim que creaste antes.

Varios Pods pueden compartir el mismo recurso PersistentVolumeClaim.

  1. Guarda el siguiente manifiesto como un archivo llamado my-pod.yaml.

    apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
  - name: nginx
    image: nginx
    volumeMounts:
      - name: lustre-volume
        mountPath: /data
  volumes:
  - name: lustre-volume
    persistentVolumeClaim:
      claimName: lustre-pvc

  2. Ejecuta el siguiente comando para aplicar el manifiesto al clúster:

    kubectl apply -f my-pod.yaml

    El Pod espera hasta que GKE aprovisione PersistentVolumeClaim antes de comenzar a ejecutarse. Esta operación puede tardar varios minutos en completarse.

  3. Verifica que el Pod se esté ejecutando.

    kubectl get pods

    Es posible que el Pod tarde unos minutos en alcanzar el estado Running.

    El resultado es similar a lo siguiente:

    NAME           READY   STATUS    RESTARTS   AGE
my-pod         1/1     Running   0          11s

Usa fsGroup con volúmenes de Managed Lustre

Puedes cambiar la propiedad del grupo del directorio de nivel raíz del sistema de archivos activado para que coincida con un fsGroup solicitado por el usuario especificado en el SecurityContext del Pod.

Soluciona problemas

Para obtener orientación sobre la solución de problemas, consulta la página de solución de problemas en la documentación de Managed Lustre.

Realiza una limpieza

Para evitar que se apliquen cargos a tu cuenta de Google Cloud , borra los recursos de almacenamiento que creaste en esta guía.

  1. Borra el Pod y la PersistentVolumeClaim.

    kubectl delete pod my-pod
kubectl delete pvc lustre-pvc

  2. Verifica el estado del PersistentVolume. Después de borrar el Pod y la PersistentVolumeClaim, el PersistentVolume debería informar un estado "Liberado":

    kubectl get pv

    El resultado es similar a lo siguiente:

    NAME        CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS     CLAIM                 STORAGECLASS   REASON   AGE
lustre-pv   9000Gi      RWX            Retain        Released   default/preprov-pvc                           2m28s

  3. Vuelve a usar el PersistentVolume. Para volver a usar el PersistentVolume, quita la referencia de la reclamación (claimRef):

    kubectl patch pv lustre-pv --type json -p '[{"op": "remove", "path": "/spec/claimRef"}]'

    El PersistentVolume ahora debería informar un estado "Available", lo que indica que está listo para vincularse a un nuevo PersistentVolumeClaim. Verifica el estado del PersistentVolume:

    kubectl get pv

    El resultado es similar a lo siguiente:

    NAME        CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   REASON   AGE
lustre-pv   9000Gi      RWX           Retain         Available                                   19m

  4. Borra el PersistentVolume si ya no es necesario. Si ya no necesitas el PersistentVolume, bórralo:

    kubectl delete pv lustre-pv

    Borrar el PersistentVolume no quita la instancia de Managed Lustre subyacente.

¿Qué sigue?