Kubernetes persistent volume : notre tutoriel

Les Kubernetes persistent volumes (PVs) jouent un rôle crucial dans la gestion efficace des données dans les clusters Kubernetes. Ils rendent les données abstraites et permettent un stockage cohérent tout au long du cycle de vie des pods.

Un Kubernetes persistent volume, c’est quoi ?

Un Kubernetes persistent volume (PV) est une ressource fondamentale au sein de l’orchestration Kubernetes, conçue pour une gestion efficace et évolutive des données dans les clusters de conteneurs. L’objectif d’un PV est de fournir une zone de stockage standardisée et persistante. Un PV peut être utilisé par différents pods, indépendamment des ressources de stockage physiques auxquelles le cluster a accès. Cela crée un niveau d’abstraction plus élevé en séparant les détails de stockage de la logique de l’application.

Les volumes persistants (PV) existent sous forme statique et dynamique. Le provisionnement statique signifie que les ressources de stockage sont prédéfinies manuellement, tandis que dans le cas du provisionnement dynamique, les PV sont créés automatiquement dès qu’un pod a des besoins de stockage spécifiques. Cette souplesse permet de gérer avec efficacité les données persistantes dans les clusters Kubernetes, ce qui rend les applications robustes et évolutives.

Quelle est la différence entre un volume et un volume persistant (PV) ?

Dans Kubernetes, il y a deux types principaux de volumes de stockage : les volumes et les volumes persistants. Un volume standard est lié à la durée de vie d’un seul pod. Il est déclaré directement dans la configuration du pod et sert principalement à stocker temporairement des données pendant l’exécution du pod auquel il est associé. À l’arrêt du pod, toutes les données contenues dans le volume standard sont supprimées, libérant ainsi le volume.

En revanche, un Kubernetes persistent volume a une durée de vie plus longue et est indépendant d’un pod spécifique. Il peut être sollicité et libéré par plusieurs pods dans différents cycles de vie. Les persistent volumes sont déclarés séparément des pods et sont ensuite couplés à des demandes de volume persistant (PVC, persistent volume claims). La liaison entre une PVC et un PV se fait de façon dynamique ou manuelle. Les volumes persistants sont parfaits pour les données qui doivent persister au-delà de la durée de vie d’un seul pod et permettent de partager et de stocker des données entre différents pods, même lorsque des pods sont créés ou supprimés.

Quels sont les différents types de volumes persistants ?

Il y a différents types de Kubernetes persistent volumes qui représentent différentes solutions et technologies de stockage. Voici quelques-uns des types de volumes persistants les plus courants :

• hostPath : le type hostPath lie un volume persistant à un chemin sur le nœud hôte dans le cluster Kubernetes. Cela permet d’accéder aux ressources de stockage locales de l’hôte et convient bien aux environnements de développement et de test. Cependant, il doit être utilisé avec prudence dans les environnements de production, car les données ne sont pas répliquées entre les nœuds.
• emptyDir : le type emptyDir crée un volume temporaire vide à chaque fois qu’un pod est créé. Il est utile pour les données temporaires ou l’échange de données entre conteneurs au sein d’un même pod. Cependant, ce volume est supprimé dès que le pod est fermé.
• GCEPersistentDisk, AWSElasticBlockStore, AzureDisk, AzureFile : ces types lient un volume persistant Kubernetes à des solutions de stockage externes dans le Cloud, comme Google Compute Engine Persistent Disks, Amazon EBS Volumes ou Azure Disks et Azure File Shares. Ils offrent la possibilité de conserver des données au-delà des pods et même des clusters, et sont bien adaptés aux applications mises à disposition dans les environnements Cloud.
• NFS (Network File System) : les PV de type NFS se connectent à un partage réseau fourni par le Network File System (NFS). Cela permet de partager des données entre différents pods et s’avère pratique lorsque plusieurs pods doivent accéder à des fichiers communs.
• iSCSI (Internet Small Computer System Interface) : les PV basés sur iSCSI se connectent à des périphériques bloc de stockage disponibles via le protocole iSCSI. C’est un moyen d’utiliser des périphériques de stockage externes en mode bloc dans les clusters Kubernetes et offre une solution souple et évolutive pour les données persistantes.
• local : le type local permet d’accéder directement aux ressources de stockage physiques sur le nœud local dans le cluster Kubernetes. Ceci est particulièrement utile pour les applications qui ont besoin d’un stockage local rapide. Il convient toutefois d’être prudent, car les ressources de stockage local ne sont pas répliquées entre les nœuds et des données peuvent être perdues en cas de défaillance du nœud.
• CSI (Container Storage Interface) : le type CSI permet d’intégrer des fournisseurs de stockage externes via l’interface Container Storage. Les systèmes d’orchestration de conteneurs comme Kubernetes peuvent ainsi communiquer avec différentes solutions de stockage de fournisseurs tiers. Cela offre de la souplesse et permet d’utiliser un large éventail de systèmes de stockage compatibles avec l’interface CSI.
• CephFS : CephFS est un système de fichiers distribué, et ses volumes persistants de type CephFS sont liés à ce système de fichiers distribué. Ce type de PV est utilisé pour les applications qui ont besoin d’un accès partagé aux fichiers et qui fonctionnent dans un environnement de stockage distribué, comme c’est le cas pour Ceph.
• FC (Fibre Channel) : les volumes persistants basés sur le type FC sont liés à des périphériques de stockage Fibre Channel. Ce type de PV permet d’accéder à des solutions de stockage externes basées sur Fibre Channel. Il est courant dans les environnements qui utilisent des réseaux Fibre Channel pour fournir du stockage en mode bloc.
• RBD (RADOS Block Device) : le type RBD se connecte aux périphériques de stockage en mode bloc dans le cluster Ceph, qui agissent en tant que RADOS Block Devices. Ce type permet d’accéder au système de stockage en mode bloc de Ceph, ce qui est particulièrement utile dans les environnements de stockage distribués à forte évolutivité.

Modes d’accès au Kubernetes persistent volume

Dans Kubernetes, les modes d’accès aux volumes persistants déterminent la façon dont les pods peuvent accéder aux volumes persistants qui leur sont rattachés. On distingue trois types principaux de modes d’accès :

• ReadWriteOnce (RWO) : ce mode permet à un seul pod de monter le volume persistant en mode lecture et écriture simultanément. Il est utile pour les applications qui ont besoin d’un contrôle d’accès exclusif en écriture. Un PV avec ce mode d’accès ne peut être monté que par un seul pod à la fois.
• ReadOnlyMany (ROX) : ReadOnlyMany permet à plusieurs pods de monter simultanément le volume persistant en mode d’accès lecture. Ceci est utile pour les applications qui peuvent partager des données avec un mode commun dans lequel les accès en écriture sont toutefois limités. Plusieurs pods peuvent accéder aux données en parallèle, mais uniquement en mode lecture.
• ReadWriteMany (RWX) : ReadWriteMany permet à plusieurs pods de monter le volume persistant simultanément en mode lecture et en mode écriture. Ce mode est utilisé dans les cas où une base de données commune est requise et où plusieurs pods peuvent avoir un accès en écriture aux données.

En définissant le mode d’accès, il convient de prendre en compte le type d’accès aux données de votre application et de vérifier que le mode choisi est compatible avec les modèles d’accès requis.

Veuillez noter que pas tous les types de volumes et classes de stockage sont compatibles avec tous les trois modes d’accès. La prise en charge dépend de l’infrastructure de stockage sous-jacente et du type de volume persistant donné. Il est donc conseillé de consulter la documentation de chaque classe de stockage et de chaque type de volume persistant pour s’assurer que les modèles d’accès souhaités sont autorisés.

Cycle de vie d’un volume persistant (PV)

Les cycles de vie des Kubernetes persistent volumes peuvent être divisés en plusieurs phases qui représentent le processus de provisionnement, d’utilisation et de libération du stockage persistant dans le cluster.

1. Provisionnement : le cycle de vie d’un PV commence par sa création, ou plus précisément, par son provisionnement. Un administrateur de cluster crée un volume persistant et le configure soit de manière statique avec des ressources de stockage fixes, soit de manière dynamique en utilisant une classe de stockage (Storage Class) qui permet un provisionnement dynamique.
2. Liaison (Binding) : un PV est lié à une demande de volume persistant (PVC) lorsqu’un pod fait part d’un besoin de stockage qui correspond aux spécifications du PV. Cette étape permet de s’assurer que le PV est conforme aux exigences d’un pod donné.
3. Utilisation par le pod : lorsque le processus de liaison est terminé, le PV peut être utilisé par un pod. Le pod peut lire ou écrire sur le volume monté, en fonction des modes d’accès définis lors de la création du PV. 4 Expiration de l’utilisation : lorsqu’un pod cesse son service ou est supprimé, le PV qui lui est associé peut être réutilisé par un autre pod. Le PV est conservé jusqu’à ce qu’il soit supprimé manuellement ou par une classe de stockage dynamique.
4. Libération (Release) : un PV peut être explicitement libéré en le séparant d’une demande de PV. Ainsi, le PV est disponible pour une autre liaison, éventuellement via une autre PVC ou un pod.
5. Suppression (Delete) : enfin, il est également possible de supprimer un PV lorsqu’il n’est plus utilisé. Cela peut se faire manuellement ou automatiquement si la réplication du PV est configurée par la classe de stockage.

Créer un Kubernetes persistent volume

La création d’un volume persistant dans Kubernetes est un processus à plusieurs étapes qui requiert une configuration minutieuse.

Étape 1 : configuration du volume persistant

La première étape consiste à ouvrir un éditeur de texte et à créer un fichier YAML contenant la configuration du Kubernetes Persistent Volume. Ce fichier peut par exemple être appelé pv.yaml. Trouvez, ci-après, un exemple simple de configuration PV :

apiVersion: v1
kind: PersistentVolume
metadata:
    name: my-pv
spec:
    capacity:
        storage: 1Gi
    volumeMode: Filesystem
    accessModes:
        - ReadWriteOnce
    persistentVolumeReclaimPolicy: Retain
    storageClassName: manual
    hostPath:
        path: "/mnt/data"

• apiVersion : indique la version de l’API Kubernetes (Ici : v1).
• kind : le type de l’objet Kubernetes, dans ce cas PersistentVolume.
• metadata : contient des métadonnées pour le volume persistant, par exemple, le nom du volume. spec : définit la spécification du volume.
• capacity : indique la capacité de stockage (ici : 1 Go).
• volumeMode : indique le mode du volume, soit Filesystem (système de fichiers) soit Bloc. Dans cet exemple, il s’agit de Filesystem.
• accessModes : définit les modes d’accès. Ici, ReadWriteOnce pour un accès exclusif en lecture et en écriture.
• persistentVolumeReclaimPolicy : indique comment le volume doit être traité lorsqu’il n’est plus sollicité. Retain signifie que le volume doit être supprimé manuellement.
• storageClassName : attribue une classe de stockage au volume persistant.
• hostPath : définit le chemin dans le système de fichiers hôte pour le stockage du volume persistant.

Étape 2 : application de la configuration

Après avoir décrit le fichier de configuration PV, vous pouvez l’activer avec Kubelet :

kubectl apply -f pv.yaml

Cette commande envoie le fichier de configuration au cluster Kubernetes qui crée les ressources qu’il contient.

Étape 3 : lister les volumes persistants du cluster

Pour vérifier que le Kubernetes persistent volume a bien été créé, utilisez la commande suivante :

kubectl get pv

Ceci dresse la liste de tous les volumes persistants existants dans le cluster.

NAME   CAPACITY  ACCESS MODES  RECLAIM POLICY  STATUS  CLAIM  STORAGECLASS  REASON  AGE
my-pv    1Gi          RWO          Retain     Available           manual             1h

Étape 4 : créer une demande de volume persistant (PVC)

Remplissez un fichier YAML pour définir la configuration de la demande de volume persistant :

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
    name: my-pvc
spec:
    accessModes:
        - ReadWriteOnce
    resources:
        requests:
            storage: 1Gi
    storageClassName: manual

Appliquez le fichier de configuration PVC au cluster Kubernetes :

kubectl apply -f pvc.yaml

Vérifiez que la demande de volume persistant a bien été créée et utilisez la commande suivante :

kubectl get pvc

Le résultat devrait ressembler à ceci :

NAME      STATUS   VOLUME   CAPACITY   ACCESS MODES   STORAGECLASS   AGE
my-pvc     Bound    my-pv     1Gi           RWO          manual       1m

Nous créons maintenant le manifest YAML pvc-dynamic.yaml pour démontrer le provisionnement dynamique d’une demande de volume persistant (PVC) dans Kubernetes. Le manifest crée et revendique automatiquement un nouveau Kubernetes persistent volume d’une taille de 1 Go, pris en charge par la classe de stockage standard.

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
    name: pvc-dynamic
spec:
    accessModes:
        - ReadWriteOnce
    resources:
        requests:
            storage: 1Gi
    storageClassName: standard

Une fois les configurations définies, activez le fichier manifest :

kubectl apply -f pvc-dynamic.yaml

Étape 5 : relier les PVC aux pods

Pour coupler le PVC et le pod, il faut configurer le pod qui utilisera le stockage persistant.

apiVersion: v1
kind: Pod
metadata:
    name: mypod
spec:
    volumes:
    - name: mypvc-volume
        persistentVolumeClaim:
            claimName: my-pvc
    containers:
    - name: mycontainer
        image: myimage
        volumeMounts:
        - mountPath: "/app/data"
            name: mypvc-volume

Appliquer la configuration du pod au cluster Kubernetes pour créer le pod :

kubectl apply -f pod.yaml

Si vous commencez tout juste à découvrir Kubernetes, vous trouverez toutes les informations utiles sur l’installation et la configuration d’un cluster dans le tutoriel Kubernetes de notre Digital Guide.