Kubernetes et les bases de données

En général, on ne recommande pas vraiment d’exploiter des bases de données sur Kubernetes, et cet article passe en revue, au fil de la pensée, les problèmes concrets que cela pose.

DB on K8s : avantages

• système d’exploitation unifié via kubectl
• politique de sécurité cohérente (pare-feu, contrôle d’accès)
• intégration de la supervision
• gestion automatisée

DB on K8s : problèmes

• problèmes de performance et de stabilité liés à la distance entre le CPU et le stockage
• problèmes liés aux ressources partagées du noyau Linux
• ajout de nouveaux points de défaillance
• faible isolement opérationnel
• complexité accrue de la configuration, des paramètres réseau et de la gestion du cycle de vie

DB on K8s : solutions proposées

• renoncer à une partie des fonctionnalités de Kubernetes (1 pod DB par nœud, utilisation de volumes locaux, utilisation de hostNetwork, etc.)
• utiliser un Operator selon le type de base de données

Conclusion :

• c’est possible, mais on peut douter de son efficacité
• cela semble utile pour les services qui ont un très grand nombre de bases de données ou qui peuvent tolérer plusieurs heures d’indisponibilité
• dans les autres cas, l’approche traditionnelle paraît plus efficace

[kaydash]

Les performances se dégradent, les opérations de maintenance deviennent plus difficiles, et en cas d’incident, le nombre important de points de gestion complique l’identification de la cause.
Cela crée une situation exactement opposée à l’objectif initial de k8s, qui est de réduire les points de gestion et la charge opérationnelle.