Container Service for Kubernetes:Accelerate access to OSS files by using JindoFS

Limites

• JindoRuntime nécessite un cluster ACK Pro exécutant un système d'exploitation autre que ContainerOS. Le composant ack-fluid ne prend pas actuellement en charge ContainerOS.

• Si vous avez déjà installé Fluid open source, désinstallez-le avant de déployer le composant ack-fluid. L'exécution simultanée des deux n'est pas prise en charge.

Prérequis

Avant de commencer, assurez-vous de disposer des éléments suivants :

• Un cluster ACK Pro avec un système d'exploitation autre que ContainerOS, exécutant Kubernetes 1.18 ou une version ultérieure. Consultez Créer un cluster ACK Pro.

• Le composant ack-fluid déployé dans le cluster :

  • Si la suite d'IA native du cloud n'est pas installée, activez Fluid acceleration lors de l'installation de la suite. Consultez Déployer la suite d'IA native du cloud.

  • Si la suite d'IA native du cloud est déjà installée, accédez à la page Cloud-native AI Suite dans la console ACK et déployez le composant ack-fluid.

• Un client kubectl connecté à votre cluster ACK Pro. Consultez Se connecter à un cluster avec kubectl.

• OSS activé. Consultez Activer OSS.

Étape 1 : Charger les données sur OSS

Les étapes suivantes utilisent une instance Elastic Compute Service (ECS) exécutant Alibaba Cloud Linux 3.2104 LTS 64 bits pour charger un jeu de données de test. Pour les autres systèmes d'exploitation, consultez ossutil et ossutil 1.0.

1. Téléchargez le jeu de données de test sur votre instance ECS.

   wget https://archive.apache.org/dist/spark/spark-3.0.1/spark-3.0.1-bin-hadoop2.7.tgz

2. Installez ossutil sur l'instance ECS.

3. Créez un compartiment OSS nommé examplebucket.

   ossutil64 mb oss://examplebucket

   Sortie attendue :

   0.668238(s) elapsed

4. Chargez le jeu de données de test dans le compartiment.

   ossutil64 cp spark-3.0.1-bin-hadoop2.7.tgz oss://examplebucket

Étape 2 : Créer un dataset et un JindoRuntime

JindoRuntime lit les identifiants OSS depuis un Secret Kubernetes ; créez donc le Secret avant de créer le Dataset.

1. Créez un fichier nommé mySecret.yaml avec le contenu suivant. Remplacez xxx par l'ID AccessKey et la clé secrète AccessKey disposant d'un accès en lecture au compartiment OSS créé à l'étape 1.

   apiVersion: v1
   kind: Secret
   metadata:
     name: mysecret
   stringData:
     fs.oss.accessKeyId: xxx
     fs.oss.accessKeySecret: xxx

2. Appliquez le Secret. Kubernetes chiffre les valeurs stockées afin qu'elles ne soient pas exposées en texte clair.

   kubectl create -f mySecret.yaml

3. Créez un fichier nommé resource.yaml avec le contenu suivant. Ce fichier définit le Dataset (qui pointe vers vos données OSS) et le JindoRuntime (qui lance le cluster de mise en cache).

   apiVersion: data.fluid.io/v1alpha1
   kind: Dataset
   metadata:
     name: hadoop
   spec:
     mounts:
       - mountPoint: oss://<oss_bucket>/<bucket_dir>
         options:
           fs.oss.endpoint: <oss_endpoint>
         name: hadoop
         path: "/"
         encryptOptions:
           - name: fs.oss.accessKeyId
             valueFrom:
               secretKeyRef:
                 name: mysecret
                 key: fs.oss.accessKeyId
           - name: fs.oss.accessKeySecret
             valueFrom:
               secretKeyRef:
                 name: mysecret
                 key: fs.oss.accessKeySecret
   ---
   apiVersion: data.fluid.io/v1alpha1
   kind: JindoRuntime
   metadata:
     name: hadoop
   spec:
     replicas: 2
     tieredstore:
       levels:
         - mediumtype: MEM
           path: /dev/shm
           volumeType: emptyDir
           quota: 2Gi
           high: "0.99"
           low: "0.95"

   Le tableau suivant décrit les paramètres clés.

   Paramètre	Description	Obligatoire	Valeur par défaut
   mountPoint	Chemin d'accès au système de fichiers sous-jacent (UFS) au format oss://<oss_bucket>/<bucket_dir>. L'endpoint OSS n'est pas inclus ici.	Oui	—
   fs.oss.endpoint	Endpoint public ou interne du compartiment OSS. Consultez Régions et endpoints.	Oui	—
   replicas	Nombre de workers dans le cluster de mise en cache JindoFS.	Oui	—
   mediumtype	Support de stockage du cache. Valeurs valides : HDD, SSD, MEM.	Oui	—
   path	Chemin de stockage local sur le nœud worker. Un seul chemin est autorisé. Obligatoire lorsque mediumtype est MEM pour stocker des données telles que les journaux.	Oui	—
   quota	Taille maximale du cache par worker.	Oui	—
   high	Seuil d'éviction du cache (filigrane haut). Lorsque l'utilisation dépasse ce ratio, l'éviction commence.	Non	—
   low	Seuil de rétention du cache (filigrane bas). L'éviction s'arrête lorsque l'utilisation atteint ce ratio.	Non	—

4. Créez le Dataset et le JindoRuntime.

   kubectl create -f resource.yaml

5. Vérifiez que le Dataset est lié.

   kubectl get dataset hadoop

   Sortie attendue :

   NAME     UFS TOTAL SIZE   CACHED   CACHE CAPACITY   CACHED PERCENTAGE   PHASE   AGE
   hadoop        210MiB       0.00B    4.00GiB              0.0%          Bound   1h

6. Vérifiez que le JindoRuntime est prêt.

   kubectl get jindoruntime hadoop

   Sortie attendue :

   NAME     MASTER PHASE   WORKER PHASE   FUSE PHASE   AGE
   hadoop   Ready          Ready          Ready        4m45s

7. Vérifiez que le volume persistant (PV) et la revendication de volume persistant (PVC) sont créés.

   kubectl get pv,pvc

   Sortie attendue :

   NAME                              CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM            STORAGECLASS   REASON   AGE
   persistentvolume/default-hadoop   100Pi      ROX            Retain           Bound    default/hadoop                           52m
   
   NAME                           STATUS   VOLUME            CAPACITY   ACCESS MODES   STORAGECLASS   AGE
   persistentvolumeclaim/hadoop   Bound    default-hadoop    100Pi      ROX                           52m

Le Dataset et le JindoRuntime sont prêts lorsque toutes les phases indiquent Ready et que l'état du PVC est Bound.

Étape 3 : Tester l'accélération des données

Déployez un pod qui monte le PVC du Dataset et comparez les temps de lecture des fichiers avant et après la mise en cache des données.

1. Créez un fichier nommé app.yaml avec le contenu suivant.

   apiVersion: v1
   kind: Pod
   metadata:
     name: demo-app
   spec:
     containers:
       - name: demo
         image: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6
         volumeMounts:
           - mountPath: /data
             name: hadoop
     volumes:
       - name: hadoop
         persistentVolumeClaim:
           claimName: hadoop

2. Déployez le pod.

   kubectl create -f app.yaml

3. Ouvrez un shell dans le pod et vérifiez la taille du fichier.

   kubectl exec -it demo-app -- bash
   du -sh /data/hadoop/spark-3.0.1-bin-hadoop2.7.tgz

   Sortie attendue :

   210M    /data/hadoop/spark-3.0.1-bin-hadoop2.7.tgz

4. Mesurez le temps de lecture initial. Cet accès provient directement d'OSS, sans cache.

   time cp /data/hadoop/spark-3.0.1-bin-hadoop2.7.tgz /dev/null

   Sortie attendue :

   real    0m18.386s
   user    0m0.002s
   sys    0m0.105s

   La lecture du fichier prend environ 18 secondes.

5. Vérifiez les données mises en cache après la lecture.

   kubectl get dataset hadoop

   Sortie attendue :

   NAME     UFS TOTAL SIZE   CACHED   CACHE CAPACITY   CACHED PERCENTAGE   PHASE   AGE
   hadoop   210.00MiB       210.00MiB    4.00GiB        100.0%           Bound   1h

   L'intégralité des 210 MiB est désormais mise en cache dans le stockage local.

6. Supprimez et recréez le pod pour vider le cache de pages du système d'exploitation, afin que la prochaine lecture provienne du cache JindoFS plutôt que de la mémoire.

   kubectl delete -f app.yaml && kubectl create -f app.yaml

7. Mesurez à nouveau le temps de lecture avec les données servies depuis le cache.

   kubectl exec -it demo-app -- bash
   time cp /data/hadoop/spark-3.0.1-bin-hadoop2.7.tgz /dev/null

   Sortie attendue :

   real    0m0.048s
   user    0m0.001s
   sys     0m0.046s

   Avec le cache JindoFS, la même lecture de fichier s'achève en 48 millisecondes, soit plus de 300 fois plus rapidement que l'accès direct à OSS.

(Facultatif) Nettoyage

Lorsque l'accélération des données n'est plus nécessaire, supprimez le pod, le Dataset et le JindoRuntime.

Supprimez le pod :

kubectl delete pod demo-app

Supprimez le Dataset et le JindoRuntime :

kubectl delete dataset hadoop

Étapes suivantes

• Pour soumettre des tâches d'entraînement d'apprentissage automatique utilisant des données accélérées par JindoFS, consultez la documentation de la suite d'IA native du cloud.

• Pour explorer d'autres options de stockage de cache (HDD, SSD), mettez à jour les champs mediumtype et path dans resource.yaml.