blog-image

Kubernetes 1.27 et GlusterFS - Export NFS

  • dHENRY
  • 15/10/2023
  • (Durée de lecture : 5 mn)

Comme annoncé dans le billet précédent le support des volumes GlusterFS a été supprimé de la version Kubernetes 1.27.

Pour continuer d’utiliser GlusterFS avec Kubernetes, il existe une solution qui va convenir aux deux systèmes : NFS (Network File System).

Kubernetes supporte ce type de volumes et les volumes GlusterFS peuvent être exportés NFS au travers du service “nfs-ganesha”.

Pour préparer la migration vers 1.27 avec ce changement majeur, assurez-vous que le support des volumes NFS fonctionne déjà sur votre cluster actuel et pour toutes les applications utilisant des volumes GlusterFS.

NFS et Serveur GlusterFS

Attention si votre serveur Gluster utilise déjà un service NFS standard, celui-ci devra être stoppé. Le service NFS-GANESHA, une fois installé, prendra le relais.

Pour lister les volumes exportés via NFS par votre serveur : showmount -e localhost

Préparation du serveur (Debian 11)

(source) :

  • Connecté “root” au serveur Gluster:
    • Arrêter le service nfs (si existant) : systemctl stop nfs;systemctl disable nfs
    • Pour chaque volume Gluster : désactivation NFS et activation features.cache-invalidation
volumes=$(gluster v list) \
for vol in $volumes \
do \
  echo "Setting volume : $vol" \
  gluster vol set $vol nfs.disable ON \
  gluster vol set $vol features.cache-invalidation ON \
done
  • Installation des paquets Debian : apt install nfs-ganesha nfs-ganesha-gluster

A cette étape, vous devez vérifier le statut de fonctionnement du serveur nfs-ganesha : systemctl status nfs-ganesha. Le statut doit être “Running”.

Export NFS d’un volume GlusterFS

Sélectionner un volume GlusterFS à exporter via NFS, pour lister vos volumes : gluster v list.

Éditer le fichier “/etc/ganesha/ganesha.conf” en ajoutant le premier export (fin de fichier) :

Pour cet exemple, j’ai choisi d"exporter le volume GlusterFS : “musicdata”, (à adapter selon votre contexte)

!!!ATTENTION!!! ===» Lorsque vous allez ajouter des volumes à exporter dans ce fichier, comme indiqué, changez bien la valeur de “Export_Id” qui doit être unique pour chaque volume exporté.

[...]
EXPORT
{
        Export_Id = 1; # Export ID unique to each export
        Path = "musicdata";  # Path of the volume to be exported. Eg: "/test_volume"

        FSAL {
                name = GLUSTER;
                hostname = "localhost";  # IP of one of the nodes in the trusted pool
                volume = "musicdata";         # Volume name. Eg: "test_volume"
        }

        Access_type = RW;        # Access permissions
        Squash = No_root_squash; # To enable/disable root squashing
        Disable_ACL = TRUE;      # To enable/disable ACL
        # Mandatory if using nfsV4
        Pseudo = "/musicdata";        # NFSv4 pseudo path for this export. Eg: "/test_volume_pseudo"
        Protocols = 3,4 ;        # NFS protocols supported
        #Sectype = sys,krb5,krb5i,krb5p;
        SecType = "sys";         # Security flavors supported
}

Enregistrer les changements, puis recharger la configuration NFS : systemctl reload nfs-ganesha

Vérifier que le volume soit bien exporté par le service NFS : showmount -e localhost :

root@mytestserver1:~#showmount -e localhost
Export list for localhost:
musicdata (everyone)

Si vous rencontrez un problème, vérifiez les logs du service nfs-ganesha : cat /var/log/ganesha/ganesha.log ou tail -f /var/log/ganesha/ganesha.log …

Test de montage d’un volume NFS sur un des “Workers” du Cluster Kubernetes

  • Connectez-vous “root” à un des “Workers” de votre cluster, créer un point de montage : mkdir /test-nfs

  • Assurez-vous que le serveur dispose du package “nfs-common” : apt install -y nfs-common, dans les cas contraire les Pods ne pourront pas monter ce type de volume…

  • Installer le package Debian nfs client : apt install nfs-common

  • Connectez l’export NFS : mount -t nfs [Ip Addr or hostname - Gluster NFS server]:/[export volume name] /test-nfs

    • Exemple avec mon serveur GlusterFS-NFS :

      • ip Addr : 192.168.1.1

      • hostname : mynfsserver.mylocaldomain

      • exported gluster nfs volume name : musicdata

        • Par adresse IP : mount -t nfs 192.168.1.1:/musicdata /test-nfs
        • Par Hostname : mount -t nfs mynfsserver.mylocaldomain:/musicdata /test-nfs

  • Vérifier le montage: ls /test-nfs/

Tout est Ok, on nettoie :

umount /test-nfs
rmdir /test-nfs
  • Installer le package Debian ’nfs-common’ sur tous vos workers Kubernetes.

Applications Kubernetes : Remplacement des “Persistent Volumes GlusterFS” par des “Persistent Volumes NFS”

L’utilisation des ressources dans un cluster Kubernetes est liée à votre “manifest” de déploiement. Ce dernier indique le type des volumes à utiliser.
Avec Gluster, nous avions besoin d’un service spécifique, il n’est maintenant plus nécessaire, la conversion Gluster vers nfs s’opère au niveau des “kind PersistentVolume” , remplacez “glusterfs” par “nfs” et adapter ses attributs : “endpoints” par “server”, et le la valeur de “path” doit toujours être indiqué en chemin absolu.

Avec Gluster

## Gluster service
apiVersion: "v1"
kind: "Service"
metadata:
  name: "glusterfs-cluster"
  namespace: "mynamespace"
spec:
  ports:
    - port: 1
---
apiVersion: "v1"
kind: "Endpoints"
metadata:
  name: "glusterfs-cluster"
  namespace: "mynamespace"
subsets:
  - addresses:
      - ip: "[Gluster Server Ip address]"
    ports:
      - port: 1
---
apiVersion: "v1"
kind: "PersistentVolume"
metadata:
  name: "gluster-pv-mynamespace-data"
spec:
  ## volume could only be used by namespace mynamespace
  claimRef:
    name: "claimref-gluster-pv-mynamespace-data"
    namespace: "mynamespace"
  capacity:
    storage: "8Gi"
  accessModes:
    - "ReadWriteOnce"
  storageClassName: ""
  glusterfs:
    endpoints: "glusterfs-cluster"
    path: "mynamespace-data"
    readOnly: false

Avec NFS

## With Nfs no endpoint service needed
apiVersion: "v1"
kind: "PersistentVolume"
metadata:
  name: "nfs-pv-mynamespace-data"
spec:
  ## volume could only be used by namespace mynamespace
  claimRef:
    name: "claimref-nfs-pv-mynamespace-data"
    namespace: "mynamespace"
  capacity:
    storage: "8Gi"
  accessModes:
    - "ReadWriteOnce"
  storageClassName: ""
  # replace glusterfs with nfs, put the Gluster NFS server Ip address or Hostname, prefix path value with "/"
  nfs:
    server: "[NFS-Ganesha Server Ip address | hostname]"
    # Warn path must be absolute
    path: "/mstream-data"
    readOnly: false

Concernant cette transformation et pour disposer d’une compatibilité maximum entre les “manifests”, tous les volumes exportés via NFS, portent le même nom que les volumes Gluster indiqués dans les “manifests” originaux.

Résumé des étapes pour la migration Kubernetes 1.27

  • Installer nfs-ganesha sur le serveur Gluster
  • Exporter les volumes utilisés par les applications installées dans le cluster Kubernetes
  • Pour chacune des applications installées dans le cluster Kubernetes, tester d’abord sur une application non critique..
    • Pour éviter les surprises, ne touchez jamais en direct les paramètres des applications dans Kubernetes, sans répercuter ces changements dans vos “manifests”. Pour réinstaller complètement une application, il suffit de supprimer le “namespace” et d’appliquer le nouveau “manifest” :
      • Suppression de l’application (kubectl delete -f [my manifest])
      • Modification du “manifest” (changements liés à l’utilisation du service NFS)
      • Application du “manifest” (kubectl apply -f [my manifest])
      • Enregistrement du “manifest” dans un dépôt “git”…

Auto-provisioner NFS-Ganesha

Si vous souhaitez utiliser un mécanisme “auto provisioning” par StorageClass, Voir la doc pour nfs-ganesha ici

+++

(*) Image Rendering Powered by
Hugo Easy Gallery