Dans un cluster Kubernetes, la mise à niveau des pods de montage (Mount Pods) JuiceFS s'effectue traditionnellement par redémarrage des pods applicatifs via un déploiement progressif. Cette approche impose une interruption de service pour les applications consommatrices.
Une alternative manuelle consiste à supprimer directement le pod de montage après modification de la configuration, puis à s'appuyer sur le mécanisme de récupération automatique des points de montage du CSI. Cette méthode présente toutefois plusieurs limitations :
- Complexité opérationnelle : l'opérateur doit identifier manuellement, via kubectl, le pod de montage associé à chaque pod applicatif ;
- Indisponibilité temporaire : le CSI attend la suppression complète de l'ancien pod avant d'en créer un nouveau, laissant l'application dans un état non fonctionnel pendant la transition ;
- Échec des opérations d'E/S en cours : la récupération automatique reposant sur un re-bind du point de montage, toute opération d'E/S antérieure est définitivement perdue après récupération.
Pour pallier ces défauts, JuiceFS CSI Driver propose depuis la version v0.25.0 un mécanisme de mise à niveau transparente, permettant d'actualiser les pods de montage sans interrompre les charges de travail.
Avantages de la mise à niveau transparente
- Simplicité opérationnelle : le tableau de bord CSI permet d'identifier visuellement les pods de montage rattachés à chaque pod applicatif et de lancer la mise à niveau en un seul clic ;
- Continuité de service : les applications ne subissent aucune interruption, ce qui permet également d'ajuster les paramètres et configurations des pods de montage à chaud.
Mécanismes d'implémentation
Le CSI met à disposition deux stratégies de mise à niveau transparente : la mise à niveau binaire et la reconstruction de pod.
Mise à niveau binaire
Cette approche ne reconstruit pas le pod de montage mais remplace uniquement le binaire du client JuiceFS qu'il contient. Elle s'appuie sur le démon de supervision interne du client JuiceFS, disponilbe à partir de la v1.2.0 en édition communautaire et v5.0.0 en édition entreprise.
Déroulement :
- Le composant CSI Node lance un Job temporaire utilisant la nouvelle image, qui copie le binaire JuiceFS mis à jour dans le pod de montage ;
- Une fois le Job terminé, CSI Node envoie un signal SIGHUP au pod de montage ;
- À réception du signal, le processus de service sérialise l'état des requêtes d'E/S en cours vers un fichier temporaire, puis s'arrête ;
- Le démon interne détecte l'arrêt et relance un nouveau processus de service avec le binaire actualisé ;
- Le nouveau processus charge le fichier d'état intermédiaire et reprend le traitement des requêtes suspendues ;
- Le nouveau processus récupère le descripteur de fichier FUSE auprès du démon.
Cette méthode est adoptée aux mises à jour limitées au client. L'image du pod reste inchangée dans le manifeste YAML, ce qui rend l'opération rapide et peu risquée, mais ne permet pas de modifier d'autres paramètres de configuration du pod.
Reconstruction de pod
Cette stratégie reconstruit entièrement le pod de montage tout en préservant la continuité. Elle exploite la fonction de mise à niveau transparente native de JuiceFS, nécessitant la v1.2.1 (édition communautaire) ou v5.1.0 (édition entreprise) au minimum.
Déroulement :
- Dès son démarrage, chaque pod de montage transmet son descripteur de fichier FUSE au CSI Node, qui conserve une table de correspondance ;
- Lors du déclenchement de la mise à niveau, CSI Node lance d'abord un Job vide avec la même configuration que le futur pod, afin de pré-charger la nouvelle image sur le nœud et réduire le temps de transition ;
- Une fois le pré-chargement terminé, CSI Node envoei un signal SIGHUP à l'ancien pod de montage ;
- L'ancien pod sérialise l'état des E/S dans un fichier temporaire puis s'arrête, passant à l'état Completed ;
- CSI Node crée le nouveau pod de montage selon la configuration du ConfigMap ;
- Le nouveau pod démarre, lit le fichier d'état intermédiaire et reprend les requêtes ;
- Le nouveau pod récupère le descripteur de fichier FUSE auprès du CSI Node.
Le transfert du descripteur de fichier entre le pod de montage et le CSI Node s'effectue via un socket de domaine Unix. Les requêtes FUSE non achevées au moment de la transition sont interrompues de force ; il est donc recommandé d'opérer pendant les périodes de faible charge.
Ce mécanisme s'apparente à la mise à niveau transparente d'un client sur machine hôte, à la différence près que c'est le CSI Node qui assume l'envoi du SIGHUP et la transmission du descripteur FUSE. Cette délégation est nécessaire car, après reconstruction du pod, le nouveau démon ne peut pas communiquer avec l'ancien via le socket de domaine Unix.
L'avantage de cette approche est de permettre la mise à jour complète de la configuration du pod (image, ressources, paramètres de montage). En contrepartie, la reconstruction du pod comporte un risque d'échec accrue dans les environnements complexes.
Déclenchement de la mise à niveau
La mise à niveau transparente peut être lancée depuis le tableau de bord CSI ou via le plugin kubectl.
Via le tableau de bord CSI
Dans un premier temps, accéder au tableau de bord et cliquer sur le bouton de configuration pour renseigner la nouvelle version d'image du pod de montage.
Sur la page de détail du pod de montage, deux boutons sont disponibles :
- Reconstruction de pod : reconstruit entièrement le pod, permettant de mettre à jour l'image, les paramètres de montage et les ressources. Version minimale requise : 1.2.1 (édition communautaire) ou 5.1.0 (édition entreprise) ;
- Mise à niveau binaire : remplace uniquement le binaire sans reconstruire le pod. Aucune modification de configuration supplémentaire n'est possible et l'image affichée dans le YAML reste inchangée. Version minimale requise : 1.2.0 (édition communautaire) ou 5.0.0 (édition entreprise).
Après déclenchement, le suivi de la progression est visible directement dans l'interface, avec redirection automatique vers la page du nouveau pod une fois l'opération terminée.
Via le plugin kubectl
Mettre à jour l'image cible dans le ConfigMap CSI :
apiVersion: v1
data:
config.yaml: |
mountPodPatch:
- ceMountImage: juicedata/mount:ce-v1.2.0
eeMountImage: juicedata/mount:ee-5.1.1-ca439c2
kind: ConfigMap
Lancer la mise à niveau via le plugin JuiceFS kubectl :
# Reconstruction de pod
kubectl jfs upgrade juicefs-kube-node-1-pvc-52382ebb-f22a-4b7d-a2c6-1aa5ac3b26af-ebngyg --recreate
# Mise à niveau binaire
kubectl jfs upgrade juicefs-kube-node-1-pvc-52382ebb-f22a-4b7d-a2c6-1aa5ac3b26af-ebngyg
Le choix entre les deux méthodes dépend du scénario : la mise à niveau binaire est privilégiée pour les mises à jour rapides du client seul, tandis que la reconstruction de pod s'impose lorsqu'une modification complète de la configuration est nécessaire, comme l'ajustement dynamique des ressources en fonction de la consommation réelle. Dans tous les cas, il est conseillé d'effectuer ces opérations durant les fenêtres de faible activité.