Dans le cadre du déploiement d’applications stateful sur un cluster kubernetes, je me suis posé la question des solutions me permettant de déployer une instance PostgreSQL. Ce comparatif est succint et comporte surement un certain nombre d’approximations. C’est le résultat de quelques heures de veille et de tests sur le sujet (jusqu’à plusieurs semaines pour KubeDB).

Chart helm PostgreSQL

Le chart est basé sur des images custom Bitnami plutôt que sur les images officielles Postgresql. Il reste toutefois possible d’utiliser les images officielles. Ce choix d’image custom se justifie par la fonctionnalité de réplication et d’avoir des images non root. Il faudra partir sur une version Debian (10.0 pour la version 8+ du chart), CentOS 7.0 ou Oracle Linux 7.

Le chart offre d’autres fonctionnalités (authentification ldap, personnalisation de pg_hba.conf, etc) et s’avère assez riche. Il peut donc a priori gérer des cas basiques à plus avancés.

Il existe un chart pour avoir une version Postgresql High Availability (non testé).

Stolon

La solution s’appuie par défaut sur les images officielles Postgresql mais il est possible d’utiliser ses propres images. Si la solution semble intéressante, je l’ai trouvé complexe, même si cela se justifie. Le fait d’avoir de multiples composants (keeper pour les instances Postgresql, des proxy pour la gestion de la connexion à la base de données et enfin des sentinels qui surveillent le tout) m’a un peu rebuté, tout comme le fait d’avoir un binaire de plus à utiliser. La documentation est assez rudimentaire également pour bien apprécier le produit.

KubeDB

Le produit est prometteur mais manque encore de stabilité : il se base sur un operateur, il est édité par une société assez implémentée dans l’écosystème kubernetes et il permet de gérer plusieurs bases de données, dont Postgresql.

L’initialisation est assez simple et le produit semble bien pensé et offre l’ensemble des fonctionnalités que l’on peut attendre d’un operator pour gérer une base Postgresql (initialisation, réplication, sauvegarde, monitoring, etc)

Pour les backups, le produit s’appuie sur stash pour faire des backups dans des espace de stockages distants (S3, Swift, etc). Pour Restic et Swift, il faut un conteneur de type object storage ’normal’. En voulant utiliser le stockage Cloud Archive d’OVH, l’intégration ne fonctionnait pas bien.

Je ne l’ai pas retenu notant des restart des pods à répétition en lisaison avec le mécanisme d’élection de leaders qui n’aboutissait pas. J’espère que les prochaines versions vont me permettre de tester à nouveau le produit.

Crunchy

Déjà, voir que l’installation se fait via Ansible ou via des commandes bash et qu’il faut un binaire spécifique pour interagir avec la plateforme, je coince un peu. La solution semble aussi très riche mais complexe à prendre en main. Venant de KubeDB, j’avoue avoir passé rapidement mon chemin.

Zalando Postgres Operator

Zalando a rendu public son operator kubernetes. Il s’appuie sur leur solution patroni pour créer un cluster haute disponibilité. Sortant de mon test KubeDB, j’ai trouvé leur modèle trop complexe et avec des fonctionnalités dont on a a priori pas besoin (les Teams ?). J’ai du coup moins l’impression de manipuler une base de données Postgres classique.

EDB Postgres on Kubernetes

EntrepriseDB, un acteur majeur de l’écosystème Postgres, a publié en septembre dernier son operator : EDB Postgres on Kubernetes. Il ne semble pas open source et l’accès aux conteneurs demande une authentification. Je ne suis donc pas allé plus loin.

Conclusion

Alors que mes besoins sont très simples (hébergement d’instances NextCloud pour quelques utilisateurs à chaque fois) et que j’utilisais pour le moment des instances Postgresql sur un seul serveur dans des conteneurs Docker (avec la gestion des backups via un container dédié), j’avoue être resté un peu sur ma fin. J’avais fondé beaucoup d’espoirs sur KubeDB mais qui tardent à se réaliser. En attendant, je suis repassé sur le chart helm qui fonctionne bien. Il faut juste prévoir un job annexe pour les backups.

Certains pourront me dire qu’il est encore trop tôt pour faire du statefull sur kubernetes ou bien qu’il faut utiliser des base de données “cloud native”. Pour le premier point, c’est aussi avec ces petits instances non critiques que l’on peut se faire la main sur le sujet et après tout, je fais ça depuis des années avec des containers Docker sans soucis. Pour le second point, faut-il encore que ces bases existent et que les outils associés les utilisent…