Un cluster Kubernetes sur deux sites a-t-il besoin de trois votants etcd ?

Trois VM de plan de contrôle donnent l'impression de trois chances de survivre à une mauvaise nuit. Elles ne le sont pas, et l'écart entre ces deux croyances est ce qui transforme une conception soignée à trois nœuds en un cluster qui cesse d'accepter des écritures lorsqu'un bâtiment perd son alimentation. Une liaison VPN entre les sites rend les machines joignables les unes aux autres et masque le problème au lieu de le corriger. Les votes sont comptés par membre etcd, et deux de ces membres peuvent encore se trouver derrière un même commutateur, un même onduleur et une même liaison montante.

Trois nœuds de plan de contrôle, un seul domaine de défaillance

Vous lancez kubectl get nodes, voyez trois entrées de plan de contrôle et classez le cluster comme haute disponibilité. Ce décompte décrit une capacité planifiable, pas une survie. Dans kubeadm sans etcd externe, chaque nœud de plan de contrôle héberge aussi un membre, donc trois nœuds donnent réellement trois votants. Savoir si ces votants échouent indépendamment est une question distincte à laquelle la liste des nœuds ne peut pas répondre.

Deux VM sur un même hyperviseur, deux baies sur une même alimentation, deux liaisons montantes d'un même FAI : chaque paire est un seul domaine portant deux noms d'hôte. Écrivez le placement et notez ce que chaque votant partage — hyperviseur, PDU, commutateur de haut de baie, baie de stockage, dispositif NAT, concentrateur VPN. Retirez ensuite chaque objet partagé sur le papier et recomptez les votes restants. Un cluster qui perd deux votants à cause d'un seul hôte défaillant a été un cluster à votant unique depuis le début ; personne ne lui avait encore posé la question.

Ce qu'une séparation en deux sites peut et ne peut pas survivre

Quand trois votants sont placés deux et un sur deux sites, le côté le plus grand conserve le quorum lorsque l'autre site disparaît, et le côté à votant unique jamais. Cette asymétrie est de l'arithmétique, pas du réglage. Tout cluster etcd fondé sur la majorité réparti exactement sur deux sites indépendants échoue au test « perdez l'un ou l'autre site et continuez à valider », car les deux côtés devraient détenir plus de la moitié des votes en même temps.

Le tableau ci-dessous est le moyen le plus rapide de voir quelles pannes vous avez réellement achetées. Lisez chaque ligne ainsi : si toute cette ligne disparaît cette nuit, les survivants peuvent-ils encore valider une écriture ?

Pourquoi le tunnel n'ajoute jamais de vote

Un VPN est un transport, pas un membre. Il peut rendre un votant distant joignable et transformer une partition en quelque chose qui ressemble à un délai d'attente lent, et c'est toute sa contribution au quorum. Ce qu'il ajoute, c'est un coût, car chaque validation doit traverser la liaison et etcd paie cet aller-retour sur les écritures qui touchent le journal raft. Un chemin qui clignote transforme la réplication en nouvelles tentatives et en élections.

Les partitions sont là où les gens attendent de la magie, soyez donc précis à leur sujet. Si la liaison tombe alors que l'ancien chef siège du côté à votant unique, ce côté ne peut pas valider et le chef se retire une fois le délai d'élection expiré, tandis que le côté à deux votants élit un remplaçant. Le guide etcd des modes de défaillance décrit le comportement simplement : service continu du côté majoritaire, aucun second cluster inscriptible du côté isolé.

Décidez quelle panne vous achetez

Deux plus un est une conception légitime lorsque le site A est le principal et que vous acceptez que le perdre signifie perdre les écritures du plan de contrôle jusqu'à ce que quelqu'un agisse. Ce qui en fait un défaut, c'est de laisser cette décision implicite. Inscrivez-la dans le runbook : quel site votre plan de contrôle survit, et ce qu'un opérateur fait lorsque l'autre site s'éteint à 03:00.

Si l'exigence est plutôt « l'un ou l'autre site peut échouer », le placement doit détenir une majorité dans chaque site, et trois votants sur deux sites ne peuvent pas le faire. Soit vous ajoutez un troisième domaine réellement indépendant — une petite région chez un autre fournisseur convient si le chemin vers elle est stable — soit vous vous scindez en deux clusters avec des etcd séparés et acceptez le coût opérationnel de cette scission. Aucun raccourci de témoin n'évite cela : etcd n'a pas de membre arbitre léger, donc un troisième votant est un membre complet avec ses propres exigences de disque, de mémoire et de réseau. Dessiner une case intitulée témoin sur le schéma n'en crée pas un.

Le quorum n'est pas la même chose que le service

Le quorum etcd maintient le serveur d'API capable d'accepter des écritures, et c'est tout ce qu'il maintient. Les sondes de santé du répartiteur de charge, l'ingress, la joignabilité CNI à travers le tunnel, les zones d'attachement de volumes et la réplication applicative ont chacune besoin de leur propre réponse. Un cluster peut détenir une majorité nette et ne rien offrir d'utile aux utilisateurs.

Confirmez ensuite l'adhésion que vous croyez avoir, car les schémas dérivent :

kubectl -n kube-system get pods -l component=etcd -o wide
kubectl get endpoints kube-apiserver -n default
etcdctl member list -w table

Comparez la liste des membres au schéma de placement. Si deux membres se résolvent vers le même hôte ou la même baie, c'est le schéma qui est faux et non le cluster, et redimensionner autour d'une topologie erronée n'achète qu'une version plus chère de la même panne.

Avant d'approuver une conception à trois votants, répondez à quatre questions : combien de votants perdent l'alimentation ensemble, quelle perte de site laisse encore une majorité, où siège le chef lorsque le tunnel tombe, et que peut encore faire le site survivant. Un « pas sûr » sur l'une d'elles signifie que le cluster n'est pas encore hautement disponible. Ce sont trois machines qui ont eu de la chance.