Comprendre le stockage dans Kubernetes

Mise à jour : 05/03/2025

Le stockage dans Kubernetes est un sujet complexe qui peut rapidement devenir un casse-tête. Contrairement aux environnements traditionnels où les données sont stockées de manière stable sur des serveurs dédiés, Kubernetes repose sur des pods éphémères, qui peuvent être créés, détruits et déplacés à tout moment.

Se pose alors plusieurs questions :

Comment alors préserver les données lorsqu’un pod disparaît ?
Comment partager un stockage entre plusieurs pods ?
Quels types de volumes utiliser selon les besoins ?

Ce guide vous aidera à comprendre ces concepts, à choisir la meilleure approche pour vos applications et à éviter les pièges courants.

Comment Kubernetes gère le stockage

Kubernetes gère le stockage en offrant deux approches principales :

les solutions intégrées (comme les volumes emptyDir, hostPath) qui fonctionnent sans ajout externe.
les solutions basées sur CSI, Container Storage Interface, qui permettent d’intégrer des systèmes de stockage avancés comme NFS, Ceph, AWS EBS, ou Google Persistent Disk via des plugins indépendants.

Dans la section suivante, nous allons explorer en détail CSI (Container Storage Interface), son architecture, son fonctionnement et comment il permet d’intégrer des solutions de stockage avancées à Kubernetes. Voici une liste de drivers CSI ↗.

Architecture du CSI

Un pilote CSI se compose généralement de deux composants :

Plugin du contrôleur (Controller Plugin) : Gère les opérations au niveau du cluster, telles que la création et la suppression de volumes, ainsi que l’attachement et le détachement des volumes aux nœuds.
Plugin du nœud (Node Plugin) : S’occupe des opérations spécifiques à chaque nœud, notamment le montage et le démontage des volumes sur les nœuds où les pods sont exécutés.

Ces plugins communiquent avec Kubernetes via des appels gRPC, assurant une interaction standardisée entre le système d’orchestration et les solutions de stockage.

Fonctionnement du CSI dans Kubernetes

Lorsqu’un utilisateur déploie une application nécessitant un stockage persistant, le processus suivant se déroule :

Requête de volume : L’utilisateur crée une demande de volume persistant (PersistentVolumeClaim ou PVC) spécifiant les caractéristiques du stockage souhaité. Il utilise un StorageClass pour définir les paramètres de provisionnement. Cette storageClass est associée à un pilote CSI spécifique.
Provisionnement du volume : Kubernetes, en fonction des classes de stockage (StorageClasses) définies, utilise le pilote CSI approprié pour créer un volume correspondant à la demande.
Attachement du volume : Le plugin du contrôleur attache le volume au nœud où le pod sera exécuté.
Montage du volume : Le plugin du nœud monte le volume sur le système de fichiers du nœud, le rendant accessible au conteneur.

Ce processus assure que les applications conteneurisées peuvent accéder de manière fiable et cohérente aux ressources de stockage nécessaires, indépendamment du fournisseur ou du type de stockage sous-jacent.

Les différents types de stockage pouvant être utilisés dans Kubernetes

Le stockage dans Kubernetes peut être classé en plusieurs catégories en fonction de sa persistance, de son mode d’accès et de son type de provisionnement. Il est essentiel de choisir la bonne solution en fonction des besoins de votre application.

Le stockage éphémère

Par défaut, un Pod n’a pas de stockage persistant : lorsqu’il est supprimé ou redémarré, ses données disparaissent. Cependant, Kubernetes offre des solutions de stockage temporaire adaptées aux cas où les données ne doivent pas survivre au cycle de vie du Pod.

emptyDir : Un stockage temporaire partagé entre les conteneurs d’un même Pod

Le volume emptyDir est créé lorsqu’un Pod démarre et supprimé lorsque le Pod est détruit. Il permet aux conteneurs d’un même Pod de partager des fichiers temporairement.

Cas d’usage :

Stocker des fichiers temporaires entre plusieurs conteneurs d’un même Pod.
Partager des caches ou des logs au sein d’un Pod.

Exemple YAML :

apiVersion: v1
kind: Pod
metadata:
  name: emptydir-demo
spec:
  containers:
    - name: app-container
      image: busybox
      command: [ "sleep", "3600" ]
      volumeMounts:
        - mountPath: "/data"
          name: temp-storage
  volumes:
    - name: temp-storage
      emptyDir: {}

hostPath : Un volume lié au nœud Kubernetes

Le volume hostPath permet à un Pod d’accéder directement au système de fichiers du nœud sur lequel il s’exécute.

Cas d’usage :

Accéder aux fichiers du nœud Kubernetes, par exemple pour les logs système.
Monter des périphériques spécifiques (disques locaux, GPU, etc.).

Limitations :

Ce type de volume n’est pas portable : si un Pod est redéployé sur un autre nœud, il perdra ses données.
Il peut poser des problèmes de sécurité, car il donne un accès direct au système de fichiers du nœud.

Exemple YAML :

apiVersion: v1
kind: Pod
metadata:
  name: hostpath-demo
spec:
  containers:
    - name: app-container
      image: busybox
      command: [ "sleep", "3600" ]
      volumeMounts:
        - mountPath: "/data"
          name: host-storage
  volumes:
    - name: host-storage
      hostPath:
        path: "/var/log"

Le stockage persistant

Contrairement aux volumes éphémères, le stockage persistant permet de conserver les données même après la suppression d’un Pod. Kubernetes offre différentes approches pour gérer le stockage persistant, et toutes ne reposent pas sur CSI (Container Storage Interface). Certaines solutions fonctionnent sans CSI, en exploitant des volumes traditionnels, tandis que d’autres utilisent CSI, offrant une intégration avancée avec Kubernetes.

Stockage basé sur des solutions non-CSI

Certaines solutions de stockage n’utilisent pas CSI, mais restent compatibles avec Kubernetes grâce aux ressources PersistentVolumes (PV) et PersistentVolumeClaims (PVC).

Avantages :

Simplicité → Pas besoin d’installer de plugin supplémentair
Compatibilité universelle → Peut être utilisé en dehors de Kubernetes.
Contrôle total → L’administrateur gère directement le stockage sans dépendre d’un orchestrateur.

Stockage utilisant CSI

Comme dit plus haut, Container Storage Interface (CSI) est devenu le standard pour l’intégration des solutions de stockage dans Kubernetes. Il permet aux fournisseurs de stockage de proposer des plugins indépendants, installés directement dans un cluster Kubernetes.

Avantages :

Provisionnement dynamique → Kubernetes peut créer automatiquement des volumes.
Mises à jour et maintenance facilitées → CSI évolue indépendamment de Kubernetes.
Fonctionnalités avancées → Gestion des snapshots, clonage, chiffrement et migration des volumes.

Voici quelques exemples de solutions de stockage utilisant CSI :

Solution	Type	Mode d’accès	Cas d’usage
AWS EBS CSI	Stockage en bloc	RWO (nœud unique)	Stockage haute performance sur AWS
Google Persistent Disk CSI	Stockage en bloc	RWO (nœud unique)	Applications cloud-native sur GCP
Ceph RBD CSI	Stockage distribué	RWO, RWX	Bases de données distribuées
Longhorn CSI	Stockage local	RWO, RWX	Stockage persistant natif Kubernetes

Faire le bon choix de stockages persistants dans Kubernetes

Pour vous aider à choisir entre un stockage, voici un tableau comparatif des deux approches :

Critère	Stockage non-CSI	Stockage avec CSI
Simplicité	Facile à configurer	Nécessite un plugin CSI
Provisionnement dynamique	Non	Oui
Gestion Kubernetes native	Limitée	Oui
Snapshops et migration	Non	Oui
Portabilité	Dépend de la configuration	Compatible multi-cloud

De plus il est important de comprendre que Kubernetes abandonne progressivement les anciennes méthodes (comme les plugins intégrés “in-tree”). Adopter CSI garantit une meilleure compatibilité avec l’écosystème Kubernetes et un meilleur contrôle du stockage persistant.

Voici un chapitre additionnel pour compléter votre guide sur le stockage dans Kubernetes en expliquant les différences entre la gestion statique et dynamique des volumes dans Kubernetes.

Gestion des volumes persistants dans Kubernetes : Statique vs Dynamique

Dans Kubernetes, il existe deux principales méthodes pour gérer les volumes persistants : statique et dynamique. Ces approches déterminent comment les volumes sont créés, alloués et gérés dans un cluster. Chaque méthode a ses avantages, et il est important de comprendre leur fonctionnement pour choisir celle qui convient le mieux à votre application.

La gestion statique des volumes

La gestion statique des volumes repose sur la création manuelle des ressources de stockage. Dans ce mode, un PersistentVolume (PV) est préalablement créé par un administrateur Kubernetes et configuré pour pointer vers un stockage existant. Une fois le volume créé, un utilisateur peut lier ce volume à un pod via un PersistentVolumeClaim (PVC) :

Création du PV (PersistentVolume) : L’administrateur crée un volume persistant en définissant ses caractéristiques (taille, type de stockage, etc.).
Création du PVC (PersistentVolumeClaim) : L’utilisateur crée un PVC spécifiant la taille et le type de stockage requis. Le PVC correspond à un PV existant qui répond à ces critères.
Association entre PVC et PV : Kubernetes associe automatiquement un PVC à un PV disponible qui satisfait les conditions du PVC.
Utilisation du volume par un Pod : Une fois le PVC attaché à un PV, le volume peut être monté dans le Pod, offrant ainsi un stockage persistant pour l’application.

Exemple de manifest de PV statique :

apiVersion: v1
kind: PersistentVolume
metadata:
  name: my-pv
spec:
  capacity:
    storage: 10Gi
  volumeMode: Filesystem
  accessModes:
    - ReadWriteOnce
  persistentVolumeReclaimPolicy: Retain
  storageClassName: standard
  hostPath:
    path: "/mnt/disks/volume1"
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: my-pvc
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: standard

La gestion dynamique des volumes

La gestion dynamique des volumes permet à Kubernetes de créer automatiquement des PersistentVolumes (PV) à la demande, sans intervention manuelle de l’administrateur. Lorsqu’un utilisateur crée un PersistentVolumeClaim (PVC) avec une StorageClass associée à un driver CSI (Container Storage Interface), Kubernetes sollicite le driver CSI pour provisionner un volume en fonction des spécifications du PVC.

Création du PVC avec StorageClass : L’utilisateur crée un PVC en précisant la StorageClass souhaitée, qui définit le type de stockage et les paramètres associés.
Provisionnement dynamique par le driver CSI : Kubernetes utilise le driver CSI pour provisionner automatiquement un volume correspondant aux critères spécifiés dans le PVC. Ce processus inclut la création et l’attachement du volume au nœud où le pod sera exécuté.
Montage et utilisation du volume : Le volume créé est monté automatiquement dans le Pod par Kubernetes, offrant ainsi un stockage persistant pour l’application.

Exemple de manifest de PVC dynamique :

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

Que choisir : statique ou dynamique ?

La gestion statique des volumes peut être plus simple dans des environnements où les volumes ne changent pas fréquemment et où l’administrateur souhaite un contrôle total. En revanche, la gestion dynamique des volumes via CSI est plus adaptée aux environnements scalables, où les volumes sont créés et gérés automatiquement en fonction des besoins des applications.

Avantages de la gestion statique :

Contrôle total sur la création et l’attribution des volumes.
Pas de dépendance aux provisionneurs CSI.
Convient aux environnements où le stockage est prédéfini et stable.

Inconvénients de la gestion statique :

Manque de flexibilité : chaque PV doit être créé manuellement.
Gestion chronophage, surtout à grande échelle.
Risque de sur-provisionnement ou sous-provisionnement des volumes.

Avantages de la gestion dynamique :

Provisionnement automatique : Kubernetes crée les volumes à la demande.
Flexibilité : adaptation aux besoins des applications sans intervention manuelle.
Scalabilité : idéal pour les environnements Cloud et CI/CD.
Réduction des erreurs humaines grâce à une configuration standardisée.

Inconvénients de la gestion dynamique :

Dépendance aux provisionneurs CSI et à leur compatibilité avec l’infrastructure.
Débogage plus complexe en cas de problème avec le stockage.
Moins de contrôle direct sur les volumes alloués.

Le choix entre ces deux approches dépendra des besoins spécifiques de votre application et de la manière dont vous gérez votre infrastructure Kubernetes.

La suite

Dans ce guide, nous avons exploré les différentes approches pour gérer le stockage dans Kubernetes, en mettant en avant les avantages et inconvénients de chaque solution. Nous avons vu comment la CSI permet d’intégrer des solutions de stockage avancées à Kubernetes, offrant des fonctionnalités comme le provisionnement dynamique, les snapshots et le chiffrement.

La prochaine étape logique est un exemple complet gestion dynamique des volumes persistants (PVC) avec un driver CSI. Dans le prochain guide, nous verrons comment déployer un driver CSI de bout en bout, configurer des PersistentVolumeClaims (PVC) et les intégrer aux applications Kubernetes.

Restez connecté pour apprendre à automatiser totalement la gestion du stockage dans vos clusters Kubernetes ! Suivez mes annonces sur mon compte LinkedIn ↗ pour ne rien manquer.