Lorsque Kubernetes est apparu, il reposait sur une idée simple mais puissante : traiter les applications comme sans état (stateless). Si un conteneur tombait, Kubernetes en redémarrait un autre ailleurs dans le cluster, et tout continuait comme si de rien n’était. Cela fonctionnait parfaitement pour des microservices qui n’avaient pas besoin de se souvenir de quoi que ce soit entre deux requêtes.
Mais la réalité a fini par frapper à la porte du cluster. Le monde de l’entreprise tourne autour des données : historiques de commandes, profils utilisateurs, transactions financières, inventaires de produits, journaux, analyses… Ces charges de travail ne sont pas sans état ; elles dépendent du fait de conserver et d’accéder aux mêmes données dans le temps. Soudain, Kubernetes a dû apprendre à gérer des applications pour lesquelles “juste redémarrer” pouvait signifier perdre des téraoctets d’informations critiques.
Et c’est là que le stockage persistant entre en jeu. Sans lui, exécuter des charges de travail avec état sur Kubernetes revient à faire tourner une base de données sur un bureau temporaire… en glace. Vous pouvez écrire tout ce que vous voulez, mais au moindre changement de température, tout fond.
Charges de travail avec ou sans état : une distinction cruciale
La meilleure manière de comprendre le besoin en stockage persistant, c’est de comparer les charges de travail stateless et stateful dans Kubernetes.
Un service stateless, c’est comme un péage autoroutier qui ne garde aucune trace. Les voitures passent, on collecte le péage, et c’est terminé. Si l’agent change, rien n’est perdu. En termes Kubernetes, cela correspond à une API HTTP qui affiche des produits, un service de rendu PDF, ou un processeur d’événements léger.
Une charge stateful, au contraire, est comme un employé de banque. Chaque transaction doit être enregistrée, stockée et consultable plus tard. Si l’employé disparaît avec les registres, la banque s’effondre. En Kubernetes, cela correspond à votre base de données MySQL, vos brokers Kafka, votre cluster Elasticsearch, ou même Redis en mode persistant.
La raison technique derrière cette différence est le cycle de vie des pods : les pods sont éphémères. Ils ne sont pas liés à un matériel spécifique, et peuvent être supprimés ou reprogrammés à tout moment. C’est parfait pour la résilience et l’élasticité, mais catastrophique pour ce qui dépend de données locales qui doivent survivre au lendemain.
Le problème du stockage éphémère
Chaque pod Kubernetes dispose d’un stockage intégré, mais il est éphémère : il existe uniquement tant que le pod est actif. Si le pod est détruit (suite à une mise à jour ou un crash du nœud), ce stockage est effacé.
On peut utiliser des volumes comme emptyDir pour du stockage temporaire : parfait pour des caches, des fichiers temporaires ou des calculs à courte durée. Mais ils sont liés au cycle de vie du pod. Si votre pod PostgreSQL utilise emptyDir pour stocker ses fichiers, vous les perdez dès que le pod est supprimé — comme si vous les stockiez dans /tmp.
Cette nature éphémère complique aussi la récupération : imaginez un broker Kafka qui échoue. Sans stockage persistant, Kubernetes relance un nouveau broker… à partir de zéro. Les offsets sont perdus, les partitions doivent être reconstruites — si des répliques existent.
Le stockage persistant : dissocier données et calcul
Le principe fondamental du stockage persistant dans Kubernetes est de découpler les données du pod. Le pod (ressource de calcul) peut apparaître ou disparaître, mais les données vivent de manière indépendante sur un système de stockage que Kubernetes peut réattacher au besoin.
Ce modèle permet de :
- Survivre aux pannes de nœuds sans perte de données.
- Réaliser des mises à jour progressives sans effacer l’état de l’application.
- Faire évoluer des charges stateful sur plusieurs nœuds sans intervention manuelle.
- Maintenir un comportement constant de l’application, même après un redéploiement.
Kubernetes utilise pour cela deux objets :
- PersistentVolume (PV) : la ressource de stockage réelle (EBS AWS, Disque Azure, Disque persistant Google, montage NFS, bloc Ceph, etc.).
- PersistentVolumeClaim (PVC) : le contrat entre l’application et le stockage. Plutôt que de coder en dur les détails du stockage, l’application dit : “j’ai besoin de 20 Go en lecture/écriture exclusive”, et Kubernetes s’occupe du reste grâce aux StorageClasses disponibles.
StatefulSets : au-delà du stockage
Les PVs résolvent le problème du stockage, mais pas tous les besoins des applications stateful. Beaucoup nécessitent :
- une identité réseau stable,
- une séquence ordonnée de démarrage/arrêt.
Prenez un cluster de base de données avec des nœuds leader/follower : on ne peut pas démarrer tous les pods aléatoirement et espérer que tout fonctionne. Certains doivent commencer avant les autres, avec des noms fixes pour que les pairs les retrouvent.
C’est pour cela que Kubernetes a introduit les StatefulSets. Contrairement aux Deployments (où les pods sont interchangeables), les StatefulSets considèrent les pods comme des “animaux de compagnie”. Les noms sont stables (app-0, app-1, etc.) et chaque PVC est lié à un nom.
Par exemple, si mysql-0 meurt, Kubernetes le recrée avec le même nom et le même PVC attaché, peu importe sur quel nœud il atterrit. L’application reprend alors son activité sans perdre de données.
Les défis réels du stockage persistant dans Kubernetes
Même avec PV, PVC et StatefulSets, le stockage dans Kubernetes n’est pas encore totalement “clé en main”.
Quelques défis :
- Performance : certaines applications sont très sensibles à la latence I/O. Un mauvais choix de StorageClass ou de backend peut ralentir tout le système.
- Disponibilité multi-zones : beaucoup de systèmes de stockage en bloc sont limités à une seule zone, ce qui complique les déploiements haute-disponibilité.
- Sauvegarde & reprise après sinistre : un volume persistant n’est pas une sauvegarde. Si le stockage sous-jacent échoue ou est supprimé, il faut des mécanismes de récupération comme les snapshots ou la réplication.
- Accès multi-auteurs : les workloads ayant besoin d’un accès ReadWriteMany nécessitent une coordination complexe pour éviter la corruption (ex : systèmes de fichiers partagés ou stockage distribué).
Et surtout, la raison pour laquelle tout cela est difficile, c’est que la plupart des stockages traditionnels ne sont pas natifs Kubernetes. Ils opèrent en dehors du plan de contrôle Kubernetes, avec leur propre ordonnanceur, domaines de panne, et logique de service. Résultat : la coordination (attach/detach, basculement, etc.) est fragile, et les opérations paraissent “ajoutées” à la main.
Le stockage natif conteneur : la solution moderne
Le stockage persistant dans Kubernetes, ce n’est pas juste “un disque qui survit à un redémarrage”. Il faut un stockage qui parle nativement Kubernetes.
Les systèmes traditionnels, conçus avant l’ère des conteneurs, voient Kubernetes comme un client externe. Ils s’y connectent depuis l’extérieur, souvent avec des intégrations manuelles, des étapes complexes, des modèles de scalabilité inadaptés, et peu d’automatisation.
Le Container-Native Storage (CNS) inverse ce modèle. Au lieu d’être externe, le CNS est déployé à l’intérieur de
Kubernetes, sous forme de microservices, comme vos applications. La couche de stockage devient un citoyen du cluster : planifiée, scalée, gérée avec les mêmes primitives Kubernetes que le reste.
Pourquoi c’est important :
- Il garantit que les données survivent aux pods de façon fiable et prévisible lors des basculements.
- Il rend la persistance aussi automatisée et dynamique que le reste de Kubernetes — plus besoin de traiter les workloads avec état comme des cas particuliers.
Avec le CNS :
- Les volumes sont créés dynamiquement dès qu’un PVC est fait.
- La réplication des données entre nœuds permet une haute disponibilité native.
- Le basculement est intégré : si un pod change de nœud, son stockage suit (ou un réplica existe déjà).
- La performance de stockage évolue avec le cluster : plus de nœuds = plus de capacité et de débit.
- Les services de données (snapshots, thin provisioning, etc.) sont intégrés, sans outils externes.
En résumé, le CNS n’apporte pas seulement un stockage persistant — il apporte un stockage persistant natif Kubernetes, qui ne reste plus à la traîne sur l’automatisation, la résilience et l’échelle. C’est ce qui permet enfin de traiter les applications stateful avec le même niveau de confiance opérationnelle que les stateless.
Comment DataCore peut vous aider
Choisir et faire fonctionner une stratégie de stockage persistant dans Kubernetes ne se résume pas à choisir une technologie. Il faut l’aligner avec les besoins en performance, en disponibilité et en croissance de vos applications.
C’est là que DataCore fait la différence.
DataCore conçoit des solutions de stockage logiciel container-native, intégrées nativement à Kubernetes. Avec des services de données de niveau entreprise (HA, réplication, snapshots, intégration backup, etc.) combinés à un modèle opérationnel Kubernetes natif, DataCore permet aux entreprises d’exécuter même les workloads stateful les plus exigeants en toute confiance.
Que vous modernisiez des applications existantes, déployiez des bases cloud-native, ou construisiez de nouveaux services stateful, DataCore fournit les outils, l’architecture, et le support nécessaires pour rendre votre couche de stockage aussi agile, résiliente et automatisée que Kubernetes lui-même.
Résultat : une plateforme où workloads avec ou sans état coexistent, sans compromis.
Prêt à rendre votre stockage persistant Kubernetes digne de la production ?
Contactez-nous pour voir comment DataCore peut vous aider à exécuter vos charges de travail avec état avec la fiabilité et les performances d’un environnement entreprise.
