L’une des problématiques connues lors de l’utilisation des solutions de stockage persistant dans Kubernetes, comme GlusterFS, est de toucher les limites de stockage dans votre cluster. Vous devez trouvez un moyen simple pour augmenter votre capacité de stockage, sans perdre les données existantes. Dans cet article, je vais vous montrer deux façon pour le faire.
Avant d’aller plus loin, je vous fais une brève introduction du contexte ainsi que quelques descriptions sur le vocabulaire utilisé.
“GlusterFS est un système de fichiers évolutif et réparti qui regroupe les ressources de stockage sur disque de plusieurs serveurs dans un même espace de nom global”.
“Heketi fournit une interface de gestion RESTful qui peut être utilisée pour gérer le cycle de vie des volumes GlusterFS.”
Topology.json, Heketi utilise ce fichier de configuration pour définir la topologie des nœuds de cluster pour GlusterFS. Il contient les adresses IP des nœuds et les périphériques de stockage à utiliser dans chaque nœud.
Cela ressemble à ça :
{
"clusters": [
{
"nodes": [
{
"node": {
"hostnames": {
"manage": [
"node4"
],
"storage": [
"10.0.XX.XX"
]
},
"zone": 1
},
"devices": [
{
"name": "/dev/xvdb",
"destroydata": false
}
]
}
...
J’utilise GlusterFS et Heketi dans un cluster Kubernetes fonctionnant sur six machines EC2; trois masters/etcd et trois nodes (workers).
J’ai utilisé le projet Kubespray pour installer le cluster sur l’environnement AWS, qui a pour avantage de permettre un déploiement via Ansible des briques nécessaires au fonctionnement de Kubernetes, ce que ce soit sur AWS ou ailleurs.
Dans ce même projet, il existe également des playbooks Ansible supplémentaires que j’ai utilisé pour installer GlusterFS et la topologie Heketi. Cette dernière est lancée sur les trois nodes k8s et utilise des volumes EBS attachés aux instances EC2. Vous pouvez personnaliser cette topologie pour mieux répondre à vos besoins.
L’image ci-dessous, qui vient de ce blog, montre approximativement la configuration.
J’ai commencé avec un volume de 30GiB monté sur le device /dev/xvdb. Le cluster k8s était presque vide, juste quelques Daemonsets de supervision qui tournent et aussi quelques applications légères avec 8GiB de PersistentVolumes; tout allait bien jusqu’à ce que j’atteigne les limites. A cet instant, j’ai remarqué que les PersistentVolumeClaims étaient bloqués en état d’attente éternellement. Voici un exemple d’un pvc en attente pour le stockage S3 Minio.
minio persistentvolumeclaim/minio-pvc Pending 1d
En regardant dans les logs, je voyais un message clair en me disant qu’il ne restait plus de capacité de stockage pour démarrer le pvc.
Warning ProvisioningFailed ... Failed to provision volume with StorageClass "gluster": failed to create volume: heketi block volume creation failed: [heketi] failed to create volume: Failed to allocate new block volume: No space
J’ai utilisé deux méthodes pour augmenter la capacité de stockage :
Cette méthode suppose que vous ayez déjà un volume monté et utilisé par le cluster Heketi. Elle peut être utilisée sur sur un cloud provider qui vous offre la possibilité d’étendre les volumes à chaud, comme AWS, GCP etc.
La première étape est d'étendre votre volume (via web GUI, ligne de commande, terraform ...)
Connectez-vous en ssh à votre instance en question.
Etendez le volume physique pv, dans mon cas j’ai ajouté d’autres 30GiB
centos]# pvresize /dev/xvdb
Physical volume "/dev/xvdb" changed
1 physical volume(s) resized / 0 physical volume(s) not resized
Avant :
centos]# vgdisplay
--- Volume group ---
VG Name vg_a1751200878b2bb0a64d89a15e3bc801
VG Size 29.87 GiB
Après :
centos]# vgdisplay
--- Volume group ---
VG Name vg_a1751200878b2bb0a64d89a15e3bc801
VG Size 59.87 GiB
Maintenant il faut prévenir Heketi pour qu’il prenne en compte la nouvelle taille du volume avec Resync device. L’ensemble des commandes Heketi sont disponibles sur ce site web.
Connectez-vous à un master ou n’importe quelle machine qui a kubectl configuré et suivez les étapes suivantes :
# Récupérer le nom du pod Heketi
kubectl get pods -n kube-system | grep heketi
# Récupérer le secret Heketi pour l'accès admin afin d’utiliser l’API
kubectl get secret heketi-config-secret -n kube-system -o jsonpath --template '{.data.heketi\.json}' | base64 -d
# Lister le nom du cluster Heketi
kubectl -n kube-system exec heketi-d55cbd78c-7tj8c -n kube-system -- heketi-cli --user admin --secret XXXXXX cluster list
ClusterId: Id:65ddc905b8a32dc49db721a004a08ead
# Avoir une description détaillée du cluster Heketi
kubectl -n kube-system exec heketi-d55cbd78c-7tj8c -n kube-system -- heketi-cli --user admin --secret XXXXX cluster info 65ddc905b8a32dc49db721a004a08ead
Cluster id: 65ddc905b8a32dc49db721a004a08ead
Nodes:
310744c2908338d7d229268a4445951b
9ac5b33d03759ba7d9b161b879a4ea39
e0fd9cbad89eac2989cff2b426a59288
Volumes:
29e2a3fd578bb98a7d44e9a538cc9e74
7c955fe8dff62136046fc5c794abb6a5
b22ad96e06a4bff70c16e9fe61a4ed50
Block: true
File: true
# Avoir des informations détaillées sur un noeud, vous pouvez changer l’ID et avoir les informations sur les autres noeuds
kubectl -n kube-system exec heketi-d55cbd78c-7tj8c -n kube-system -- heketi-cli --user admin --secret XXXXX node info 9ac5b33d03759ba7d9b161b879a4ea39
Node Id: 310744c2908338d7d229268a4445951b
State: online
Cluster Id: 65ddc905b8a32dc49db721a004a08ead
Zone: 1
Management Hostname: node5
Storage Hostname: 10.0.XX.XX
Devices:
Id:a1751200878b2bb0a64d89a15e3bc801 Name:/dev/xvdb State:online Size (GiB):34 Used (GiB):22 Free (GiB):12 Bricks:3
# Maintenant on applique “Resync device”
kubectl -n kube-system exec heketi-d55cbd78c-7tj8c -n kube-system -- heketi-cli --user admin --secret XXXXX device resync a1751200878b2bb0a64d89a15e3bc801
Device updated
# Avoir les informations à jour sur le noeud 5
kubectl -n kube-system exec heketi-d55cbd78c-7tj8c -n kube-system -- heketi-cli --user admin --secret XXXXX node info 9ac5b33d03759ba7d9b161b879a4ea39
Node Id: 310744c2908338d7d229268a4445951b
State: online
Cluster Id: 65ddc905b8a32dc49db721a004a08ead
Zone: 1
Management Hostname: node5
Storage Hostname: 10.0.XX.XX
Devices:
Id:Id:a1751200878b2bb0a64d89a15e3bc801 Name:/dev/xvdb State:online Size (GiB):64 Used (GiB):22 Free (GiB):42 Bricks:3
Dans ce cas, je vais ajouter un nouveau volume dans la topologie Heketi. Cette méthode est plus adaptée si vous n’avez pas la possibilité d’augmenter la taille de votre volume existant à chaud et que vous êtes obligé d’ajouter un autre afin d’augmenter votre capacité de stockage. L’ensemble des étapes à suivre sont inspirés du site IBM.
Veuillez noter que le volume doit être démonté et vide, ni une partition ni un système de fichiers ne doivent être créés, afin que Heketi puisse l’utiliser.
Créez et attachez le volume à votre instance, par exemple : /dev/xvdc
Vous pouvez assurer que votre volume est bien propre avec :
wipefs --all --force /dev/xvdc
Connectez-vous à un master ou n’importe quelle machine qui a kubectl configuré.
Cette étape de la précédente méthode est optionnelle, je l’utilise seulement pour avoir plus de visibilité sur ce qui se passe, c’est également un petit rappel pour les gens qui utilisent la deuxième méthode.
Récupérer le nom du pod Heketi
Récupérer le secret Heketi pour l'accès admin
Lister le nom du cluster Heketi
Avoir une description détaillée du cluster Heketi
Avoir des informations détaillées sur un noeud
Ajoutez le volume dans la topologie Heketi :
# Afin d’ajouter le volume, il faut utiliser le volume ID que vous avez obtenu avec la commande heketi cluster info
kubectl -n kube-system exec heketi-d55cbd78c-7tj8c -- heketi-cli --user admin --secret XXXXX device add --name=/dev/xvdc --node=e0fd9cbad89eac2989cff2b426a59288
Device added successfully
Avant :
kubectl -n kube-system exec heketi-d55cbd78c-7tj8c -- heketi-cli --user admin --secret XXXXX node info 9ac5b33d03759ba7d9b161b879a4ea39
Node Id: 310744c2908338d7d229268a4445951b
State: online
Cluster Id: 65ddc905b8a32dc49db721a004a08ead
Zone: 1
Management Hostname: node5
Storage Hostname: 10.0.25.109
Devices:
Id:a1751200878b2bb0a64d89a15e3bc801 Name:/dev/xvdb State:online Size (GiB):34 Used (GiB):22 Free (GiB):12 Bricks:3
Après :
kubectl -n kube-system exec heketi-d55cbd78c-7tj8c -- heketi-cli --user admin --secret XXXXX node info 9ac5b33d03759ba7d9b161b879a4ea39
Node Id: 310744c2908338d7d229268a4445951b
State: online
Cluster Id: 65ddc905b8a32dc49db721a004a08ead
Zone: 1
Management Hostname: node5
Storage Hostname: 10.0.25.109
Devices:
Id:a1751200878b2bb0a64d89a15e3bc801 Name:/dev/xvdb
State:online Size (GiB):34 Used (GiB):22 Free (GiB):12 Bricks:3
Id:fcb295c112eb0a1bbfa9e6fca8a3f30a Name:/dev/xvdc State:online Size (GiB):59 Used (GiB):0 Free (GiB):59 Bricks:5
N’oubliez pas d’appliquer l’étape précédente sur l’ensemble des noeuds glusterFS (node4, node6 restants dans mon cas).
GlusterFS est un projet sérieux supporté par RedHat, IBM et d’autres encore. Vous pouvez l’utiliser afin de vous familiariser avec les volumes persistent dans k8S. En revanche, je ne l’ai pas testé dans un contexte de production.
J'ai utilisé les deux méthodes présentées dans cet article et elles sont fonctionnelles. Vous pouvez maintenant profiter de votre espace de stockage ! :)