Pourquoi mettre sa base de données dans Kubernetes n’est (plus) une hérésie ?

Bases de données dans Kubernetes : les arguments à la loupe

Début 2026, on a fait tout un [podcast sur Kubernetes et les promesses non tenues du cloud](https://Début 2026, on a fait tout un podcast sur Kubernetes et les promesses non tenues du cloud.). Mais aujourd'hui, je voulais me focaliser sur un sujet en particulier : les données dans Kubernetes. Alors, est-il aujourd'hui possible - et surtout judicieux - d'héberger sa base de données dans Kubernetes ? Examinons les arguments, pour déterminer s'ils relèvent de fausses croyances ou de réelles limitations.

« Kubernetes est conçu pour le stateless »

Faux. Si Kubernetes gère naturellement des workloads éphémères, cela ne signifie pas qu'il est incompatible avec la persistance des données. Les pods peuvent effectivement disparaître à tout moment, mais cela n'empêche pas la résilience des données :

• Stockage persistant : Les solutions comme les PersistentVolumes (PV) permettent de lier un stockage durable (disques SSD, NAS, etc.) à un pod, indépendamment de son cycle de vie.
• Stockage externe : Intégration avec des services comme S3, ou des solutions pour la sauvegarde et la réplication.

Opérateurs dédiés : Des outils comme CloudNativePG ou KubeDB automatisent la gestion des bases de données stateful (PostgreSQL, MySQLMoteur de gestion de base de données., etc.) avec des fonctionnalités de haute disponibilité et de sauvegarde intégrées (honnêtement impressionnant).

« Configurer un cluster de base de données dans Kubernetes est trop complexe »

Vrai… si vous le faite à la main. Monter un cluster de base de données manuellement est effectivement un exercice périlleux (désynchronisations, pertes de données, etc.). Moi-même, j'ai perdu beaucoup de cheveux à monter des clusters de base à la main dans ma jeunesse :). Cependant, les opérateurs Kubernetes ont améliorés cette approche : Automatisation : Un opérateur comme CloudNativePG permet de déployer un cluster PostgreSQLMoteur de gestion de base de données libre de droit. avec réplication, sauvegardes et monitoring en quelques commandes - aussi simplement qu'un fichier YAML.

« Les performances sont médiocres dans Kubernetes »

À nuancer. Les benchmarks montrent que les performances d'une base de données dans Kubernetes sont comparables à celles d'un service managé type RDS. Qu'on soit clair, ce n'est pas des performances bare metal, mais c'est pas pire que les RDS.

« Kubernetes est trop complexe pour héberger une base de données »

Partiellement vrai. Kubernetes n'est pas une solution universelle :

• Courbe d'apprentissage : Maîtriser les concepts (PV, StatefulSets, opérateurs) demande un investissement.
• Mais : Si votre équipe a déjà adopté Kubernetes pour d'autres workloads, ajouter une base de données devient la bonne idée surtout avec des opérateurs.

Base de données dans kubernetes : quand est-ce une bonne idée ?

• Unification de l'infrastructure : Centraliser applications et bases de données dans le même cluster simplifie la gestion (networking, IAM, observabilité).
• Portabilité : Éviter le vendor lock-in des services managés (ex : RDS) en gardant le contrôle sur ses données.
• Coûts : Pour des environnements multi-cloud ou on-premise, Kubernetes peut réduire les coûts de licensing et d'infrastructure.
• DevOps/Platform Engineering : Intégrer la base de données dans le pipeline CI/CD et les pratiques GitOps.

Quand éviter ?

• Besoins en performances extrêmes : Pour des workloads ultra-critiques , une solution dédiée (bare metal ou appliance) reste souvent préférable.
• Manque d'expertise : Sans compétences Kubernetes avancées, mieux vaut opter pour un service managé.
• Données massives : Pour des bases de données de plusieurs To, les solutions cloud natives (ex : BigQuery, Snowflake) sont souvent plus adaptées.

Conclusion : Une pratique désormais mature Mettre sa base de données dans Kubernetes n'est plus une hérésie, mais une option viable - à condition de :

• Choisir les bons outils : Opérateurs spécialisés (CloudNativePG, KubeDB), stockage performant, et monitoring adapté.
• Adapter l'architecture : Privilégier des designs résilients (réplication, sauvegardes automatiques).
• Évaluer le rapport coût/bénéfice : Kubernetes brille pour l'agilité et la portabilité, mais peut complexifier la gestion si mal maîtrisé.

Si Kubernetes vous intéresse, n'hésitez pas à écouter notre podcast sur le sujet !