Accéder à des instances Managed Lustre existantes sur GKE à l'aide du pilote CSI Managed Lustre

Ce guide explique comment vous connecter à une instance Managed Lustre existante à l'aide du pilote CSI Managed Lustre. Vous pouvez ainsi accéder aux instances Managed Lustre existantes en tant que volumes pour vos charges de travail avec état, de manière contrôlée et prévisible.

Compatibilité avec plusieurs cartes d'interface réseau pour les réseaux à hautes performances

Pour les clusters GKE exécutant la version 1.35.2-gke.1842000 ou ultérieure, le pilote CSI Managed Lustre est activé par défaut pour utiliser toutes les cartes d'interface réseau disponibles afin d'augmenter le débit. Cette compatibilité agrège la bande passante en répartissant le trafic de stockage TCP sur vos interfaces réseau.

Pour utiliser la compatibilité avec plusieurs cartes d'interface réseau, vos nœuds doivent répondre aux exigences suivantes :

Si vous souhaitez désactiver la compatibilité avec plusieurs cartes d'interface réseau, consultez Désactiver plusieurs cartes d'interface réseau pour Lustre.

Ports de communication Lustre

Le pilote CSI GKE Managed Lustre utilise différents ports pour communiquer avec les instances Managed Lustre, en fonction de la version de votre cluster GKE et des configurations Managed Lustre existantes.

  • Port par défaut (recommandé) : pour les nouveaux clusters GKE exécutant la version 1.33.2-gke.4780000 ou ultérieure, le pilote utilise par défaut le port 988 pour la communication Lustre.

  • Ancien port (obsolète) : utilisez le port 6988 en ajoutant l'option --enable-legacy-lustre-port à vos commandes gcloud dans les scénarios suivants :

    • Versions GKE antérieures : si votre cluster GKE exécute une version antérieure à 1.33.2-gke.4780000, l'option --enable-legacy-lustre-port contourne un conflit de port avec gke-metadata-server sur les nœuds GKE.
    • Instances Lustre existantes : si vous vous connectez à une instance Managed Lustre existante qui a été créée avec l'option gke-support-enabled, vous devez toujours inclure --enable-legacy-lustre-port dans vos commandes gcloud, quelle que soit la version de votre cluster. Sans cette option, votre cluster GKE ne pourra pas installer l'instance Lustre existante.

Vous pouvez configurer les clusters nouveaux et existants pour qu'ils utilisent le port par défaut 988 ou l'ancien port 6988.

Avant de commencer

Avant de commencer, effectuez les tâches suivantes :

  • Activez l'API Google Cloud Managed Lustre et l'API Google Kubernetes Engine.
    • Activer les API
  • Si vous souhaitez utiliser Google Cloud CLI pour cette tâche, installez puis initialisez la gcloud CLI. Si vous avez déjà installé la gcloud CLI, obtenez la dernière version en exécutant la gcloud components update commande. Il est possible que les versions antérieures de la gcloud CLI ne permettent pas d'exécuter les commandes de ce document.

Configurer des variables d'environnement

Configurez les variables d'environnement suivantes :

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

Remplacez les éléments suivants :

Configurer le pilote CSI Managed Lustre

Cette section explique comment activer et désactiver le pilote CSI Managed Lustre.

Activer le pilote CSI Managed Lustre sur un nouveau cluster GKE

Les sections suivantes décrivent comment activer le pilote CSI Managed Lustre sur un nouveau cluster GKE.

Utiliser le port par défaut 988

Pour activer le pilote CSI Managed Lustre lors de la création d'un cluster GKE exécutant la version 1.33.2-gke.4780000 ou ultérieure, exécutez la commande suivante :

Autopilot

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

Standard

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

Utiliser l'ancien port 6988

Pour activer le pilote CSI Managed Lustre lors de la création d'un cluster GKE exécutant une version antérieure à 1.33.2-gke.4780000, exécutez la commande suivante :

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

Standard

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

Activer le pilote CSI Managed Lustre sur des clusters GKE existants

Les sections suivantes décrivent comment activer le pilote CSI Managed Lustre sur des clusters GKE existants.

Utiliser le port par défaut 988

Pour activer le pilote CSI Managed Lustre sur un cluster GKE existant exécutant la version 1.33.2-gke.4780000 ou ultérieure, exécutez la commande suivante :

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

Utiliser l'ancien port 6988

Pour activer le pilote CSI Managed Lustre sur un cluster GKE existant, vous devrez peut-être utiliser l'ancien port 6988 en ajoutant l'option --enable-legacy-lustre-port. Cette option est requise dans les scénarios suivants :

  • Si votre cluster GKE exécute une version antérieure à 1.33.2-gke.4780000.

  • Si vous prévoyez de connecter ce cluster à une instance Managed Lustre existante qui a été créée avec l'option gke-support-enabled.

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

Mise à niveau des nœuds requise sur les clusters existants

L'activation du pilote CSI Managed Lustre sur des clusters existants peut déclencher la recréation de nœuds afin de mettre à jour les modules de noyau nécessaires pour le client Managed Lustre. Pour une disponibilité immédiate, nous vous recommandons de mettre à niveau manuellement vos pools de nœuds.

Les clusters GKE sur un version disponible sont mis à niveau en fonction de leur déploiement planifié, ce qui peut prendre plusieurs semaines en fonction de votre fenêtre de maintenance. Si vous utilisez une version GKE statique, vous devez mettre à niveau manuellement vos pools de nœuds.

Tant que la mise à niveau des nœuds n'est pas terminée, le pod du pilote CSI peut être en boucle de plantage sur les nœuds en attente de mise à jour. Si une erreur Operation not permitted s'affiche dans les journaux du pod du pilote CSI, cela indique qu'une mise à niveau ou une recréation des nœuds est requise.

Après la mise à niveau du pool de nœuds, les nœuds de processeur peuvent sembler utiliser une image GPU dans la Cloud de Confiance console ou la sortie de la CLI. Ce comportement est normal. L'image GPU est réutilisée sur les nœuds de processeur pour installer de manière sécurisée les modules de noyau Managed Lustre. L'utilisation du GPU ne vous sera pas facturée.

(Facultatif) Créer un pool de nœuds avec plusieurs cartes d'interface réseau

Pour utiliser un réseau à hautes performances, vous devez créer un pool de nœuds avec un type d'instance compatible avec plusieurs interfaces réseau. La compatibilité avec plusieurs cartes d'interface réseau est activée par défaut sur les clusters GKE exécutant la version 1.35.2-gke.1842000 ou ultérieure. Assurez-vous que vos interfaces réseau secondaires résident dans le même réseau VPC que votre interface principale.

Exécutez la commande suivante :

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

Remplacez les éléments suivants :

  • NODE_POOL_NAME : nom de votre pool de nœuds.
  • CLUSTER_NAME : nom du cluster.
  • LOCATION : région ou zone de votre cluster.
  • MACHINE_TYPE : type de machine pour le pool de nœuds, tel que a3-megagpu-8g, souvent utilisé avec plusieurs cartes d'interface réseau pour des performances élevées. Plusieurs cartes d'interface réseau sont compatibles avec n'importe quel type de machine.
  • NETWORK_NAME : nom du réseau VPC.
  • SECONDARY_SUBNET : nom du sous-réseau secondaire.

Désactiver plusieurs cartes d'interface réseau sur Lustre

Bien que la compatibilité avec plusieurs cartes d'interface réseau soit recommandée pour les charges de travail à hautes performances, vous pouvez la désactiver dans des scénarios spécifiques. Par exemple, vous pouvez choisir de ne pas répartir le trafic Lustre sur toutes les interfaces matérielles disponibles ou vous devrez peut-être isoler les problèmes de connectivité sur un seul chemin réseau pour le dépannage.

Remarque : Si vous désactivez la compatibilité avec plusieurs cartes d'interface réseau sur les nœuds en cours d'exécution, vous devrez peut-être recréer ou mettre à niveau manuellement vos pools de nœuds pour que cette modification prenne effet.

Pour un cluster

Pour désactiver le réseau à hautes performances pour l'ensemble du cluster, utilisez l'option --disable-multi-nic-lustre lors de la création ou de la mise à jour du cluster. Exemple :

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

Remplacez les éléments suivants :

  • CLUSTER_NAME : nom du cluster.
  • LOCATION : région ou zone de votre cluster.

Pour un pool de nœuds

Pour désactiver le réseau à hautes performances pour un pool de nœuds spécifique, mettez à jour le pool de nœuds afin de définir le libellé lustre.csi.storage.gke.io/multi-nic sur false :

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

Remplacez les éléments suivants :

  • NODE_POOL_NAME : nom de votre pool de nœuds.
  • CLUSTER_NAME : nom du cluster.
  • LOCATION : zone de votre cluster.

Désactiver le pilote CSI Managed Lustre

Vous pouvez désactiver le pilote CSI Managed Lustre sur un cluster GKE existant à l'aide de Google Cloud CLI.

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

Une fois le pilote CSI désactivé, GKE recrée automatiquement vos nœuds et désinstalle les modules de noyau Managed Lustre.

Accéder à une instance Managed Lustre existante à l'aide du pilote CSI Managed Lustre

Si vous avez déjà provisionné une instance Managed Lustre sur le même réseau que votre cluster GKE, vous pouvez suivre ces instructions pour provisionner de manière statique un PersistentVolume qui fait référence à votre instance.

Les sections suivantes décrivent la procédure standard d'accès à une instance Managed Lustre existante à l'aide du pilote CSI Managed Lustre :

  1. Créez un PersistentVolume qui fait référence à l'instance Managed Lustre.
  2. Utilisez un objet PersistentVolumeClaim pour accéder au volume.
  3. Créez une charge de travail qui utilise le volume.

Créer un volume persistant

  1. Pour localiser votre instance Managed Lustre, exécutez la commande suivante.

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

    Le résultat doit ressembler à ce qui suit. Avant de passer à l’étape suivante, veillez à noter les champs Managed Lustre instance name (Nom de l’instance Managed Lustre), filesystem (Système de fichiers) et mountPoint (Point d’installation).

    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. Enregistrez le fichier manifeste suivant dans un fichier nommé 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

    Remplacez les éléments suivants :

    • storageClassName : nom de votre StorageClass. La valeur peut être une chaîne vide, mais elle doit correspondre à la spécification de votre PersistentVolumeClaim.
    • volumeHandle : identifiant de ce volume.
      • PROJECT_ID : ID du Cloud de Confiance by S3NS projet.
      • LOCATION : emplacement zonal de votre instance Lustre. Vous devez spécifier une zone compatible pour le pilote CSI Managed Lustre.
      • INSTANCE_NAME : nom de votre instance Lustre.
    • ip: adresse IP de votre instance Lustre. Vous l'obtenez à partir du champ mountPoint dans la sortie de la commande précédente.
    • filesystem : nom du système de fichiers de votre instance Managed Lustre.

    Pour obtenir la liste complète des champs compatibles dans l'objet PersistentVolume, consultez la documentation de référence sur le pilote CSI Managed Lustre.

  3. Créez le PersistentVolume en exécutant la commande suivante :

    kubectl apply -f lustre-pv.yaml

Utiliser le PersistentVolumeClaim pour accéder au volume

Vous pouvez créer une PersistentVolumeClaim qui référence la StorageClass du pilote CSI Managed Lustre.

Le fichier manifeste suivant montre un exemple de création d'un PersistentVolumeClaim en ReadWriteMany mode d'accès , qui référence la StorageClass que vous avez créée précédemment.

  1. Enregistrez le fichier manifeste suivant dans un fichier nommé 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

    Remplacez STORAGE_SIZE par la taille de stockage, par exemple 9000Gi. Il doit correspondre à la spécification de votre PersistentVolume.

  2. Créez la PersistentVolumeClaim en exécutant la commande suivante :

    kubectl create -f lustre-pvc.yaml

Créer une charge de travail qui utilise le volume

Cette section explique comment créer un pod qui utilise la ressource PersistentVolumeClaim que vous avez créée précédemment.

Plusieurs pods peuvent partager la même ressource PersistentVolumeClaim.

  1. Enregistrez le fichier manifeste suivant dans un fichier nommé 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. Exécutez la commande suivante pour appliquer le fichier manifeste au cluster :

    kubectl apply -f my-pod.yaml

    Le pod attend que GKE provisionne le PersistentVolumeClaim avant de commencer à s'exécuter. Cette opération peut prendre plusieurs minutes

  3. Vérifiez qu'il est en cours d'exécution :

    kubectl get pods

    Le pod peut mettre quelques minutes à atteindre l'état Running.

    Le résultat ressemble à ce qui suit :

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

Utiliser fsGroup avec des volumes Managed Lustre

Vous pouvez modifier la propriété de groupe du répertoire racine du système de fichiers installé pour qu'il corresponde à un fsGroup demandé par l'utilisateur et spécifié dans le SecurityContext du pod.

Dépannage

Pour obtenir des conseils de dépannage, consultez la page Dépannage de la documentation Managed Lustre.

Effectuer un nettoyage

Pour éviter que des frais ne soient facturés sur votre Cloud de Confiance by S3NS compte, supprimez les ressources de stockage que vous avez créées dans ce guide.

  1. Supprimez le pod et le PersistentVolumeClaim.

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

  2. Vérifiez l'état du PersistentVolume. Après avoir supprimé le pod et le PersistentVolumeClaim, le PersistentVolume doit indiquer l'état "Released" (Libéré) :

    kubectl get pv

    Le résultat ressemble à ce qui suit :

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

  3. Réutilisez le PersistentVolume. Pour réutiliser le PersistentVolume, supprimez la référence de revendication (claimRef) :

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

    Le PersistentVolume doit maintenant indiquer l'état "Available" (Disponible), ce qui indique qu'il est prêt à être lié à un nouveau PersistentVolumeClaim. Vérifiez l'état du PersistentVolume :

    kubectl get pv

    Le résultat ressemble à ce qui suit :

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

  4. Supprimez le PersistentVolume s'il n'est plus nécessaire. Si le PersistentVolume n'est plus nécessaire, supprimez-le :

    kubectl delete pv lustre-pv

    La suppression du PersistentVolume ne supprime pas l'instance Managed Lustre sous-jacente.

Étape suivante