Les Volumes Sur Kubernetes

 

Vue conceptuelle d’un volume persistant Kubernetes avec Manifest YAML et modes d’accès

Introduction

Kubernetes est devenu un standard incontournable pour orchestrer les conteneurs dans des environnements cloud ou locaux. Une composante essentielle dans la gestion d’applications distribuées est le stockage persistant. Pour cela, Kubernetes utilise les Persistent Volumes (PV) et les Persistent Volume Claims (PVC). Cet article explicite ces concepts, leur configuration via manifests YAML, ainsi que les différents modes d’accès et types de PV, illustrés par des images explicatives.

Définitions : PV et PVC

Persistent Volume (PV)

Un Persistent Volume est une ressource de stockage dans le cluster Kubernetes, abstraite du stockage physique sous-jacent (disque local, réseau, cloud, etc.). Il est provisionné par l’administrateur ou dynamiquement via un StorageClass.

À retenir : Le PV est un volume de stockage indépendant du cycle de vie des pods. Il existe indépendamment et peut être réclamé par un ou plusieurs pods.

Persistent Volume Claim (PVC)

Le Persistent Volume Claim est une requête d’un utilisateur ou d’un pod pour un volume avec certaines spécifications (taille, access mode, etc.). Kubernetes associe automatiquement un PV compatible à la PVC.

Manifest YAML : Exemple et explications

Exemple de définition d’un Persistent Volume (PV)

apiVersion: v1
kind: PersistentVolume
metadata:
  name: pv-example
spec:
  capacity:
    storage: 5Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  hostPath:
    path: /mnt/data

Ici, un PV de 5 gigaoctets est défini, accessible en lecture/écriture par un seul nœud (ReadWriteOnce), utilisant un dossier local (hostPath).

Exemple de définition d’un Persistent Volume Claim (PVC)

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: pvc-example
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 5Gi

Ce manifest réclame un volume avec 5 Gi de stockage et le même mode d’accès ReadWriteOnce, que Kubernetes associera à un PV adéquat.

Modes d’accès aux Persistent Volumes

Les modes d’accès définissent comment un volume persistant peut être monté et utilisé par les pods.

  • ReadWriteOnce (RWO) : Le volume peut être monté pour lecture/écriture par un seul noeud à la fois.
  • ReadOnlyMany (ROX) : Le volume peut être monté en lecture seule par plusieurs noeuds simultanément.
  • ReadWriteMany (RWX) : Le volume peut être monté pour lecture/écriture par plusieurs noeuds en même temps.
Illustration des modes d’accès PV dans Kubernetes

Le choix du mode d’accès impacte la manière dont les applications peuvent partager les données et la disponibilité du volume dans un cluster.

Types de Persistent Volumes

Selon le type d’infrastructure, les PV peuvent correspondre à différents backends de stockage. Voici les principaux types :

  • hostPath : volume monté directement depuis un chemin local du nœud. Utile en développement local ou test.
  • NFS (Network File System) : permet le partage de fichiers via réseau, supportant RWX.
  • Cloud Providers : volumes dynamiques comme EBS pour AWS, Persistent Disk pour GCP, Azure Disk, etc.
  • Ceph, GlusterFS, iSCSI : solutions de stockage en réseau avancées, souvent utilisées pour de gros clusters.