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 Lustre géré est activé par défaut pour utiliser toutes les cartes d'interface réseau (NIC) disponibles afin d'augmenter le débit. Cette fonctionnalité regroupe la bande passante en répartissant le trafic de stockage TCP sur vos interfaces réseau.
Pour utiliser la prise en charge multi-NIC, vos nœuds doivent répondre aux exigences suivantes :
- Cartes d'interface réseau standards pour TCP : vos nœuds doivent utiliser des cartes d'interface réseau standards, telles que Google Virtual NIC (gVNIC) ou VirtIO-Net, pour gérer le trafic de stockage TCP.
- Même VPC : toutes les cartes d'interface réseau standards doivent résider dans le même réseau VPC.
- Considérations concernant RDMA : vos nœuds peuvent également être associés à des cartes d'interface réseau RDMA. Toutefois, le pilote CSI Managed Lustre n'utilise que les cartes d'interface réseau standards pour le trafic de stockage TCP.
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 Managed Lustre GKE 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.4780000ou ultérieure, le pilote utilise le port988pour la communication Lustre par défaut.Ancien port : utilisez le port
6988en ajoutant l'indicateur--enable-legacy-lustre-portà vos commandesgclouddans les scénarios suivants :- Versions antérieures de GKE : si votre cluster GKE exécute une version antérieure à
1.33.2-gke.4780000, l'indicateur--enable-legacy-lustre-portpermet de contourner un conflit de port avecgke-metadata-serversur les nœuds GKE. - Instances Lustre existantes : si vous vous connectez à une instance Managed Lustre existante qui a été créée avec l'indicateur
gke-support-enabled, vous devez toujours inclure--enable-legacy-lustre-portdans vos commandesgcloud, quelle que soit la version de votre cluster. Sans cet indicateur, votre cluster GKE ne pourra pas monter l'instance Lustre existante. Pour en savoir plus sur l'indicateurgke-support-enabled, consultez la description des indicateurs facultatifs dans Créer une instance.
- Versions antérieures de GKE : si votre cluster GKE exécute une version antérieure à
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 gcloud CLI. Si vous avez déjà installé la gcloud CLI, obtenez la dernière version en exécutant la commande
gcloud components update. Il est possible que les versions antérieures de la gcloud CLI ne permettent pas d'exécuter les commandes de ce document.
- Pour connaître les limites et les exigences, consultez À propos du pilote CSI Google Cloud Managed Lustre.
- Assurez-vous d'activer le pilote CSI Lustre géré. Il est désactivé par défaut dans les clusters Standard et Autopilot.
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 :
CLUSTER_NAME: nom du cluster.PROJECT_ID: ID de votre projet Google Cloud .LUSTRE_NETWORK: réseau cloud privé virtuel partagé dans lequel résident le cluster GKE et l'instance Managed Lustre.ZONE: zone géographique de votre cluster GKE (par exemple,us-central1-a).
Configurer le pilote CSI Lustre géré
Cette section explique comment activer et désactiver le pilote CSI Lustre géré.
Activer le pilote CSI Lustre géré sur un nouveau cluster GKE
Les sections suivantes décrivent comment activer le pilote CSI Lustre géré sur un nouveau cluster GKE.
Utiliser le port par défaut 988
Pour activer le pilote CSI Lustre géré lorsque vous créez 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 Lustre géré lorsque vous créez 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 Lustre géré sur des clusters GKE existants
Les sections suivantes décrivent comment activer le pilote CSI Lustre géré 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 Lustre géré sur un cluster GKE existant, vous devrez peut-être utiliser l'ancien port 6988 en ajoutant l'indicateur --enable-legacy-lustre-port. Cette option est obligatoire dans les cas suivants :
- Si votre cluster GKE exécute une version antérieure à
1.33.2-gke.4780000. Si vous avez l'intention de connecter ce cluster à une instance Managed Lustre existante qui a été créée avec l'indicateur
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 selon leur déploiement planifié, ce qui peut prendre plusieurs semaines en fonction de votre période 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 d'erreur 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 signifie qu'une mise à niveau ou une recréation du nœud est requise.
Après la mise à niveau du pool de nœuds, il est possible que les nœuds CPU semblent utiliser une image GPU dans la sortie de la console Google Cloud ou 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 du noyau Managed Lustre. L'utilisation du GPU ne vous sera pas facturée.
(Facultatif) Créer un pool de nœuds à plusieurs cartes d'interface réseau
Pour utiliser la mise en 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 prise en charge de 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 clusterLOCATION: région ou zone de votre cluster.MACHINE_TYPE: type de machine pour le pool de nœuds, tel quea3-megagpu-8g, souvent utilisé avec plusieurs cartes d'interface réseau pour les hautes performances. Les cartes d'interface réseau multiples sont compatibles avec tous les types de machines.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 prise en charge de plusieurs cartes réseau soit recommandée pour les charges de travail hautes performances, vous pouvez la désactiver dans certains cas spécifiques. Par exemple, vous ne souhaitez peut-être 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 prise en charge de 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 soit prise en compte.
Pour un cluster
Pour désactiver la mise en réseau à hautes performances pour l'ensemble du cluster, utilisez l'option --disable-multi-nic-lustre lorsque vous créez ou mettez à jour le cluster. Exemple :
gcloud container clusters update CLUSTER_NAME \
--location=LOCATION \
--disable-multi-nic-lustre
Remplacez les éléments suivants :
CLUSTER_NAME: nom du clusterLOCATION: région ou zone de votre cluster.
Pour un pool de nœuds
Pour désactiver la mise en 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 clusterLOCATION: zone de votre cluster.
Désactiver le pilote CSI Lustre géré
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 Lustre gérés.
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 :
- Créer un PersistentVolume qui fait référence à l'instance Managed Lustre
- Utiliser un objet PersistentVolumeClaim pour accéder au volume
- Créer une charge de travail qui utilise le volume.
Créer un volume persistant
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 Nom de l'instance Managed Lustre, système de fichiers et point de montage.
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'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: FILESYSTEMRemplacez 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 projet Google Cloud .
- LOCATION : emplacement zonal de votre instance Lustre. Vous devez spécifier une zone compatible pour le pilote CSI Lustre géré.
- INSTANCE_NAME : nom de votre instance Lustre.
ip: adresse IP de votre instance Lustre. Vous l'obtiendrez à partir du champmountPointdans 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 Lustre géré.
Créez le PersistentVolume en exécutant la commande suivante :
kubectl apply -f lustre-pv.yaml
Utiliser l'objet PersistentVolumeClaim pour accéder au volume
Vous pouvez créer une ressource 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 mode d'accès ReadWriteMany qui référence la StorageClass que vous avez créée précédemment.
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_SIZERemplacez STORAGE_SIZE par la taille de stockage, par exemple
9000Gi. Il doit correspondre à la spécification de votre PersistentVolume.Créez la PersistentVolumeClaim en exécutant la commande suivante :
kubectl create -f lustre-pvc.yaml
Créer un pod 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.
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-pvcExécutez la commande suivante pour appliquer le fichier manifeste au cluster :
kubectl apply -f my-pod.yamlLe pod attend que GKE provisionne le PersistentVolumeClaim avant de commencer à s'exécuter. Cette opération peut prendre plusieurs minutes.
Vérifiez qu'il est en cours d'exécution :
kubectl get podsIl peut s'écouler quelques minutes avant que le pod n'atteigne 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 compte Google Cloud , supprimez les ressources de stockage que vous avez créées dans ce guide.
Supprimez le pod et l'objet PersistentVolumeClaim.
kubectl delete pod my-pod kubectl delete pvc lustre-pvcVérifiez l'état de PersistentVolume. Après avoir supprimé le pod et la PersistentVolumeClaim, le PersistentVolume devrait afficher l'état "Released" (Libéré) :
kubectl get pvLe 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 2m28sRé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 devrait maintenant afficher 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 pvLe résultat ressemble à ce qui suit :
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE lustre-pv 9000Gi RWX Retain Available 19mSupprimez le PersistentVolume s'il n'est plus nécessaire. Si le PersistentVolume n'est plus nécessaire, supprimez-le :
kubectl delete pv lustre-pvLa suppression du PersistentVolume n'entraîne pas la suppression de l'instance Managed Lustre sous-jacente.