Ku­ber­netes per­sis­tent volume : notre tutoriel

Les Ku­ber­netes per­sis­tent volumes (PVs) jouent un rôle crucial dans la gestion efficace des données dans les clusters Ku­ber­netes. Ils rendent les données abs­traites et per­met­tent un stockage cohérent tout au long du cycle de vie des pods.

Un Ku­ber­netes per­sis­tent volume, c’est quoi ?

Un Ku­ber­netes per­sis­tent volume (PV) est une ressource fon­da­men­tale au sein de l’or­ches­tra­tion Ku­ber­netes, conçue pour une gestion efficace et évolutive des données dans les clusters de con­te­neurs. L’objectif d’un PV est de fournir une zone de stockage stan­dar­di­sée et per­sis­tante. Un PV peut être utilisé par dif­fé­rents pods, in­dé­pen­dam­ment des res­sources de stockage physiques aux­quelles le cluster a accès. Cela crée un niveau d’abs­trac­tion plus élevé en séparant les détails de stockage de la logique de l’ap­pli­ca­tion.

Les volumes per­sis­tants (PV) existent sous forme statique et dynamique. Le pro­vi­sion­ne­ment statique signifie que les res­sources de stockage sont pré­dé­fi­nies ma­nuel­le­ment, tandis que dans le cas du pro­vi­sion­ne­ment dynamique, les PV sont créés au­to­ma­ti­que­ment dès qu’un pod a des besoins de stockage spé­ci­fiques. Cette souplesse permet de gérer avec ef­fi­ca­cité les données per­sis­tantes dans les clusters Ku­ber­netes, ce qui rend les ap­pli­ca­tions robustes et évo­lu­tives.

Quelle est la dif­fé­rence entre un volume et un volume per­sis­tant (PV) ?

Dans Ku­ber­netes, il y a deux types prin­ci­paux de volumes de stockage : les volumes et les volumes per­sis­tants. Un volume standard est lié à la durée de vie d’un seul pod. Il est déclaré di­rec­te­ment dans la con­fi­gu­ra­tion du pod et sert prin­ci­pa­le­ment à stocker tem­po­rai­re­ment 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 sup­pri­mées, libérant ainsi le volume.

En revanche, un Ku­ber­netes per­sis­tent volume a une durée de vie plus longue et est in­dé­pen­dant d’un pod spé­ci­fique. Il peut être sollicité et libéré par plusieurs pods dans dif­fé­rents cycles de vie. Les per­sis­tent volumes sont déclarés sé­pa­ré­ment des pods et sont ensuite couplés à des demandes de volume per­sis­tant (PVC, per­sis­tent volume claims). La liaison entre une PVC et un PV se fait de façon dynamique ou manuelle. Les volumes per­sis­tants sont parfaits pour les données qui doivent persister au-delà de la durée de vie d’un seul pod et per­met­tent de partager et de stocker des données entre dif­fé­rents pods, même lorsque des pods sont créés ou supprimés.

Quels sont les dif­fé­rents types de volumes per­sis­tants ?

Il y a dif­fé­rents types de Ku­ber­netes per­sis­tent volumes qui re­pré­sen­tent dif­fé­rentes solutions et tech­no­lo­gies de stockage. Voici quelques-uns des types de volumes per­sis­tants les plus courants :

• hostPath : le type hostPath lie un volume per­sis­tant à un chemin sur le nœud hôte dans le cluster Ku­ber­netes. Cela permet d’accéder aux res­sources de stockage locales de l’hôte et convient bien aux en­vi­ron­ne­ments de dé­ve­lop­pe­ment et de test. Cependant, il doit être utilisé avec prudence dans les en­vi­ron­ne­ments de pro­duc­tion, car les données ne sont pas ré­pli­quées entre les nœuds.
• emptyDir : le type emptyDir crée un volume tem­po­raire vide à chaque fois qu’un pod est créé. Il est utile pour les données tem­po­raires ou l’échange de données entre con­te­neurs 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 per­sis­tant Ku­ber­netes à des solutions de stockage externes dans le Cloud, comme Google Compute Engine Per­sis­tent Disks, Amazon EBS Volumes ou Azure Disks et Azure File Shares. Ils offrent la pos­si­bi­lité de conserver des données au-delà des pods et même des clusters, et sont bien adaptés aux ap­pli­ca­tions mises à dis­po­si­tion dans les en­vi­ron­ne­ments Cloud.
• NFS (Network File System) : les PV de type NFS se con­nec­tent à un partage réseau fourni par le Network File System (NFS). Cela permet de partager des données entre dif­fé­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 con­nec­tent à des pé­ri­phé­riques bloc de stockage dis­po­nibles via le protocole iSCSI. C’est un moyen d’utiliser des pé­ri­phé­riques de stockage externes en mode bloc dans les clusters Ku­ber­netes et offre une solution souple et évolutive pour les données per­sis­tantes.
• local : le type local permet d’accéder di­rec­te­ment aux res­sources de stockage physiques sur le nœud local dans le cluster Ku­ber­netes. Ceci est par­ti­cu­liè­re­ment utile pour les ap­pli­ca­tions qui ont besoin d’un stockage local rapide. Il convient toutefois d’être prudent, car les res­sources de stockage local ne sont pas ré­pli­quées entre les nœuds et des données peuvent être perdues en cas de dé­fail­lance du nœud.
• CSI (Container Storage Interface) : le type CSI permet d’intégrer des four­nis­seurs de stockage externes via l’interface Container Storage. Les systèmes d’or­ches­tra­tion de con­te­neurs comme Ku­ber­netes peuvent ainsi com­mu­ni­quer avec dif­fé­rentes solutions de stockage de four­nis­seurs tiers. Cela offre de la souplesse et permet d’utiliser un large éventail de systèmes de stockage com­pa­tibles avec l’interface CSI.
• CephFS : CephFS est un système de fichiers distribué, et ses volumes per­sis­tants de type CephFS sont liés à ce système de fichiers distribué. Ce type de PV est utilisé pour les ap­pli­ca­tions qui ont besoin d’un accès partagé aux fichiers et qui fonc­tion­nent dans un en­vi­ron­ne­ment de stockage distribué, comme c’est le cas pour Ceph.
• FC (Fibre Channel) : les volumes per­sis­tants basés sur le type FC sont liés à des pé­ri­phé­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 en­vi­ron­ne­ments 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é­ri­phé­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 par­ti­cu­liè­re­ment utile dans les en­vi­ron­ne­ments de stockage dis­tri­bués à forte évo­lu­ti­vité.

Modes d’accès au Ku­ber­netes per­sis­tent volume

Dans Ku­ber­netes, les modes d’accès aux volumes per­sis­tants dé­ter­mi­nent la façon dont les pods peuvent accéder aux volumes per­sis­tants qui leur sont rattachés. On distingue trois types prin­ci­paux de modes d’accès :

• ReadWriteOnce (RWO) : ce mode permet à un seul pod de monter le volume per­sis­tant en mode lecture et écriture si­mul­ta­né­ment. Il est utile pour les ap­pli­ca­tions 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 si­mul­ta­né­ment le volume per­sis­tant en mode d’accès lecture. Ceci est utile pour les ap­pli­ca­tions 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 uni­que­ment en mode lecture.
• ReadWriteMany (RWX) : ReadWriteMany permet à plusieurs pods de monter le volume per­sis­tant si­mul­ta­né­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é­fi­nis­sant le mode d’accès, il convient de prendre en compte le type d’accès aux données de votre ap­pli­ca­tion et de vérifier que le mode choisi est com­pa­tible avec les modèles d’accès requis.

Veuillez noter que pas tous les types de volumes et classes de stockage sont com­pa­tibles avec tous les trois modes d’accès. La prise en charge dépend de l’in­fras­truc­ture de stockage sous-jacente et du type de volume per­sis­tant donné. Il est donc conseillé de consulter la do­cu­men­ta­tion de chaque classe de stockage et de chaque type de volume per­sis­tant pour s’assurer que les modèles d’accès souhaités sont autorisés.

Cycle de vie d’un volume per­sis­tant (PV)

Les cycles de vie des Ku­ber­netes per­sis­tent volumes peuvent être divisés en plusieurs phases qui re­pré­sen­tent le processus de pro­vi­sion­ne­ment, d’uti­li­sa­tion et de li­bé­ra­tion du stockage per­sis­tant dans le cluster.

1. Pro­vi­sion­ne­ment : le cycle de vie d’un PV commence par sa création, ou plus pré­ci­sé­ment, par son pro­vi­sion­ne­ment. Un ad­mi­nis­tra­teur de cluster crée un volume per­sis­tant et le configure soit de manière statique avec des res­sources de stockage fixes, soit de manière dynamique en utilisant une classe de stockage (Storage Class) qui permet un pro­vi­sion­ne­ment dynamique.
2. Liaison (Binding) : un PV est lié à une demande de volume per­sis­tant (PVC) lorsqu’un pod fait part d’un besoin de stockage qui cor­res­pond aux spé­ci­fi­ca­tions du PV. Cette étape permet de s’assurer que le PV est conforme aux exigences d’un pod donné.
3. Uti­li­sa­tion 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 Ex­pi­ra­tion de l’uti­li­sa­tion : 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é ma­nuel­le­ment ou par une classe de stockage dynamique.
4. Li­bé­ra­tion (Release) : un PV peut être ex­pli­ci­te­ment libéré en le séparant d’une demande de PV. Ainsi, le PV est dis­po­nible pour une autre liaison, éven­tuel­le­ment via une autre PVC ou un pod.
5. Sup­pres­sion (Delete) : enfin, il est également possible de supprimer un PV lorsqu’il n’est plus utilisé. Cela peut se faire ma­nuel­le­ment ou au­to­ma­ti­que­ment si la ré­pli­ca­tion du PV est con­fi­gu­rée par la classe de stockage.

Créer un Ku­ber­netes per­sis­tent volume

La création d’un volume per­sis­tant dans Ku­ber­netes est un processus à plusieurs étapes qui requiert une con­fi­gu­ra­tion mi­nu­tieuse.

Étape 1 : con­fi­gu­ra­tion du volume per­sis­tant

La première étape consiste à ouvrir un éditeur de texte et à créer un fichier YAML contenant la con­fi­gu­ra­tion du Ku­ber­netes Per­sis­tent Volume. Ce fichier peut par exemple être appelé pv.yaml. Trouvez, ci-après, un exemple simple de con­fi­gu­ra­tion 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 Ku­ber­netes (Ici : v1).
• kind : le type de l’objet Ku­ber­netes, dans ce cas PersistentVolume.
• metadata : contient des mé­ta­don­nées pour le volume per­sis­tant, par exemple, le nom du volume. spec : définit la spé­ci­fi­ca­tion 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é ma­nuel­le­ment.
• storageClassName : attribue une classe de stockage au volume per­sis­tant.
• hostPath : définit le chemin dans le système de fichiers hôte pour le stockage du volume per­sis­tant.

Étape 2 : ap­pli­ca­tion de la con­fi­gu­ra­tion

Après avoir décrit le fichier de con­fi­gu­ra­tion PV, vous pouvez l’activer avec Kubelet :

kubectl apply -f pv.yaml

Cette commande envoie le fichier de con­fi­gu­ra­tion au cluster Ku­ber­netes qui crée les res­sources qu’il contient.

Étape 3 : lister les volumes per­sis­tants du cluster

Pour vérifier que le Ku­ber­netes per­sis­tent volume a bien été créé, utilisez la commande suivante :

kubectl get pv

Ceci dresse la liste de tous les volumes per­sis­tants 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 per­sis­tant (PVC)

Rem­plis­sez un fichier YAML pour définir la con­fi­gu­ra­tion de la demande de volume per­sis­tant :

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

Appliquez le fichier de con­fi­gu­ra­tion PVC au cluster Ku­ber­netes :

kubectl apply -f pvc.yaml

Vérifiez que la demande de volume per­sis­tant a bien été créée et utilisez la commande suivante :

kubectl get pvc

Le résultat devrait res­sem­bler à ceci :

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

Nous créons main­te­nant le manifest YAML pvc-dynamic.yaml pour démontrer le pro­vi­sion­ne­ment dynamique d’une demande de volume per­sis­tant (PVC) dans Ku­ber­netes. Le manifest crée et re­ven­dique au­to­ma­ti­que­ment un nouveau Ku­ber­netes per­sis­tent 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 con­fi­gu­ra­tions 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 con­fi­gu­rer le pod qui utilisera le stockage per­sis­tant.

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 con­fi­gu­ra­tion du pod au cluster Ku­ber­netes pour créer le pod :

kubectl apply -f pod.yaml

Si vous commencez tout juste à découvrir Ku­ber­netes, vous trouverez toutes les in­for­ma­tions utiles sur l’ins­tal­la­tion et la con­fi­gu­ra­tion d’un cluster dans le tutoriel Ku­ber­netes de notre Digital Guide.