Trois managers : le quorum n'est pas la HA de tes données

Mon cluster a 3 Raspberry Pi, mais un seul était manager (rpi4) — et c’est lui qui portait aussi tout l’ingress (Traefik + le tunnel Cloudflare). Deux casquettes, un seul nœud : le point unique de défaillance parfait. Le perdre = plus d’orchestration et plus de site. Le réflexe « ajoutons un 2ᵉ manager » est tentant. C’est aussi un piège.

Piège n°1 : deux managers, c’est pire qu’un seul

Le quorum raft veut une majorité de managers en ligne : floor(N/2)+1.

Managers	Quorum	Pannes tolérées
1	1	0
2	2	0 ← les deux doivent être up
3	2	1 ✅

À deux, tu ne tolères toujours aucune panne, et tu t’exposes au split-brain. Le minimum utile, c’est trois. J’ai donc promu rpi51 et rpi52 : docker node promote. Quorum 2/3, le cluster survit à la perte d’un nœud.

Et la fausse croyance qui m’avait freiné — « un manager ne doit pas faire tourner d’apps » — ne vaut que pour les gros clusters. Sur 3 Pi, la topo recommandée est justement : les 3 sont managers et exécutent la charge. Un manager, c’est un worker + le rôle raft. Promouvoir ne « gâche » rien.

L’ingress en actif/actif, et le bon dimensionnement par service

Control-plane réparti, il restait à répartir l’ingress. Et là, tout n’est pas « mets-le en global ». La vraie question : le service est-il joint sur chaque hôte, ou via le VIP de l’overlay ?

Traefik publie le port :80 de l’hôte → une instance par nœud a du sens → mode: global. Bonus : ça s’auto-ajuste si j’ajoute un manager.
cloudflared ne fait que des connexions sortantes vers le edge Cloudflare → 2 répliques sur 2 nœuds suffisent pour la HA du tunnel. Une 3ᵉ n’ajoute que des connexions.
error-pages est joint par le VIP → 2 répliques, inutile d’être partout.
Sablier (scale-to-zero) garde un état en mémoire → 1 seule, mais reschedulable.

Mettre replicas:2 n’est pas un compromis au rabais : c’est le bon outil pour un service atteint par VIP. Le sur-dimensionner ne paie pas.

Piège n°2 : Swarm refuse de changer le mode d’un service à chaud

J’édite Traefik en mode: global, je déploie… et :

failed to update service ingress_traefik:
  service mode change is not allowed

On ne peut pas convertir un service replicated en global en place. Il faut le supprimer puis le recréer — donc accepter un bref trou d’ingress. (Détour utile au passage : replicas:3 + max_replicas_per_node:1 donne le même « un par nœud » sans coupure, si on tient à zéro interruption.) J’ai assumé le micro-blip pour la sémantique propre de global.

Autre conséquence du multi-nœuds : la config dynamique de Traefik était un bind-mount d’un dossier local — qui n’existe que sur un nœud. Je l’ai passée en Swarm configs (un objet par fichier de route), distribuées automatiquement à tous les managers. Le file-provider lit toujours un dossier, mais les fichiers viennent désormais du cluster, pas du disque d’un hôte.

La vérité gênante : le quorum ne sauve pas tes données

C’est le cœur de l’affaire. Avec 3 managers + ingress actif/actif, perdre rpi4 ne coupe plus rien. Mais j’ai dû séparer proprement trois choses qu’on amalgame sous « HA » :

Couche	Réglée par	État
Control-plane (orchestration)	quorum de managers	✅ 3 managers
Ingress (le routeur)	répliques réparties	✅ actif/actif
Données (les bases)	réplication / failover	❌ toujours épinglées à un nœud

Mes Postgres sont pinnés sur un nœud (les volumes locaux NVMe ne voyagent pas). Promouvoir des managers n’y change rien : perdre ce nœud, c’est perdre les bases, qu’il y ait 1 ou 3 managers. Le quorum et la disponibilité des données sont deux problèmes orthogonaux. Et même le redémarrage à froid (pas d’onduleur) reste un risque d’intégrité disque — qu’aucun nombre de managers ne corrige, seulement un UPS.

Donc non, je n’ai pas « rendu le cluster HA ». J’ai supprimé le SPOF du control-plane et de l’ingress — la moitié stateless du problème. Le stateful (réplication des bases) est un chantier à part, et plus honnête à nommer ainsi qu’à cacher derrière le mot « HA ».

L’effet de bord qui change la vie : les nœuds deviennent nomades

Bénéfice concret du quorum : je peux déplacer un Pi à chaud. drain → arrêt propre → je le débranche, le déplace, le rallume → il rejoint le raft tout seul → activate. La seule règle : un nœud à la fois, et attendre que le raft soit complet avant le suivant (deux managers absents = quorum perdu). Un petit script l’encode et refuse la manœuvre si elle casserait le quorum.