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

En esta guía, se describe cómo puedes crear un nuevo volumen de Kubernetes respaldado por el controlador de CSI de Managed Lustre en GKE con aprovisionamientodinámico. El controlador de 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.

Compatibilidad con varias NIC para redes de alto rendimiento

En el caso de los clústeres de GKE que ejecutan la versión 1.35.2-gke.1842000 o versiones posteriores, el controlador de CSI de Managed Lustre está habilitado de forma predeterminada para usar todas las tarjetas de interfaz de red (NIC) disponibles para aumentar la capacidad de procesamiento. Esta compatibilidad agrega ancho de banda mediante la propagación del tráfico de almacenamiento de TCP en 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 de 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 para GKE usa diferentes puertos para la comunicación con instancias de Managed Lustre, según la versión del clúster de GKE y las configuraciones existentes de Managed Lustre.

  • Puerto predeterminado (recomendado): Para los clústeres de GKE nuevos que ejecutan la versión 1.33.2-gke.4780000 o versiones posteriores, 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 1.33.2-gke.4780000, la marca --enable-legacy-lustre-port soluciona un conflicto de puertos con 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.
    • Habilitar las APIs
  • Si deseas usar Google Cloud CLI para esta tarea, instala y, luego, inicializa the 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 IP_RANGE_NAME=LUSTRE_IP_RANGE
export FIREWALL_RULE_NAME=LUSTRE_FIREWALL_RULE
export LOCATION=ZONE
export CLUSTER_VERSION=CLUSTER_VERSION

Reemplaza lo siguiente:

  • CLUSTER_NAME: el nombre del clúster
  • PROJECT_ID: tu Google Cloud ID del proyecto.
  • LUSTRE_NETWORK: la red de nube privada virtual (VPC) compartida en la que residen el clúster de GKE y la instancia de Managed Lustre
  • LUSTRE_IP_RANGE: el nombre del rango de direcciones IP creado para el intercambio de tráfico entre redes de VPC con Managed Lustre
  • LUSTRE_FIREWALL_RULE: el nombre de la regla de firewall para permitir el tráfico de TCP desde el rango de direcciones IP
  • ZONE: la zona geográfica de tu clúster de GKE; por ejemplo, us-central1-a
  • CLUSTER_VERSION: la versión del clúster de GKE

Configura una red de VPC

Debes especificar la misma red de VPC cuando crees la instancia de Managed Lustre y tus clústeres de GKE, o conectarte a través de Network Connectivity Center si usas una red de VPC con intercambio de tráfico.

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

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

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

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

  3. 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}

  4. Obtén el rango de CIDR asociado con el 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}
)

  5. 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}

  6. Para configurar el intercambio de tráfico entre redes para tu proyecto, verifica que tengas los permisos de IAM necesarios, específicamente el rol compute.networkAdmin o servicenetworking.networksAdmin.

    1. Ve a la Google Cloud consola > IAM y administración y, luego, busca la entidad principal propietaria del proyecto.
    2. Haz clic en el ícono de lápiz y, luego, en + AGREGAR OTRO ROL.
    3. Selecciona Administrador de redes de Compute o Administrador de redes de servicio.
    4. Haz clic en Guardar.

  7. 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 de CSI de Managed Lustre

En esta sección, se explica cómo habilitar y 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 versiones posteriores, 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 crees un clúster de GKE nuevo que ejecute una versión anterior a 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 versiones posteriores, 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 1.33.2-gke.4780000.

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

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

Se requiere la actualización de nodos en 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 del kernel necesarios para el cliente de Managed Lustre. Para obtener disponibilidad inmediata, te recomendamos que actualices los grupos de nodos de forma manual.

Los clústeres de GKE en un canal de lanzamiento se actualizan según su implementación programada, que puede tardar varias semanas según tu ventana de mantenimiento. Si usas una versión estática de GKE, debes actualizar los grupos de nodos de forma manual.

Hasta que se complete la actualización del nodo, es posible que el pod del controlador de CSI entre en un bucle de fallas 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 Google Cloud consola 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 del 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 varias interfaces de red. La compatibilidad con varias NIC está habilitada de forma predeterminada en los clústeres de GKE que ejecutan la versión 1.35.2-gke.1842000 o versiones posteriores. Asegúrate de que tus interfaces de red secundarias residan en la misma red de VPC que tu interfaz principal.

Ejecuta el siguiente comando:

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: la región o la zona de tu clúster
  • MACHINE_TYPE: el tipo de máquina para el grupo de nodos, como a3-megagpu-8g, que se usa con frecuencia con varias NIC para un alto rendimiento Se admiten varias NIC en cualquier tipo de máquina.
  • NETWORK_NAME: el nombre de la red de VPC
  • SECONDARY_SUBNET: el nombre de la subred secundaria

Inhabilita varias NIC en Lustre

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

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

Para un clúster

Para inhabilitar las redes de alto rendimiento para 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: la región o la zona de tu clúster

Para un grupo de nodos

Para inhabilitar las redes de alto rendimiento para 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: 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 automáticamente tus nodos y desinstala los módulos del kernel de Managed Lustre.

Crea un volumen nuevo con el controlador de CSI de Managed Lustre

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

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

Crea un StorageClass

Cuando se habilita el controlador de CSI de Managed Lustre, GKE crea automáticamente un StorageClass para aprovisionar instancias de Managed Lustre. El StorageClass depende del nivel de rendimiento de Managed Lustre , y es uno de los siguientes:

  • 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 Managed Lustre compatible. Esto simplifica el aprovisionamiento dinámico de instancias de Managed Lustre, ya que puedes usar los StorageClasses integrados sin tener que definir los tuyos.

Para los clústeres zonales, el controlador de CSI aprovisiona instancias de Managed Lustre en la misma zona que el clúster. Para 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 un StorageClass personalizado con requisitos de topología específicos:

  1. 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 Managed Lustre.

  2. 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 hace referencia a la StorageClass del controlador de CSI de Managed Lustre.

  1. 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: 9000Gi
  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 Managed Lustre.

  2. 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.

  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. Aplica el manifiesto al clúster.

    kubectl apply -f my-pod.yaml

  3. Verificar que el pod se esté ejecutando. El Pod se ejecuta después de que se aprovisiona 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 activado para que coincida con un fsGroup solicitado por el usuario especificado en el SecurityContext del Pod. fsGroup no cambiará de forma recursiva la propiedad de todo el sistema de archivos de Managed Lustre activado; solo se verá afectado el directorio raíz del punto de activación.

Soluciona problemas

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

Limpia

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

  1. Borra el Pod y PersistentVolumeClaim.

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

  2. Verifica el estado de PersistentVolume.

    kubectl get pv

    El resultado es similar a este:

    No resources found

    Es posible que la instancia subyacente de Managed Lustre tarde unos minutos en borrarse por completo.

¿Qué sigue?