Beaucoup d’entreprises partent du principe que si Kubernetes (K8s) excelle à orchestrer les applications, il doit naturellement héberger tout le reste : bases de données, brokers de messages, outils de recherche.
Cette logique du « tout-conteneur » est séduisante sur le papier. Pourtant, vouloir y faire entrer de force l’intégralité de vos middlewares historiques et de vos infrastructures de données peut rapidement transformer une bonne idée en un défi de gouvernance complexe.
Un point de repère : de quoi parle-t-on exactement ?
Avant de parler d’architecture, il est utile de préciser ce que l’on met derrière ces termes dans le contexte actuel :
Kubernetes : Pensé à l’origine pour le stateless, c’est un orchestrateur conçu pour déployer, scaler et gérer des microservices éphémères et hautement volatiles.
Le Middleware : C’est la couche logicielle d’infrastructure qui fait le lien entre vos applications et vos bases de données ou vos systèmes d’exploitation. On y regroupe les bases de données (PostgreSQL, MongoDB), les moteurs de recherche (Elasticsearch), les brokers de messages (Kafka, RabbitMQ) ou les caches (Redis). Contrairement aux microservices, ces composants sont dits stateful : ils ont besoin de conserver un état et des données de manière hautement persistante et sécurisée.
La question n’est pas de savoir si Kubernetes est techniquement capable de faire tourner vos middlewares; la technologie et les opérateurs le permettent largement aujourd’hui. La vraie question est de savoir si votre organisation a intérêt à le faire, au vu des efforts requis sur quatre piliers stratégiques.
1. L'architecture : le débat du stateful et du niveau de maturité
Faire tourner des applications sans état (stateless) sur Kubernetes est devenu un standard. Les choses se corsent lorsqu’on touche aux middlewares stateful, qui doivent stocker et conserver des données critiques à long terme.
Aujourd’hui, l’écosystème a mûri. Grâce aux Operators (comme CloudNativePG ou Strimzi), gérer du stateful sur K8s est tout à fait viable. Cependant, cela demande une excellente maturité opérationnelle des équipes.
Pour simplifier votre architecture, deux voies principales coexistent selon vos contraintes :
- La délégation (si vos critères réglementaires le permettent) : s’orienter vers des services managés (DBaaS) dans le cloud pour vos bases de données les plus lourdes, vous évitant ainsi de gérer la plomberie du stockage persistant.
- La conteneurisation maîtrisée (si vous êtes On-Premise ou souverain) : garder ces middlewares sur K8s, mais uniquement si vos équipes ont les compétences internes pour gérer les pannes de stockage et la réplication des données au sein du cluster.
2. Le volet financier : au-delà de la simple consommation de ressources
La promesse de réduction des coûts de Kubernetes s’accompagne de réalités financières parfois négligées :
- Le piège des licences traditionnelles : les modèles commerciaux de certains éditeurs historiques ne sont pas toujours adaptés à la volatilité de Kubernetes. Un pod qui se déplace d’un serveur à un autre peut, lors d’un audit, déclencher des redressements de licences très douloureux basés sur la puissance totale de vos serveurs physiques.
- La granularité du FinOps : partager un cluster entre plusieurs équipes (mutualisation) complique la répartition des coûts. Un vrai suivi FinOps ne se limite pas à mesurer la RAM et le CPU des pods. Il doit intégrer le coût du stockage persistant associé, les transferts de données inter-zones (réseau) et les outils d’observabilité indispensables au bon fonctionnement de vos middlewares.
3. L'humain : ne surchargez pas vos développeurs
Kubernetes est une machine de guerre d’une grande complexité. Demander à chaque développeur de maîtriser K8s pour déployer et maintenir ses propres files de messages ou bases de données de test est souvent contre-productif.
Pour éviter de saturer vos équipes tout en maintenant leur autonomie, le Platform Engineering offre une excellente réponse. En construisant un portail interne (IDP pour Internal Developer Platform), vous masquez la complexité de l’infrastructure.
Vos développeurs consomment du middleware pré-configuré et sécurisé en quelques clics, sans avoir à manipuler des fichiers de configuration interminables.
4. La sécurité : repenser la confiance et l'isolation des flux
Dans un environnement partagé où cohabitent applications et middlewares critiques, la sécurité périmétrique traditionnelle est insuffisante. C’est ici qu’intervient l’approche Zero Trust (ne faire confiance à aucun flux par défaut).
Pour chiffrer et contrôler les communications entre vos pods, plusieurs options existent selon la taille de votre infrastructure :
- Les solutions légères : l’implémentation de politiques réseau strictes (Network Policies) et l’usage de CNI modernes (comme Cilium) permettent de cloisonner efficacement vos flux sans ajouter de surcouche complexe.
- Les Service Mesh (comme Istio ou Linkerd) : ils apportent une sécurité et une observabilité maximales (notamment via le mTLS natif), mais au prix d’une complexité de gestion supplémentaire que toutes les équipes ne sont pas prêtes à assumer.
Ce qu'il faut retenir
La conteneurisation de vos middlewares n’est ni une obligation, ni une hérésie. C’est un curseur à placer selon vos besoins réels d’automatisation, de portabilité et, surtout, selon la maturité de vos équipes d’ingénierie.
L’important est de ne pas utiliser Kubernetes comme une finalité technologique, mais comme un moyen d’apporter une valeur concrète et mesurable à votre architecture.
FAQ
Est-il possible de faire tourner des bases de données de production sur Kubernetes ?
Oui, c’est tout à fait possible et de nombreuses entreprises le font avec succès grâce aux Operators. Cependant, cela demande des compétences pointues en ingénierie de stockage et en gestion de la persistance des données pour garantir la haute disponibilité en cas de panne d’un nœud du cluster.
Pourquoi le modèle de licence de certains éditeurs pose-t-il problème sur K8s ?
Certains logiciels traditionnels calculent leurs tarifs sur le nombre de cœurs physiques de la machine où ils s’exécutent. Comme Kubernetes déplace de façon dynamique les conteneurs (pods) d’un serveur physique à un autre au sein d’un cluster, un éditeur peut considérer lors d’un audit que son logiciel a « utilisé » l’ensemble des serveurs du cluster, ce qui multiplie la facture de manière exponentielle.
Comment choisir entre du DBaaS (Cloud) et des bases de données conteneurisées On-Premise ?
Le choix dépend principalement de vos contraintes. Le DBaaS (Database as a Service) offre la simplicité opérationnelle mais peut poser des limites de souveraineté et de coûts à grande échelle. L’approche On-Premise (dans vos datacenters) garantit le contrôle total et la conformité, mais exige que vous gériez vous-même la maintenance, les sauvegardes et la résilience de vos bases de données.
