Enable the auto recovery feature for FUSE mount targets - Container Service for Kubernetes

Le démon Filesystem in Userspace (FUSE) peut tomber en panne pendant le cycle de vie d'un pod d'application. Le pod ne peut alors plus utiliser le système de fichiers FUSE pour accéder aux données. Cette rubrique explique comment activer la récupération automatique des points de montage d'un système de fichiers FUSE afin de rétablir l'accès aux données de l'application sans redémarrer les pods.

Vue d'ensemble

Problème

Les pods d'application qui utilisent des jeux de données Fluid accèdent aux données d'un système de cache distribué via le système de fichiers FUSE. Chaque système de fichiers FUSE correspond à un processus démon FUSE chargé de traiter les demandes d'accès aux fichiers.

Le démon FUSE peut tomber en panne pendant le cycle de vie d'un pod d'application. Par exemple, si l'utilisation de la mémoire dépasse la limite supérieure, le système arrête le démon. L'erreur « Transport Endpoint is Not Connected » s'affiche alors lorsque le pod tente d'accéder aux fichiers du système de fichiers FUSE. Pour résoudre ce problème, vous devez redémarrer ou reconstruire manuellement le pod afin de rétablir l'accès au système de fichiers FUSE.

Fonctionnement

Fluid propose une fonctionnalité de récupération automatique pour les points de montage d'un système de fichiers FUSE. En interrogeant périodiquement l'état du système de fichiers FUSE monté sur chaque pod d'application d'un nœud, Fluid détecte les pannes du démon FUSE. Une fois que Kubernetes a redémarré automatiquement le conteneur du démon, Fluid détecte la récupération et remonte le système de fichiers. L'accès aux données est ainsi rétabli pour les pods d'application sans qu'il soit nécessaire de les redémarrer ou de les reconstruire.

Cluster ACK vs serverless : principales différences

La fonctionnalité de récupération automatique est disponible dans les clusters ACK Pro et ACK Serverless Pro. Le tableau suivant résume les principales différences entre ces deux approches.

Aspect	Cluster ACK Pro	Cluster ACK Serverless Pro
Mécanisme d'activation	Définissez la porte de fonctionnalité `FuseRecovery=true` sur le DaemonSet CSI	Définissez l'annotation `alibabacloud.com/fuse-recover-policy: auto` sur chaque pod
Configuration du pod	Libellé : `fuse.serverful.fluid.io/inject: "true"`	Libellé : `alibabacloud.com/fluid-sidecar-target: eci` + annotations
État READY attendu du pod	`1/1`	`2/2`
Cible de simulation de panne FUSE	Pod FUSE distinct sur le même nœud	Conteneur sidecar `fluid-fuse-0` au sein du même pod
Prérequis supplémentaires	Nœuds virtuels déployés dans le cluster	Aucun

Limites

Le processus de récupération automatique introduit un délai et ne prend pas en charge la récupération transparente pour les applications métier. Ces dernières doivent tolérer les échecs d'accès aux données et continuer à réessayer jusqu'au rétablissement de l'accès.
Vous ne pouvez activer la récupération automatique que pour les jeux de données en lecture seule. Si le cluster contient un jeu de données accessible en lecture et en écriture, assurez-vous que cette fonctionnalité est désactivée pour éviter toute écriture inattendue dans le jeu de données.
Cette fonctionnalité ne permet pas de monter les pods d'application sur les revendications de volume persistant (PVC) des jeux de données en mode subPath.
La récupération automatique FUSE intervient après le redémarrage automatique du démon FUSE. Le démon FUSE s'exécute dans un conteneur. En cas de pannes fréquentes du démon, l'intervalle de redémarrage du conteneur par Kubernetes augmente de manière exponentielle, ce qui prolonge la durée de la récupération automatique.

Prérequis communs

Les prérequis suivants s'appliquent aux scénarios de cluster ACK Pro et ACK Serverless Pro.

Exigences relatives au cluster

Un cluster ACK Pro ou ACK Serverless Pro utilisant un système d'exploitation autre que ContainerOS doit être créé, avec une version Kubernetes 1.18 ou ultérieure. Pour plus d'informations, consultez Créer un cluster ACK Pro ou Créer un cluster ACK Serverless.

Important

Le composant ack-fluid n'est actuellement pas pris en charge sur ContainerOS.

Exigences relatives aux composants

La suite AI cloud-native est installée et le composant ack-fluid est déployé.

Important

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

Si vous n'avez pas installé la suite AI cloud-native, activez Fluid acceleration lors de l'installation de la suite. Pour plus d'informations, consultez Installer la suite AI cloud-native.
Si vous avez déjà installé la suite AI cloud-native, accédez à la page Cloud-native AI Suite de la console ACK et déployez le composant ack-fluid.

Exigences relatives à l'infrastructure

Un client kubectl est connecté au cluster ACK Pro. Pour plus d'informations, consultez Se connecter à un cluster à l'aide de kubectl.
OSS est activé et un bucket est créé. Pour plus d'informations, consultez Activer OSS et Créer des buckets.

Prérequis supplémentaires pour les clusters ACK Pro

Des nœuds virtuels sont déployés dans le cluster ACK Pro. Pour plus d'informations, consultez Planifier des pods sur des instances de conteneur élastiques.

Créer un jeu de données Fluid

Cette section décrit comment créer un jeu de données Fluid sauvegardé par OSS. Ces étapes sont communes aux scénarios de cluster ACK Pro et ACK Serverless Pro.

Dans cet exemple, JindoFS est déployé pour accélérer l'accès à OSS.

Créez un fichier nommé secret.yaml et copiez-y le contenu suivant : fs.oss.accessKeyId et fs.oss.accessKeySecret spécifient l'AccessKey ID et la AccessKey secret utilisés pour accéder à OSS.
```
apiVersion: v1
kind: Secret
metadata:
  name: mysecret
stringData:
  fs.oss.accessKeyId: <YOUR_ACCESS_KEY_ID>
  fs.oss.accessKeySecret: <YOUR_ACCESS_KEY_SECRET>
```
Exécutez la commande suivante pour créer un Secret :
```
kubectl create -f secret.yaml
```

Créez un fichier nommé dataset.yaml et copiez-y le contenu suivant. Le tableau suivant décrit les paramètres.

Paramètre	Description
`mountPoint`	oss:/// spécifie le chemin d'accès au UFS monté. L'endpoint n'est pas requis dans le chemin.
`fs.oss.endpoint`	L'endpoint public ou privé du bucket OSS. Pour plus d'informations, consultez Régions et endpoints OSS.
`replicas`	Le nombre de workers dans le cluster JindoFS.
`mediumtype`	Le type de cache. Lors de la création d'un modèle JindoRuntime, JindoFS prend en charge uniquement l'un des types de cache suivants : HDD, SSD et MEM.
`path`	Le chemin de stockage. Vous ne pouvez spécifier qu'un seul chemin. Si vous définissez mediumtype sur MEM, vous devez spécifier un chemin de stockage local pour stocker des données telles que les journaux.
`quota`	La taille maximale des données mises en cache. Unité : Go.
`high`	La limite supérieure de la capacité de stockage.
`low`	La limite inférieure de la capacité de stockage.

apiVersion: data.fluid.io/v1alpha1
kind: Dataset
metadata:
  name: demo-dataset
spec:
  mounts:
    - mountPoint: oss://<oss_bucket>/<bucket_dir>
      options:
        fs.oss.endpoint: <oss_endpoint>
      name: mybucket
      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: demo-dataset
spec:
  replicas: 2
  tieredstore:
    levels:
      - mediumtype: MEM
        path: /dev/shm
        volumeType: emptyDir
        quota: 2Gi
        high: "0.99"
        low: "0.95"

Exécutez la commande suivante pour créer un objet Dataset et un objet JindoRuntime :
```
kubectl create -f dataset.yaml
```

Activer la récupération automatique des points de montage FUSE dans un cluster ACK

Cette section explique comment activer et vérifier la récupération automatique FUSE dans un cluster ACK Pro.

Étape 1 : Activer la récupération automatique des points de montage FUSE

Exécutez la commande suivante pour activer la récupération automatique des points de montage FUSE :

kubectl get ds -n fluid-system csi-nodeplugin-fluid -oyaml | sed 's/FuseRecovery=false/FuseRecovery=true/g' | kubectl apply -f -

Sortie attendue :

daemonset.apps/csi-nodeplugin-fluid configured

Exécutez la commande suivante pour vérifier si la récupération automatique est activée pour les points de montage FUSE :

kubectl get ds -n fluid-system csi-nodeplugin-fluid -oyaml | grep '\- \-\-feature-gates='

Si la sortie suivante s'affiche, la récupération automatique est activée pour les points de montage FUSE :

- --feature-gates=FuseRecovery=true

Étape 2 : Créer un pod d'application et monter le jeu de données Fluid

Dans cet exemple, un jeu de données Fluid est monté sur un pod NGINX utilisé pour accéder aux données du jeu de données.

Créez un fichier nommé app.yaml et copiez-y le contenu suivant. Le libellé fuse.serverful.fluid.io/inject=true active la récupération automatique pour le point de montage FUSE du pod.

apiVersion: v1
kind: Pod
metadata:
  name: demo-app
  labels:
    fuse.serverful.fluid.io/inject: "true"
spec:
  containers:
    - name: demo
      image: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6
      volumeMounts:
        - mountPath: /data
          name: data-vol
  volumes:
    - name: data-vol
      persistentVolumeClaim:
        claimName: demo-dataset   # The value of this parameter must be the same as the name of the Dataset.

Exécutez la commande suivante pour créer un pod d'application :
```
kubectl create -f app.yaml
```
Exécutez la commande suivante pour afficher l'état du pod d'application. Si le champ STATUS du pod indique Running, le pod a démarré avec succès.
```
kubectl get pod demo-app
```
```
NAME       READY   STATUS    RESTARTS   AGE
demo-app   1/1     Running   0          16s
```

Étape 3 : Vérifier la récupération automatique du point de montage FUSE

Exécutez la commande suivante pour vous connecter au pod d'application et lancer un script qui accède périodiquement aux métadonnées des fichiers. Le script liste les fichiers du jeu de données Fluid monté toutes les secondes.
```
kubectl exec -it demo-app -- bash -c 'while true; do ls -l /data; sleep 1; done'
```

Laissez le script précédent s'exécuter en arrière-plan et exécutez la commande suivante pour simuler une panne du composant FUSE :

# Obtain the node where demo-pod resides.
demo_pod_node_name=$(kubectl get pod demo-app -ojsonpath='{.spec.nodeName}')
# Obtain the name of the FUSE pod on the same node as demo-pod.
fuse_pod_name=$(kubectl get pod --field-selector spec.nodeName=$demo_pod_node_name --selector role=jindofs-fuse,release=demo-dataset -oname)
# Simulate a crash in the FUSE pod.
kubectl exec -it $fuse_pod_name -- bash -c 'kill 1'

Consultez la sortie du script exécuté dans demo-app. Si la sortie suivante s'affiche, le point de montage FUSE a été récupéré avec succès.

...
total 172
-rwxrwxr-x 1 root root          18 Jul  1 15:17 myfile
-rwxrwxr-x 1 root root         154 Jul  1 17:06 myfile.txt
total 172
-rwxrwxr-x 1 root root          18 Jul  1 15:17 myfile
-rwxrwxr-x 1 root root         154 Jul  1 17:06 myfile.txt
ls: cannot access '/data/': Transport endpoint is not connected
ls: cannot access '/data/': Transport endpoint is not connected
ls: cannot access '/data/': Transport endpoint is not connected
ls: cannot access '/data/': Transport endpoint is not connected
ls: cannot access '/data/': Transport endpoint is not connected
ls: cannot access '/data/': Transport endpoint is not connected
ls: cannot access '/data/': Transport endpoint is not connected
ls: cannot access '/data/': Transport endpoint is not connected
total 172
-rwxrwxr-x 1 root root          18 Jul  1 15:17 myfile
-rwxrwxr-x 1 root root         154 Jul  1 17:06 myfile.txt
total 172
-rwxrwxr-x 1 root root          18 Jul  1 15:17 myfile
-rwxrwxr-x 1 root root         154 Jul  1 17:06 myfile.txt
...

Activer la récupération automatique des points de montage FUSE dans un environnement serverless

Cette section explique comment activer et vérifier la récupération automatique FUSE dans un cluster ACK Serverless Pro. Dans un environnement serverless, il n'est pas nécessaire de définir une porte de fonctionnalité. Activez plutôt la récupération automatique via une annotation de pod.

Vous avez créé un cluster ACK Serverless Pro utilisant un système d'exploitation autre que ContainerOS, avec une version de cluster 1.18 ou ultérieure. Pour plus d'informations, consultez Créer un cluster ACK Serverless.

Étape 1 : Créer un pod d'application et monter le jeu de données Fluid

Dans cet exemple, un jeu de données Fluid est monté sur un pod NGINX utilisé pour accéder aux données du jeu de données.

Créez un fichier nommé app.yaml et copiez-y le contenu suivant. L'annotation alibabacloud.com/fuse-recover-policy=auto active la récupération automatique pour le point de montage FUSE du pod. Cette annotation prend effet uniquement sur les pods d'application s'exécutant dans l'environnement serverless.

apiVersion: v1
kind: Pod
metadata:
  name: demo-app
  labels:
    alibabacloud.com/fluid-sidecar-target: eci
  annotations:
    # Disable the virtual node-based pod scheduling policy.
    alibabacloud.com/burst-resource: eci_only
    # Enable auto recovery for FUSE mount targets
    alibabacloud.com/fuse-recover-policy: auto
spec:
  containers:
    - name: demo
      image: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6
      volumeMounts:
        - mountPath: /data
          name: data-vol
  volumes:
    - name: data-vol
      persistentVolumeClaim:
        claimName: demo-dataset  # The value of this parameter must be the same as the name of the Dataset.

Exécutez la commande suivante pour créer un pod d'application :
```
kubectl create -f app.yaml
```
Exécutez la commande suivante pour afficher l'état du pod d'application. Si le champ STATUS du pod indique Running, le pod a démarré avec succès.
```
kubectl get pod demo-app
```
```
NAME       READY   STATUS    RESTARTS   AGE
demo-app   2/2     Running   0          110s
```

Étape 2 : Vérifier la récupération automatique du point de montage FUSE

Exécutez la commande suivante pour vous connecter au pod d'application et lancer un script qui accède périodiquement aux métadonnées des fichiers. Le script liste les fichiers du jeu de données Fluid monté toutes les secondes.
```
kubectl exec -it demo-app -c demo -- bash -c 'while true; do ls -l /data; sleep 1; done'
```
Laissez le script précédent s'exécuter en arrière-plan et exécutez la commande suivante pour simuler une panne du composant FUSE :
```
# Simulate a crash in the FUSE pod.
kubectl exec -it demo-app -c fluid-fuse-0 -- bash -c 'kill 1'
```

Consultez la sortie du script exécuté dans demo-app. Si la sortie suivante s'affiche, le point de montage FUSE a été récupéré avec succès.

total 172
-rwxrwxr-x 1 root root          18 Jul  1 15:17 myfile
-rwxrwxr-x 1 root root         154 Jul  1 17:06 myfile.txt
total 172
-rwxrwxr-x 1 root root          18 Jul  1 15:17 myfile
-rwxrwxr-x 1 root root         154 Jul  1 17:06 myfile.txt
ls: cannot access '/data/demo2': Transport endpoint is not connected
ls: cannot access '/data/demo2': Transport endpoint is not connected
ls: cannot access '/data/demo2': Transport endpoint is not connected
ls: cannot access '/data/demo2': Transport endpoint is not connected
total 172
-rwxrwxr-x 1 root root          18 Jul  1 15:17 myfile
-rwxrwxr-x 1 root root         154 Jul  1 17:06 myfile.txt
total 172
-rwxrwxr-x 1 root root          18 Jul  1 15:17 myfile
-rwxrwxr-x 1 root root         154 Jul  1 17:06 myfile.txt