Docs
Kubernetes
Le stockage PV & PVC

Le stockage PV & PVC

ÉlémentDescription
PersistentVolume (PV)Représente une ressource de stockage dans le cluster, pouvant être basée sur un disque physique ou un service cloud.
PersistentVolumeClaim (PVC)Demande un volume de stockage avec des caractéristiques spécifiques, telles que la taille et le mode d’accès.
Association PV-PVCLorsqu’un PVC est créé, Kubernetes assigne un PV disponible correspondant à la demande du PVC.
Accès au stockageLe PVC est monté dans un Pod, ce qui permet au Pod d’accéder au volume persistant, garantissant la persistance des données.

Persistent Volume (PV)

Un Persistent Volume (PV) est une ressource dans Kubernetes qui représente un espace de stockage disponible dans le cluster.
Il s’agit d’une abstraction permettant de découpler l’utilisation du stockage physique du déploiement des applications. Les PV peuvent être basés sur un stockage local, un disque réseau, ou même sur des services de stockage cloud tels que AWS EBS ou GCP Persistent Disk.

  • Les PV sont créés par les administrateurs du cluster.
  • Le PV est indépendant des Pods et peut être réutilisé entre différentes applications ou Pods.
  • Le PV possède une durée de vie distincte de celle des Pods, ce qui permet de conserver les données persistantes même après le redémarrage ou la suppression des Pods.
  • Les PV peuvent être dynamique ou statique. Le stockage dynamique est alloué automatiquement lorsqu’un utilisateur en fait la demande via un PVC.

Exemple d’un Persistent Volume :

apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-pv
spec:
  capacity:
    storage: 10Gi
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: standard
  hostPath:
    path: /data

Dans cet exemple :

  • capacity: définit la taille du volume (ici, 10 Go).
  • accessModes: indique les modes d’accès possibles (par exemple, ReadWriteOnce signifie qu’un seul Pod peut avoir un accès en lecture et écriture à ce volume à la fois).
  • persistentVolumeReclaimPolicy: détermine ce qui arrive au PV une fois le PVC associé supprimé (ici, Retain signifie que le volume ne sera pas supprimé).
  • hostPath: spécifie l’emplacement du stockage sur un disque local pour des clusters non cloud.

Persistent Volume Claim (PVC)

Un Persistent Volume Claim (PVC) est une demande pour un volume de stockage dans Kubernetes. Contrairement au PV, le PVC est une ressource créée par l’utilisateur ou l’application qui souhaite obtenir du stockage.
Le PVC spécifie les caractéristiques du stockage désiré, comme la taille et les modes d’accès.

  • Le PVC est créé par les utilisateurs ou les applications qui souhaitent utiliser un volume de stockage.
  • Le PVC peut être associé à un PV existant qui correspond à ses critères (taille, mode d’accès, etc.). Kubernetes peut également allouer un PV dynamique si aucun PV disponible ne correspond à la demande.
  • Le PVC est lié à un Pod, permettant à ce dernier d’accéder au stockage persistant.

Exemple de Persistent Volume Claim :

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

Dans cet exemple :

  • accessModes: indique le mode d’accès demandé pour ce volume.
  • resources.requests.storage: spécifie la capacité du volume demandée (ici, 10 Go).

Les Acces Mode

Comparatif

Access ModeDescriptionExemples d’utilisation
ReadWriteOnce (RWO)Permet un montage en lecture-écriture par un seul Pod à la fois.Base de données SQL, applications avec accès exclusif.
ReadOnlyMany (ROX)Permet un montage en lecture seule par plusieurs Pods.Fichiers de configuration partagés, fichiers statiques.
ReadWriteMany (RWX)Permet un montage en lecture-écriture par plusieurs Pods.Stockage partagé entre plusieurs Pods, systèmes de gestion de fichiers.

Choisir le bon Access Mode

Le choix de l’Access Mode dépend du cas d’usage spécifique :

  • Si une application doit accéder à un volume de manière exclusive (comme une base de données), il est préférable d’utiliser ReadWriteOnce (RWO).
  • Si plusieurs Pods doivent lire des fichiers sans les modifier (comme des fichiers de configuration ou des ressources statiques), ReadOnlyMany (ROX) peut être utilisé.
  • Si plusieurs Pods doivent non seulement lire mais aussi écrire sur le même volume, ReadWriteMany (RWX) sera le mode le plus approprié, mais il est plus limité en termes de types de stockage supportés.
Dernière modification
DeploymentLa configuration via ConfigMap & Secret