Container Service for Kubernetes:Use JindoRuntime to persist storage for the JindoFS master

Fonctionnement

JindoFS repose sur une architecture maître-travailleur. Le maître gère les métadonnées et les points de montage des données mises en cache, tandis que les travailleurs gèrent les données mises en cache elles-mêmes. Lorsque vous conteneurisez le maître et les travailleurs dans un cluster Kubernetes, le pod maître peut être redémarré ou replanifié à tout moment.

Sans stockage persistant, les métadonnées du maître résident uniquement dans le système de fichiers local du pod ; elles disparaissent lors d'un redémarrage. En montant une PersistentVolumeClaim (PVC) sur le pod maître et en définissant namespace.meta-dir sur le chemin de montage, JindoRuntime écrit les métadonnées sur le PV. Lorsque le pod est recréé sur un autre nœud, il lit les mêmes métadonnées depuis le PV et reprend son fonctionnement normal.

Ce guide utilise un volume disque pour le stockage persistant. Un volume disque persiste lors des redémarrages et des replanifications de pods au sein de la même zone de disponibilité. Assurez-vous que votre cluster dispose d'au moins deux nœuds dans la même zone afin que le pod maître puisse être replanifié sur un nœud différent tout en accédant au même disque.

Prérequis

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

• Un cluster ACK Pro exécutant Kubernetes 1.18 ou une version ultérieure. Consultez la rubrique Créer un cluster ACK managé.

• La suite AI cloud-native et ack-fluid 1.0.5 ou une version ultérieure déployées. Consultez la rubrique Déployer la suite AI cloud-native.

  Important

  Si vous avez déjà installé Fluid open source, désinstallez-le et déployez plutôt le composant ack-fluid.

• kubectl connecté au cluster. Consultez la rubrique Obtenir le fichier kubeconfig d'un cluster et utiliser kubectl pour se connecter au cluster.

• Un bucket Object Storage Service (OSS) contenant des fichiers téléchargés. L'utilisateur Resource Access Management (RAM) doit avoir accès au bucket. Consultez la rubrique Créer un bucket. Pour accorder l'accès à l'utilisateur RAM, consultez la rubrique Ajouter une politique de bucket.

Étape 1 : Créer une PVC pour les métadonnées du maître

Créez un fichier nommé pvc.yaml avec le contenu suivant :

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: demo-jindo-master-meta
spec:
  accessModes:
    - ReadWriteOnce                        # Disk volumes support single-node read/write
  storageClassName: alicloud-disk-topology-alltype
  resources:
    requests:
      storage: 30Gi

Pour obtenir la liste complète des paramètres PVC, consultez la rubrique Utiliser un volume disque provisionné dynamiquement.

Appliquez le manifeste :

kubectl create -f pvc.yaml

Résultat attendu :

persistentvolumeclaim/demo-jindo-master-meta created

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

apiVersion: v1
kind: Secret
metadata:
  name: access-key
stringData:
  fs.oss.accessKeyId: ******     # Replace with your AccessKey ID
  fs.oss.accessKeySecret: ******  # Replace with your AccessKey secret

kubectl create -f secret.yaml

secret/access-key created

apiVersion: data.fluid.io/v1alpha1
kind: Dataset
metadata:
  name: demo
spec:
  mounts:
    - mountPoint: oss://<OSS_BUCKET>/<BUCKET_DIR>   # Replace with your OSS bucket path
      name: demo
      path: /
      options:
        fs.oss.endpoint: <OSS_BUCKET_ENDPOINT>       # Replace with your OSS endpoint
      encryptOptions:
        - name: fs.oss.accessKeyId
          valueFrom:
            secretKeyRef:
              name: access-key
              key: fs.oss.accessKeyId
        - name: fs.oss.accessKeySecret
          valueFrom:
            secretKeyRef:
              name: access-key
              key: fs.oss.accessKeySecret
---
apiVersion: data.fluid.io/v1alpha1
kind: JindoRuntime
metadata:
  name: demo
spec:
  replicas: 2
  # [ Required for persistent storage ]
  volumes:
    - name: meta-vol
      persistentVolumeClaim:
        claimName: demo-jindo-master-meta  # The PVC created in Step 1
  master:
    # [ Required for persistent storage ]
    volumeMounts:
      - name: meta-vol
        mountPath: /root/jindofsx-meta    # Path where the PV is mounted in the master pod
    properties:
      namespace.meta-dir: "/root/jindofsx-meta"  # Must match mountPath above
  tieredstore:
    levels:
      - mediumtype: MEM
        path: /dev/shm
        volumeType: emptyDir   # Worker cache — not persistent across restarts
        quota: 12Gi
        high: "0.99"
        low: "0.99"

kubectl create -f dataset.yaml

dataset.data.fluid.io/demo created
jindoruntime.data.fluid.io/demo created

kubectl get dataset

NAME   UFS TOTAL SIZE   CACHED   CACHE CAPACITY   CACHED PERCENTAGE   PHASE   AGE
demo   531.89MiB        0.00B    24.00GiB         0.0%                Bound   5m35s

Étape 3 : Vérifier le stockage persistant

Simulez une replanification du pod maître pour confirmer que les métadonnées survivent.

1. Créez un fichier nommé pod.yaml pour déployer une application de test qui monte le Dataset :

   apiVersion: v1
   kind: Pod
   metadata:
     name: nginx
   spec:
     containers:
       - name: nginx
         image: registry.openanolis.cn/openanolis/nginx:1.14.1-8.6
         volumeMounts:
           - mountPath: /data
             name: data-vol
     volumes:
       - name: data-vol
         persistentVolumeClaim:
           claimName: demo

2. Déployez le pod :

   kubectl create -f pod.yaml

   Résultat attendu :

   pod/nginx created

3. Confirmez que l'accès aux données fonctionne avant la replanification :

   kubectl exec -it nginx -- ls /data

   La sortie liste les fichiers du bucket OSS spécifié dans Dataset.spec.mountPoint.

4. Recherchez le nœud exécutant le maître JindoFS :

   master_node=$(kubectl get pod -o wide | awk '/demo-jindofs-master-0/ {print $7}')

5. Ajoutez une taint à ce nœud pour empêcher les pods d'y être replanifiés :

   kubectl taint node $master_node test-jindofs-master=reschedule:NoSchedule

   Résultat attendu :

   node/cn-beijing.192.168.xx.xx tainted

6. Supprimez le pod maître. Kubernetes le recrée sur un nœud différent de la même zone et monte la même PVC :

   Le nouveau pod maître doit être planifié sur un nœud situé dans la même zone de disponibilité que le nœud d'origine, car les volumes disque ne peuvent pas être montés entre différentes zones. Assurez-vous que votre cluster dispose d'au moins deux nœuds dans la zone où le pod maître d'origine s'exécutait.

   kubectl delete pod demo-jindofs-master-0

   Résultat attendu :

   pod "demo-jindofs-master-0" deleted

7. Recréez le pod d'application pour vérifier que les données restent accessibles après la replanification du maître :

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

   Résultat attendu :

   pod "nginx" deleted
   pod/nginx created

8. Confirmez l'accès aux données depuis le pod recréé :

   kubectl exec -it nginx -- ls /data

   La sortie liste les mêmes fichiers qu'avant la replanification, confirmant que le stockage persistant fonctionne correctement.

Étape 4 : Nettoyer les ressources

1. Supprimez le pod d'application :

   kubectl delete -f pod.yaml

   Résultat attendu :

   pod "nginx" deleted

2. Retirez la taint du nœud :

   kubectl taint node $master_node test-jindofs-master-

   Résultat attendu :

   node/cn-beijing.192.168.xx.xx untainted

3. (Facultatif) Supprimez le Dataset, le JindoRuntime et la PVC :

   Important

   Après la création d'un volume disque, vous êtes facturé pour le disque sous-jacent. Si vous n'avez plus besoin de l'accélération des données, supprimez les ressources pour cesser d'encourir des frais. Consultez la rubrique Volumes disque pour plus de détails sur la tarification. Avant de supprimer, assurez-vous qu'aucune application n'utilise le Dataset et qu'aucune opération d'E/S n'est en cours.

   kubectl delete -f dataset.yaml
   kubectl delete -f pvc.yaml