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
- Arrêter le service nfs (si existant) :
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
- Par adresse IP :
-
-
-
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”…
- Suppression de l’application (
- 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” :
Auto-provisioner NFS-Ganesha
Si vous souhaitez utiliser un mécanisme “auto provisioning” par StorageClass, Voir la doc pour nfs-ganesha ici
+++