Cette page a été traduite par l'API Cloud Translation.

Accéder aux instances Managed Lustre sur GKE avec le pilote CSI Managed Lustre

Autopilot Standard

Ce guide explique comment créer un volume Kubernetes reposant sur le pilote CSI Managed Lustre dans GKE avec le provisionnement dynamique. Le pilote CSI Managed Lustre vous permet de créer du stockage à la demande avec des instances Managed Lustre et d'y accéder en tant que volumes pour vos charges de travail avec état.

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é gcloud CLI, assurez-vous de disposer de la dernière version en exécutant la commande gcloud components update.
Remarque : Pour les installations de gcloud CLI existantes, veillez à définir la propriété compute/region. Si vous utilisez principalement des clusters zonaux, définissez plutôt compute/zone. En définissant un emplacement par défaut, vous pouvez éviter les erreurs gcloud CLI telles que celle-ci : One of [--zone, --region] must be supplied: Please specify location. Vous devrez peut-être spécifier l'emplacement dans certaines commandes si l'emplacement de votre cluster diffère de celui par défaut que vous avez défini.

Pour connaître les limites et les conditions requises, consultez la présentation du pilote CSI.
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 IP_RANGE_NAME=LUSTRE_IP_RANGE
export FIREWALL_RULE_NAME=LUSTRE_FIREWALL_RULE
export LOCATION=ZONE

Remplacez les éléments suivants :

CLUSTER_NAME : nom du cluster.
PROJECT_ID : ID de votre projet Trusted Cloud by S3NS .
LUSTRE_NETWORK : réseau de cloud privé virtuel (VPC) partagé dans lequel résident le cluster GKE et l'instance Lustre gérée.
LUSTRE_IP_RANGE : nom de la plage d'adresses IP créée pour le peering de réseau VPC avec Managed Lustre.
LUSTRE_FIREWALL_RULE : nom de la règle de pare-feu permettant le trafic TCP à partir de la plage d'adresses IP.
ZONE : zone géographique de votre cluster GKE (par exemple, us-central1-a).

Configurer un réseau VPC

Vous devez spécifier le même réseau VPC lorsque vous créez l'instance Managed Lustre et vos clusters GKE.

Pour activer la mise en réseau des services, exécutez la commande suivante :

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

Créez un réseau VPC. Définir l'indicateur --mtu sur 8896 permet d'améliorer les performances de 10 %.

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

Créez une plage d'adresses 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}

Obtenez la plage CIDR associée à la plage que vous avez créée à l'étape précédente.

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

Créez une règle de pare-feu pour autoriser le trafic TCP provenant de la plage d'adresses IP que vous avez créée.

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

Pour configurer l'appairage de réseau pour votre projet, vérifiez que vous disposez des autorisations IAM nécessaires, en particulier du rôle compute.networkAdmin ou servicenetworking.networksAdmin.
1. Accédez à la console Trusted Cloud > IAM et administration, puis recherchez le principal du propriétaire de votre projet.
2. Cliquez sur l'icône en forme de crayon, puis sur + AJOUTER UN AUTRE RÔLE.
3. Sélectionnez Administrateur de réseaux Compute ou Administrateur de Service Networking.
4. Cliquez sur Enregistrer.

Connectez le peering.

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

Configurer le pilote CSI Lustre géré

Cette section explique comment activer et désactiver le pilote CSI Managed Lustre, si nécessaire.

Activer le pilote CSI Lustre géré sur un nouveau cluster GKE

Pour activer le pilote CSI Lustre géré lorsque vous créez un cluster GKE, procédez comme suit :

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

Standard

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

Lorsque l'indicateur enable-legacy-lustre-port est spécifié, le pilote CSI configure LNet (la couche de réseau virtuel pour le module de noyau Lustre géré) pour utiliser le port 6988. Cet indicateur est nécessaire pour contourner un conflit de port avec gke-metadata-server sur les nœuds GKE.

Activer le pilote CSI Lustre géré sur un cluster GKE existant

Pour activer le pilote CSI Managed Lustre sur un cluster GKE existant, utilisez la commande suivante :

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

L'activation du pilote CSI Managed Lustre 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 d'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 statique de GKE, vous devez mettre à niveau manuellement vos pools de nœuds.

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 consoleTrusted Cloud ou de la CLI. Exemple :

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

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 Lustre gérés. L'utilisation du GPU ne vous sera pas facturée.

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.

Créer un volume à l'aide du pilote CSI Lustre géré

Les sections suivantes décrivent la procédure de création standard d'un volume Kubernetes reposant sur une instance Managed Lustre dans GKE :

Créez une StorageClass.
Utiliser un objet PersistentVolumeClaim pour accéder au volume
Créer une charge de travail qui utilise le volume.

Créer un objet StorageClass

Lorsque le pilote CSI Managed Lustre est activé, GKE crée automatiquement un objet StorageClass pour le provisionnement d'instances Managed Lustre. La StorageClass dépend du niveau de performances Managed Lustre. GKE, et correspond à l'un des éléments suivants :

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

GKE fournit une StorageClass par défaut pour chaque niveau de performances Managed Lustre compatible. Cela simplifie le provisionnement dynamique des instances Managed Lustre, car vous pouvez utiliser les StorageClasses intégrées sans avoir à définir les vôtres.

Pour les clusters zonaux, le pilote CSI provisionne des instances Managed Lustre dans la même zone que le cluster. Pour les clusters régionaux, il provisionne l'instance dans l'une des zones de la région.

L'exemple suivant montre comment créer une StorageClass personnalisée avec des exigences de topologie spécifiques :

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

Pour obtenir la liste complète des champs compatibles avec StorageClass, consultez la documentation de référence sur le pilote CSI Lustre géré.

Créez l'objet StorageClass en exécutant la commande suivante :
```
kubectl apply -f lustre-class.yaml
```

Utiliser un objet PersistentVolumeClaim pour accéder au volume

Cette section explique comment créer une ressource PersistentVolumeClaim qui fait référence à la StorageClass du pilote CSI Managed Lustre.

Enregistrez le fichier manifeste suivant dans un fichier nommé lustre-pvc.yaml :
```
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: lustre-pvc
spec:
  accessModes:
  - ReadWriteMany
  resources:
    requests:
      storage: 18000Gi
  storageClassName: lustre-class
```
Pour obtenir la liste complète des champs compatibles avec PersistentVolumeClaim, consultez la documentation de référence sur le pilote CSI Lustre géré.
Créez la PersistentVolumeClaim en exécutant la commande suivante :
```
kubectl apply -f lustre-pvc.yaml
```

Créer une charge de travail pour utiliser le volume

Cette section présente un exemple de création d'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-pvc

Appliquez le fichier manifeste au cluster.
```
kubectl apply -f my-pod.yaml
```
Vérifier que le pod est en cours d'exécution. Le pod s'exécute une fois que le PersistentVolumeClaim est provisionné. Cette opération peut durer quelques minutes.
```
kubectl get pods
```
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. fsGroup ne modifie pas de manière récursive la propriété de l'ensemble du système de fichiers Managed Lustre installé. Seul le répertoire racine du point de montage est concerné.

Dépannage

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

Effectuer un nettoyage

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

Supprimez le pod et l'objet PersistentVolumeClaim.

Remarque : Si vous créez le PersistentVolume avec une persistentVolumeReclaimPolicy "Delete", la suppression du PersistentVolumeClaim entraîne également la suppression du PersistentVolume et de l'instance Managed Lustre sous-jacente.
```
kubectl delete pod my-pod
kubectl delete pvc lustre-pvc
```
Vérifiez l'état de PersistentVolume.
```
kubectl get pv
```
Le résultat ressemble à ce qui suit :
```
No resources found
```
La suppression complète de l'instance Managed Lustre sous-jacente peut prendre quelques minutes.

Étapes suivantes

Consultez la documentation Managed Lustre.