etcd leader election instable sur k8s clusters galère

check les logs systemd d'etcd sur chaque master t'as des warnings genre "apply request took too long"

ouais pas mal de "apply request took too long" et des "wal fsync took too long" même

ah ok alors c'est l'infra disk derrière etcd qui est pas assez perf c'est du ssd ou hdd

c'est du ssd provisionné sur notre env vmware mais j'avoue que le storage est partagé avec d'autres trucs

mauvaise idée etcd est ultra sensible à la latence disque il lui faut son propre iops si possible dédiés sinon ça part en vrille direct

t'as regardé les métriques disque iops et latence depuis les noeuds masters direct ? genre iotop ou iostat

iostat me sort des avgrq-sz énormes et des await à genre 50-100ms sur le volume etcd

voilà tu as ta cause 50ms d'await c'est la mort pour etcd faudrait être sous 10ms voir 5ms max. le problème est clairement côté storage

est-ce que ton WAL dir est séparé de ta data dir ? c'est une best practice pour etcd si tu peux le faire

non tout est sur le même volume par défaut j'avais pas pensé à ça

faut absolument séparer le WAL dir sur un volume avec des iops encore plus rapides s'il y a un moyen

ok je vais voir avec l'équipe infra si on peut monter un nouveau volume ultra rapide juste pour le WAL et resizer le volume data

fais gaffe la migration du WAL dir c'est un peu tricky faut arrêter etcd faire le move et relancer

je suis en train de faire ça. stop etcd déplacer reconfigurer le service et relancer

n'oublie pas de backup avant hein tu connais la musique

oui oui j'ai un snapshot vmware en cas de pépin thx. je relance et je te dis

bon on dirait que c'est le jour et la nuit les leader elections sont stables plus de timeouts les awaits sont descendus à 2-3ms sur le WAL dir dédié c'est super fluide

nickel on avait eu le même souci sur un gros cluster chez nous une fois c'est un grand classique pour etcd le storage

grave merci bcp pour l'aide je pensais pas que ça aurait autant d'impact