etcd leader election loop sur k8s cluster prod

hmm election loop ça sent la latence réseau ou les disques I/O sature check les métriques du disque iops latence sur les control plane et le network latency entre eux

j'ai déjà regardé les disques sont pas à fond le cpu est ok et le réseau entre les control plane est censé être en 10gbe y'a rien qui justifie ça

même si les disques sont pas à fond c'est pas les iops absolus mais la latence moyenne qui compte un disque lent même avec peu d'iops peut bloquer etcd regarde le iostat ou les métriques block device de node_exporter

ok j'ai mis en place un `iostat -x 1` sur les trois nodes. le disque système (/dev/sda) a un `await` qui monte parfois à 50-100ms sur un des nodes. les autres sont bas

voilà ça c un point un seul node lent peut foutre le bordel etcd est super sensible à la latence du disque et du réseau même un seul ms de trop peut provoquer un split brain ou des élections infinies

mais pourquoi juste un seul node ? ils ont le même hardware

y'a plein de raisons un autre process qui fait de l'i/o intensive sur ce node un snapshot backup du disque de la vm qui tourne un driver défectueux t'as des logs système qui parlent de ça sur ce node précisément

je vois rien de spécial dans les dmesg ni dans les logs du kubelet pas de process bizarre qui bouffe du i/o par contre je suis sur que ce node est aussi le leader actuel

c'est fort possible que le leader ait plus de charge et que ça le rende plus sensible aux problèmes de latence. essaie de migrer le leader sur un autre node ou de rebooter le node lent si c'est possible en prod

impossible de rebooter direct en prod là ça va péter encore plus mais je peux forcer un nouveau leader. comment je fais ça proprement sur etcd

tu peux pas forcer un leader directement etcd c'est du raft ça élit tout seul. par contre tu peux mettre le node en maintenance si c'est une vm ou conteneur tu le vire du cluster etcd et tu le rajoute après

trop risqué on a pas le droit de défaire et refaire le cluster etcd à chaud. est-ce que le tuning des paramètres etcd pourrait aider type `election-timeout` ou `heartbeat-interval`

oui ça peut mais c'est un pansement pas une solution à la cause. si tu augmentes le timeout tu masques le problème. mais pour stabiliser en urgence tu peux doubler le `heartbeat-interval` à 100ms et `election-timeout` à 1000ms

ok j'ai ajusté les timeouts c'est un peu plus stable les elections sont moins fréquentes. on va creuser le i/o du disque sur ce node. thx pour les pistes c'est moins le chaos

d'acc pas de souci. une fois que c'est stable faudrait investiguer la cause profonde de la latence i/o sur ce node particulier

ouais on va faire ça je pense à une maj du firmware du disque ou un bug vmware on est dessus thx