Container Service for Kubernetes:Accelerate data access for Job applications

Charger des données de test dans OSS

1. Créez un fichier de test de 2 Go, tel que cet exemple de jeu de données.

2. Chargez le fichier dans votre compartiment OSS à l'aide de ossutil.

Créer les ressources Dataset et JindoRuntime

Cet exemple utilise JindoFS comme backend de cache (JindoRuntime). Fluid représente les sources de données sous forme de deux ressources personnalisées (CR) :

• Dataset — pointe vers les données dans le système de stockage externe.

• JindoRuntime — définit la configuration du système de mise en cache.

Fluid utilise le chargement différé : le premier accès récupère les données depuis OSS vers le cache local ; les lectures suivantes proviennent du cache. Pour éliminer la latence lors de la première exécution, préchauffez le cache avant de soumettre votre Job.

1. Créez un Secret pour stocker les identifiants OSS :

   kubectl create secret generic oss-access-key \
     --from-literal=fs.oss.accessKeyId=<access_key_id> \
     --from-literal=fs.oss.accessKeySecret=<access_key_secret>

2. Créez un fichier nommé dataset.yaml :

   Parameter	Description
   mountPoint	Chemin de montage OSS au format oss://<bucket_name>/<bucket_path>. Définissez path sur / pour un point de montage unique.
   fs.oss.endpoint	Endpoint du compartiment OSS. Utilisez un endpoint interne (par exemple, oss-cn-hangzhou-internal.aliyuncs.com) pour un accès dans la même région ; utilisez un endpoint public (par exemple, oss-cn-hangzhou.aliyuncs.com) dans le cas contraire.
   replicas	Nombre de pods de travail du cache. Détermine la capacité totale du cache.
   alibabacloud.com/burst-resource: eci_only	Désactive la planification des nœuds virtuels sur les pods de travail du cache. Obligatoire, car Fluid entre en conflit avec la planification des nœuds virtuels (voir la section Limites).
   k8s.aliyun.com/eci-use-specs	Spécification de l'instance ECI pour chaque pod de travail du cache.
   k8s.aliyun.com/eci-image-cache	Active le cache d'image d'instance pour accélérer le démarrage des pods.
   tieredstore.levels.mediumtype	Support de cache. Valeurs valides : MEM (mémoire), SSD, HDD. Consultez la rubrique Sélectionner un support de cache.
   tieredstore.levels.volumeType	Type de volume. Utilisez emptyDir pour la mémoire ou le disque système (évite que le cache résiduel n'affecte la disponibilité du nœud). Utilisez hostPath pour les disques de données et définissez path sur le point de montage. Par défaut : hostPath.
   tieredstore.levels.path	Chemin du cache. Un seul chemin est pris en charge.
   tieredstore.levels.quota	Capacité maximale du cache par travailleur, par exemple 10Gi.
   tieredstore.levels.high / low	Seuils haut et bas pour l'éviction du cache.

   apiVersion: data.fluid.io/v1alpha1
   kind: Dataset
   metadata:
     name: demo-dataset
   spec:
     mounts:
       - mountPoint: oss://<bucket_name>/<bucket_path>
         name: demo
         path: /
         options:
           fs.oss.endpoint: oss-<region>.aliyuncs.com
         encryptOptions:
           - name: fs.oss.accessKeyId
             valueFrom:
               secretKeyRef:
                 name: oss-access-key
                 key: fs.oss.accessKeyId
           - name: fs.oss.accessKeySecret
             valueFrom:
               secretKeyRef:
                 name: oss-access-key
                 key: fs.oss.accessKeySecret
   ---
   apiVersion: data.fluid.io/v1alpha1
   kind: JindoRuntime
   metadata:
     name: demo-dataset
   spec:
     # Number of cache worker nodes
     replicas: 2
     worker:
       podMetadata:
         annotations:
           # Required: disable virtual node scheduling (conflicts with Fluid — see Limitations)
           alibabacloud.com/burst-resource: eci_only
           # ECI instance spec for the JindoFS cache worker pod
           k8s.aliyun.com/eci-use-specs: <eci_instance_spec>
           # Enable instance image cache to speed up pod startup
           k8s.aliyun.com/eci-image-cache: "true"
     tieredstore:
       levels:
         # 10 GiB of memory cache per worker node
         - mediumtype: MEM
           volumeType: emptyDir
           path: /dev/shm
           quota: 10Gi
           high: "0.99"
           low: "0.99"

   Paramètres clés :

3. Appliquez le manifeste :

   kubectl create -f dataset.yaml

4. Attendez une à deux minutes que le système de mise en cache soit déployé, puis vérifiez l'état du Dataset :

   Si PHASE indique NotBound , le système de mise en cache est toujours en cours d'initialisation. Attendez une à deux minutes et vérifiez à nouveau.

   kubectl get dataset demo-dataset

   Sortie attendue :

   NAME           UFS TOTAL SIZE   CACHED   CACHE CAPACITY   CACHED PERCENTAGE   PHASE   AGE
   demo-dataset   1.16GiB          0.00B    20.00GiB         0.0%                Bound   2m58s

   PHASE: Bound confirme le déploiement réussi. Les autres colonnes indiquent la taille des données OSS, la quantité mise en cache et la capacité totale du cache.

Préchauffer le cache (facultatif)

Fluid utilise le chargement différé, de sorte que la première exécution du Job récupère les données depuis OSS et peut prendre plusieurs dizaines de secondes pour les grands jeux de données. Préchauffez le cache pour éliminer la latence lors de la première exécution.

1. Créez un fichier nommé dataload.yaml :

   apiVersion: data.fluid.io/v1alpha1
   kind: DataLoad
   metadata:
     name: data-warmup
   spec:
     dataset:
       name: demo-dataset
       namespace: default
     loadMetadata: true

2. Démarrez la tâche de préchauffage :

   kubectl create -f dataload.yaml

   Attendez que l'état affiche Complete :

   NAME          DATASET        PHASE      AGE   DURATION
   data-warmup   demo-dataset   Complete   99s   58s

   Le préchauffage du cache s'est achevé en environ 58s.

Créer une application Job

Utilisez des conteneurs applicatifs ou des jobs de machine learning pour accéder aux données accélérées via JindoFS. Cet exemple crée un Job qui lit les données OSS. Le PVC demo-dataset lit automatiquement depuis le cache JindoFS, sans modification du code. L'étiquette alibabacloud.com/fluid-sidecar-target: eci déclenche l'injection du sidecar de mise en cache par Fluid Webhook.

1. Créez un fichier nommé job.yaml :

   apiVersion: batch/v1
   kind: Job
   metadata:
     name: demo-app
   spec:
     template:
       metadata:
         labels:
           alibabacloud.com/fluid-sidecar-target: eci
         annotations:
           # Required: disable virtual node scheduling (conflicts with Fluid — see Limitations)
           alibabacloud.com/burst-resource: eci_only
           # ECI instance spec for the application pod
           k8s.aliyun.com/eci-use-specs: ecs.g7.4xlarge
       spec:
         containers:
           - name: demo
             image: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6
             command:
               - /bin/bash
             args:
               - -c
               - du -sh /data && time cp -r /data/ /tmp
             volumeMounts:
               - mountPath: /data
                 name: demo
         restartPolicy: Never
         volumes:
           - name: demo
             persistentVolumeClaim:
               claimName: demo-dataset
     backoffLimit: 4

2. Soumettez le Job :

   kubectl create -f job.yaml

3. Consultez les journaux du Job une fois celui-ci terminé :

   kubectl logs demo-app-jwktf -c demo

   Sortie attendue :

   1.2G    /data
   
   real    0m0.992s
   user    0m0.004s
   sys     0m0.674s

   Le temps real pour la copie du fichier est de 0m0.992s.

Nettoyer les ressources

Nettoyez les ressources pour éviter des frais inutiles.

1. Supprimez le Job :

   kubectl delete job demo-app

2. Supprimez le Dataset. Cela supprime également les composants associés du système de mise en cache :

   Important

   Le nettoyage prend environ une minute. Attendez que tous les pods de mise en cache soient supprimés avant de continuer.

   kubectl delete dataset demo-dataset

3. Réduisez le plan de contrôle Fluid :

   kubectl get deployments.apps -n fluid-system | awk 'NR>1 {print $1}' | xargs kubectl scale deployments -n fluid-system --replicas=0

   Pour réactiver l'accès aux données, augmentez à nouveau le nombre de réplicas du plan de contrôle avant de créer de nouvelles ressources Dataset et JindoRuntime :

   kubectl scale -n fluid-system deployment dataset-controller --replicas=1
   kubectl scale -n fluid-system deployment fluid-webhook --replicas=1