Augmenter la capacité de volume glusterFS dans Kubernetes

Augmenter la capacité de volume glusterFS dans Kubernetes

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.
glusterkube-1

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

Prêt à mettre les mains dans le cambouis

J’ai utilisé deux méthodes pour augmenter la capacité de stockage :

  • Etendre le volume attaché aux VM.
  • Ajouter un autre device de stockage (exemple: /dev/xvdc) à la topologie Heketi.

1. Etendre le volume

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
  1. Une fois le resync est appliqué, vous pouvez vérifier à nouveau pour voir ce qui a été changé.
# 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
  1. Finalement, n’oubliez pas d’appliquer le resync sur l’ensemble des noeuds GlusterFS (node4 et node6 dans mon cas).
    Et voilà, vous venez juste d’augmenter la capacité de stockage de votre cluster.

2. Ajouter un autre volume dans la topologie Heketi

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).

Conclusion

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 ! :)