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

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

Autopilot Estándar

En esta guía, se describe cómo puedes crear un nuevo volumen de Kubernetes respaldado por el controlador de CSI de Lustre administrado en GKE con aprovisionamiento dinámico. El controlador CSI de Managed Lustre te permite crear almacenamiento respaldado por instancias de Managed Lustre a pedido y acceder a ellas como volúmenes para tus cargas de trabajo con estado.

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 la propiedad compute/region. Si usas principalmente clústeres zonales, configura compute/zone en su lugar. Cuando configuras una ubicación predeterminada, puedes evitar errores en gcloud CLI como el siguiente: One of [--zone, --region] must be supplied: Please specify location. Es posible que debas especificar la ubicación en ciertos comandos si la ubicación de tu clúster difiere de la predeterminada que estableciste.

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 IP_RANGE_NAME=LUSTRE_IP_RANGE
export FIREWALL_RULE_NAME=LUSTRE_FIREWALL_RULE
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 (VPC) compartida en la que residen tanto el clúster de GKE como la instancia de Lustre administrada.
LUSTRE_IP_RANGE: Es el nombre del rango de direcciones IP creado para el peering de redes de VPC con Lustre administrado.
LUSTRE_FIREWALL_RULE: Es el nombre de la regla de firewall para permitir el tráfico TCP desde el rango de direcciones IP.
ZONE: La zona geográfica de tu clúster de GKE, por ejemplo, us-central1-a.

Configura una red de VPC

Debes especificar la misma red de VPC cuando crees la instancia de Lustre administrada y tus clústeres de GKE.

Para habilitar las redes de servicio, ejecuta el siguiente comando:

gcloud services enable servicenetworking.googleapis.com \
    --project=${PROJECT_ID}

Crear una red de VPC. Si estableces la marca --mtu en 8896, se obtiene un aumento del rendimiento del 10%.

gcloud compute networks create ${NETWORK_NAME} \
    --subnet-mode=auto --project=${PROJECT_ID} \
    --mtu=8896

Crea un rango de direcciones IP.

gcloud compute addresses create ${IP_RANGE_NAME} \
    --global \
    --purpose=VPC_PEERING \
    --prefix-length=20 \
    --description="Managed Lustre VPC Peering" \
    --network=${NETWORK_NAME} \
    --project=${PROJECT_ID}

Obtén el rango de CIDR asociado al rango que creaste en el paso anterior.

CIDR_RANGE=$(
  gcloud compute addresses describe ${IP_RANGE_NAME} \
      --global  \
      --format="value[separator=/](address, prefixLength)" \
      --project=${PROJECT_ID}
)

Crea una regla de firewall para permitir el tráfico de TCP desde el rango de direcciones IP que creaste.

gcloud compute firewall-rules create ${FIREWALL_RULE_NAME} \
    --allow=tcp:988,tcp:6988 \
    --network=${NETWORK_NAME} \
    --source-ranges=${CIDR_RANGE} \
    --project=${PROJECT_ID}

Para configurar el intercambio de tráfico entre redes de tu proyecto, verifica que tengas los permisos de IAM necesarios, específicamente el rol compute.networkAdmin o servicenetworking.networksAdmin.
1. Ve a Trusted Cloud console > IAM y administración y, luego, busca la entidad principal del propietario del proyecto.
2. Haz clic en el ícono de lápiz y, luego, en + AGREGAR OTRO ROL.
3. Selecciona Administrador de red de Compute o Administrador de redes de servicio.
4. Haz clic en Guardar.

Conecta el intercambio de tráfico.

gcloud services vpc-peerings connect \
    --network=${NETWORK_NAME} \
    --project=${PROJECT_ID} \
    --ranges=${IP_RANGE_NAME} \
    --service=servicenetworking.googleapis.com

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

Cuando se especifica la marca enable-legacy-lustre-port, el controlador CSI configura LNet (la capa de red virtual para el módulo del kernel de Lustre administrado) para usar el puerto 6988. Esta marca es necesaria para solucionar un conflicto de puertos con gke-metadata-server en los nodos de GKE.

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

Para habilitar el controlador 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

Habilitar el controlador de CSI de Lustre administrado puede activar la recreación de nodos para actualizar los módulos del kernel necesarios para el cliente de Lustre administrado. Para que esté disponible 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 el 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 de forma manual tus grupos de nodos.

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

Después de inhabilitar el controlador de CSI, GKE vuelve a crear automáticamente tus nodos y desinstala los módulos del kernel de Lustre administrado.

Crea un volumen nuevo con el controlador CSI de Lustre administrado

En las siguientes secciones, se describe el proceso típico para crear un volumen de Kubernetes respaldado por una instancia de Lustre administrada en GKE:

Crea un StorageClass.
Usa un objeto PersistentVolumeClaim para acceder al volumen
Crea una carga de trabajo que consuma el volumen

Crea un StorageClass

Cuando se habilita el controlador CSI de Lustre administrado, GKE crea automáticamente una StorageClass para aprovisionar instancias de Lustre administrado. La StorageClass depende del nivel de rendimiento de Lustre administrado. GKE, y es una de las siguientes opciones:

lustre-rwx-125mbps-per-tib
lustre-rwx-250mbps-per-tib
lustre-rwx-500mbps-per-tib
lustre-rwx-1000mbps-per-tib

GKE proporciona un StorageClass predeterminado para cada nivel de rendimiento de Lustre administrado compatible. Esto simplifica el aprovisionamiento dinámico de instancias de Lustre administrado, ya que puedes usar las StorageClasses integradas sin tener que definir las tuyas.

En el caso de los clústeres zonales, el controlador de CSI aprovisiona instancias de Lustre administrado en la misma zona que el clúster. En el caso de los clústeres regionales, aprovisiona la instancia en una de las zonas de la región.

En el siguiente ejemplo, se muestra cómo crear una StorageClass personalizada con requisitos de topología específicos:

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

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: lustre-class
provisioner: lustre.csi.storage.gke.io
volumeBindingMode: Immediate
reclaimPolicy: Delete
parameters:
  perUnitStorageThroughput: "1000"
  network: LUSTRE_NETWORK
allowedTopologies:
- matchLabelExpressions:
  - key: topology.gke.io/zone
    values:
    - us-central1-a

Para obtener la lista completa de los campos admitidos en StorageClass, consulta la documentación de referencia del controlador de CSI de Lustre administrado.

Para crear una StorageClass, ejecuta este comando:
```
kubectl apply -f lustre-class.yaml
```

Usa un objeto PersistentVolumeClaim para acceder al volumen

En esta sección, se muestra cómo crear un recurso de PersistentVolumeClaim que haga referencia a la StorageClass del controlador de CSI de Lustre administrado.

Guarda el siguiente manifiesto como un archivo llamado lustre-pvc.yaml:
```
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: lustre-pvc
spec:
  accessModes:
  - ReadWriteMany
  resources:
    requests:
      storage: 18000Gi
  storageClassName: lustre-class
```
Para obtener la lista completa de los campos admitidos en PersistentVolumeClaim, consulta la documentación de referencia del controlador de CSI de Lustre administrado.
Ejecuta el siguiente comando para crear la PersistentVolumeClaim:
```
kubectl apply -f lustre-pvc.yaml
```

Crea una carga de trabajo para consumir el volumen

En esta sección, se muestra un ejemplo de 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

Aplica el manifiesto al clúster.
```
kubectl apply -f my-pod.yaml
```
Verificar que el pod se esté ejecutando. El Pod se ejecuta después de que se aprovisiona la PersistentVolumeClaim. Esta operación puede tardar unos minutos en completarse.
```
kubectl get pods
```
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 montado para que coincida con un fsGroup solicitado por el usuario y especificado en el SecurityContext del Pod. fsGroup no cambiará de forma recursiva la propiedad de todo el sistema de archivos Lustre administrado montado; solo se verá afectado el directorio raíz del punto de montaje.

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.

Limpia

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: Si creas el PersistentVolume con un persistentVolumeReclaimPolicy "Delete", borrar el PersistentVolumeClaim también borrará el PersistentVolume y la instancia de Managed Lustre subyacente.
```
kubectl delete pod my-pod
kubectl delete pvc lustre-pvc
```
Verifica el estado de PersistentVolume.
```
kubectl get pv
```
El resultado es similar a este:
```
No resources found
```
Es posible que la instancia subyacente de Lustre administrado tarde unos minutos en borrarse por completo.

¿Qué sigue?

Explora la documentación de Managed Lustre.