etcd cluster lent et des elections leader a repet

salut t'as check les metriques iops sur les disques ou etcd tourne souvent c'est le storage le bottleneck. et la latence reseau entre tes noeuds etcd ? ca doit etre <1ms

les disques sont censés être rapides du nvme local. iops ok pour l'instant. latence réseau j'ai fait des pings inter-noeuds c'est genre 0.2ms. on a 10g entre eux.

regarde aussi la compaction etcd. si elle ne suit pas les evenements l'espace disque peut gonfler et ralentir tout. t'as une retention setup ?

etcdctl member list --write-out=table
etcdctl endpoint status --write-out=table

oui la compaction est activee par default avec la retention sur 30min mais j'ai pas verifié si ca tournait bien. l'espace disque est ok pour l'instant pas de saturation.

check les 'AppliedIndex' et 'CommittedIndex' via les metriques prometheus de etcd. si y'a un gros ecart ca indique un lag. et les 'leader_changes_total' bien sur. tu peux aussi augmenter le --election-timeout si ton reseau est juste un peu flou

j'ai bien les metriques. le AppliedIndex est parfois un peu derriere le CommittedIndex sur les followers c'est vrai. leader_changes_total est monté en fleche ces derniers jours.

tu utilises des snapshots auto ? et quel est ton quorum size ? si t'as 3 noeuds c'est 2 le quorum. assure toi que tous les noeuds soient au courant de tous les autres pour le vote

snapshots oui mais pas de probleme de place. quorum size par defaut 2 sur 3. je pense que tous les noeuds se connaissent bien la config est bonne.

une autre idee. les ressources CPU / RAM des VMs etcd sont suffisantes ? et tu as bien desactivé le swap dessus ? etdd est sensible a ca.

CPU/RAM c'est du lourd 8c/32g. swap est bien off partout. je penche pour un truc plus subtil. est-ce que le traffic net entre apiserver et etcd est propre ?

ouais ca peut etre ca un truc qui sature le reseau sur tes apiservers quand ils parlent a etcd. regarde tcpdump sur etcd pour voir le traffic entrant pendant ces phases de lag. combien de connexions ?

ok je vais faire un tcpdump sur le port 2379 pour voir. je soupconne que les apiservers spamment etcd quand y'a beaucoup de deploiements ou de resyncs de controllers.

si c'est le cas etcd a du mal a repondre aux requetes du leader et les followers le declarent mort. tu peux tester de limiter les requetes apiserver vers etcd pour voir si ca calme le jeu temporairement.

et n'oublie pas le `etcdctl defrag` en cas de gros volume de keys et de delete. ca peut aider a liberer de l'espace dans la bdd etcd

d'acc je vais mettre en place des limites sur les apiservers pour etcd et faire un defrag apres les heures de pointe. merci les gars je vous tiens au jus.

bon courage tiens nous informés du resultat !