Tout est dans le titre 
Plusieurs clusters sur plusieurs VMs ^^
C’est compliqué en effet 
Au début, on a fait une instance MySQL par service, avec docker compose, c’était le plus simple.
Des copains ( weho.st ) ont un gros cluster PG, pas sur kube, et les services sur kube.
Aujourd’hui, on en est là de la reflexion: un cluster PG par namespace qui sert du coup pour Nextcloud ou Discourse. On utilise l’opérateur postgres de Zalando et on est très content
De notre côté on a oscillé plusieurs fois. Chaque approche a ses avantages et inconvénients. Les plus clairs étant : la mutualisation coûte un petit peu moins cher en ressources, mais nécessite une gestion fine des utilisateurs ; elle facilite la supervision (on peut plus aisément instrumenter, et avec plus de profondeur) mais complexifie les configurations sécifiques.
Actuellement on ne mutualise plus, parce qu’on avait suffisamment de ressources pour se le permettre et pas trop de problèmes à debugger, donc pas besoin d’instrumentation fine. On a récemment rencontré de nombreux problèmes IO, donc on reviendra possiblement sur ce choix.
Côté zalando/postgres, ou tout opérateur Patroni, vous avez des configurations à partager, @pierre ? ou juste des liens vers un repo ? ça nous intéresse beaucoup pour la migration de nos bases vers k8s.
désolé je ne t’oublie pas, j’essaye de te donner une réponse d’ici la fin de semaine sous forme d’un zoli repo git 
Mais le Tl;DR c’est que c’est compliqué cet opérateur. J’ai du passer une semaine pour comprendre comment il fonctionne. La doc est loin d’être parfaite, mais il y a toujours le code
Il est difficile de comprendre les différentes responsabilités de l’opérateur, spilo (l’image docker) et enfin patroni…
Mais une fois que tu as compris, ça marche super bien