web-dev-qa-db-fra.com

Comment modéliser un cluster de basculement PostgreSQL avec Docker/Kubernetes?

Je suis toujours en train de comprendre Kubernetes et son fonctionnement. Actuellement, j'ai du mal à comprendre comment modéliser un cluster PostgreSQL avec réplication en continu, mise à l'échelle et reprise automatique (pgpool-II, repmgr, choisissez votre poison).

Mon principal problème avec cette approche est la double nature d’une instance PostgreSQL, d’un point de vue configuration, c’est un maître ou un serveur en veille froide/chaude/chaude. Si j'augmente le nombre de répliques, je m'attendrais à ce qu'elles se présentent toutes en standby. J'imagine donc que l'on crée un contrôleur de réplication postgresql-standby séparément d'un pod postgresql-master. Cependant, je m'attendrais également à ce que l'un de ces statuts devienne un maître si le maître actuel est en panne, c'est donc un contrôleur de réplication postgresql commun.

La seule idée que j'ai eu jusqu'à présent est de placer la configuration de réplication sur un volume externe et de gérer l'état et les changements d'état en dehors des conteneurs.

(dans le cas de PostgreSQL, la configuration serait probablement déjà sur un volume à l'intérieur de son répertoire data, ce qui en soi est évidemment ce que je souhaiterais sur un volume, mais ce n'est pas grave)

Est-ce la bonne approche ou existe-t-il un moyen plus propre?

postgresqldockerkubernetes
27
Nikolai Prokoschenko

Il y a un exemple dans OpenShift: https://github.com/openshift/postgresql/tree/master/examples/replica Le principe est le même dans Kube pur (il n’utilise rien d’authentiquement spécifique à OpenShift, et vous pouvez utiliser les images en docker simple)

10
Clayton

Vous pouvez essayer PostDock a essayer, avec docker-compose ou Kubernetes. Actuellement, je l'ai essayé dans notre projet avec docker-compose, avec le schéma ci-dessous:

pgmaster (primary node1)  --|
|- pgslave1 (node2)       --|
|  |- pgslave2 (node3)    --|----pgpool (master_slave_mode stream)----client
|- pgslave3 (node4)       --|
   |- pgslave4 (node5)    --|

J'ai testé les scénarios suivants et ils fonctionnent tous très bien:

  • Réplication: les modifications apportées au noeud principal (maître) seront répliquées sur tous les noeuds en attente (esclave).
  • Basculement: arrête le noeud principal et un noeud de secours (par exemple, noeud4) prendra automatiquement le rôle principal.
  • Prévention de deux nœuds principaux: ressuscitez le nœud principal précédent (nœud1), nœud 4 continuera en tant que nœud principal, tandis que nœud1 sera synchronisé mais en tant que nœud de secours. 

En ce qui concerne l'application cliente, ces modifications sont toutes transparentes. Le client pointe simplement sur le nœud pgpool et continue de bien fonctionner dans tous les scénarios susmentionnés.

Note: Si vous rencontrez des problèmes pour faire fonctionner PostDock, vous pouvez essayer ma version forkée de PostDock .

Pgpool-II avec chien de garde

Un problème avec l'architecture susmentionnée est que pgpool est le point de défaillance unique. J'ai donc également essayé d'activer Watchdog pour pgpool-II avec une adresse IP virtuelle déléguée, afin d'éviter le point de défaillance unique.

master (primary node1)  --\
|- slave1 (node2)       ---\     / pgpool1 (active)  \
|  |- slave2 (node3)    ----|---|                     |----client
|- slave3 (node4)       ---/     \ pgpool2 (standby) /
   |- slave4 (node5)    --/

J'ai testé les scénarios suivants et ils fonctionnent tous très bien: 

  • Scénario normal: les deux pgpools démarrent, avec l’IP virtuelle automatiquement appliquée à l’un d’eux, dans mon cas, pgpool1
  • Basculement: arrêter pgpool1. L'IP virtuelle sera automatiquement appliquée à pgpool2, qui deviendra donc actif.
  • Start failed pgpool: redémarrez pgpool1. L'IP virtuelle sera conservée avec pgpool2 et pgpool1 fonctionne maintenant en mode veille.

En ce qui concerne l'application cliente, ces modifications sont toutes transparentes. Le client pointe simplement sur l'adresse IP virtuelle et continue de bien fonctionner dans tous les scénarios susmentionnés.

Vous pouvez trouver ce projet sur mon dépôt GitHub sur la branche watchdog .

1
Yuci

Statefulset de Kubernetes est une bonne base pour configurer le service stateful. Vous aurez encore besoin de travail pour configurer l’adhésion correcte entre les réplicas PostgreSQL. 

Kubernetes a un exemple pour cela. http://blog.kubernetes.io/2017/02/postgresql-clusters-kubernetes-statefulsets.html

0
CloudStax