Se usó la API de Cloud Translation para traducir esta página.

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

Autopilot Estándar

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 instancias de Managed Lustre existentes como volúmenes para tus cargas de trabajo con estado, de una manera controlada y predecible.

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

Si deseas usar Google Cloud CLI para esta tarea, instala y, luego, inicializa gcloud CLI. Si ya instalaste gcloud CLI, ejecuta gcloud components update para obtener la versión más reciente.
Nota: Para las instalaciones de gcloud CLI existentes, asegúrate de configurar las propiedades compute/region y compute/zone. Cuando configuras las ubicaciones predeterminadas, puedes evitar errores en la CLI de gcloud como el siguiente: One of [--zone, --region] must be supplied: Please specify location.

Para conocer las limitaciones y los requisitos, consulta la [descripción general del controlador de CSI].
Asegúrate de habilitar el controlador de CSI de Lustre administrado. Está inhabilitado de forma predeterminada en los clústeres de Standard y Autopilot.

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: El Trusted Cloud by S3NS ID del proyecto.
LUSTRE_NETWORK: Es la red de nube privada virtual compartida en la que residen tanto el clúster de GKE como la instancia de Lustre administrada.
ZONE: La zona geográfica de tu clúster de GKE, por ejemplo, us-central1-a.

Configura el controlador CSI de Lustre administrado

En esta sección, se explica cómo habilitar e inhabilitar el controlador CSI de Lustre administrado, si es necesario.

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

Para habilitar el controlador de CSI de Lustre administrado cuando crees un clúster de GKE nuevo, sigue estos pasos:

Autopilot

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

Estándar

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

Habilita el controlador de CSI de Lustre administrado en un clúster de GKE existente

Si deseas habilitar el controlador de CSI de Lustre administrado en un clúster de GKE existente, usa el siguiente comando:

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

Después de habilitar el controlador de CSI de Lustre administrado en tu clúster, es posible que observes que se recrearon tus nodos y que los nodos de CPU parecen usar una imagen de GPU en la consola deTrusted Cloud o en el resultado de la CLI. Por ejemplo:

config:
  imageType: COS_CONTAINERD
  nodeImageConfig:
    image: gke-1330-gke1552000-cos-121-18867-90-4-c-nvda

Se espera que esto suceda. La imagen de GPU se reutiliza en los nodos de CPU para instalar de forma segura los módulos del kernel de Lustre administrado. No se te cobrará de más por el uso de la GPU.

Inhabilita el controlador de CSI de Lustre administrado

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

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

Una vez que se inhabilite el controlador CSI, se volverán a crear automáticamente los nodos y se desinstalarán los módulos del kernel de Lustre administrado de los nodos de GKE.

Accede a una instancia de Managed Lustre existente con el controlador 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 existente de Lustre administrado con el controlador CSI de Lustre administrado:

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

Crea un PersistentVolume

Para ubicar tu instancia de Lustre administrado, 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 los campos Nombre de la instancia de Lustre administrada, filesystem y mountPoint.

capacityGib: '18000'
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'

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: 18000Gi
  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: El ID del proyecto de Trusted Cloud by S3NS .
  - LOCATION: Es la ubicación zonal de tu instancia de Lustre. Debes especificar una zona compatible para el controlador CSI de Lustre administrado.
  - INSTANCE_NAME: Es el nombre de tu instancia de Lustre.
- ip: Es la dirección IP de tu instancia de Lustre. Obtienes este valor 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 admitidos en el objeto PersistentVolume, consulta la documentación de referencia del controlador de CSI de Lustre administrado.
Ejecuta este comando para crear el PersistentVolume:
```
kubectl apply -f lustre-pv.yaml
```

Usa el objeto PersistentVolumeClaim para acceder al volumen

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

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.

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, 18000Gi. Debe coincidir con la especificación de tu PersistentVolume.

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 de PersistentVolumeClaim que creaste antes.

Varios Pods pueden compartir el mismo recurso PersistentVolumeClaim.

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

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.
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 este:
```
  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 y 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 Lustre administrado.

Realiza una limpieza

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

Borra el Pod y el PersistentVolumeClaim.

Nota: Cuando creas el PersistentVolume con un "Retain" persistentVolumeReclaimPolicy, borrar el PersistentVolumeClaim no quitará el PersistentVolume ni la instancia de Managed Lustre subyacente.
```
kubectl delete pod my-pod
kubectl delete pvc lustre-pvc
```

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

kubectl get pv

El resultado es similar a este:

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

Reutiliza 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 "Disponible", lo que indica que está listo para vincularse a un nuevo PersistentVolumeClaim. Verifica el estado de PersistentVolume:
```
kubectl get pv
```
El resultado es similar a este:
```
NAME        CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM   STORAGECLASS   REASON   AGE
lustre-pv   18000Gi      RWX           Retain         Available                                   19m
```
Borra el PersistentVolume si ya no lo necesitas. 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?

Explora la documentación de Managed Lustre.