etcd member flapping dans K8s avec Operator, réconciliation loops infinis

yo! etcd qui flap c'est souvent un signe de latence réseau ou de disque. t'as checké les logs des etcd pods? regarde si y a des messages de leader election ou de member unreachable. un iostat -x 1 sur tes masters ça donne quoi niveau util% et await

ping entre tes masters c'est stable? des drops? et au niveau CPU/mémoire tes masters sont saturés ou tranquilles? etcd est super sensible à la latence réseau inter-member.

les logs etcd montrent des election timeout et warnings genre 'member 12345 took too long to send out heartbeat'. le ping entre masters est ok pas de drops. iostat par contre ça pic un peu sur les disques des fois à 100% util et await à 200ms+.

# excerpt from etcd logs
{"level":"warn","ts":"2023-10-27T10:30:15.123Z","caller":"etcdserver/server.go:1931","msg":"failed to send out heartbeat on time","interval":"100ms","expected-duration":"200ms","took":"250ms"}
{"level":"warn","ts":"2023-10-27T10:30:15.223Z","caller":"etcdserver/server.go:1931","msg":"leader 12345 failed to send out heartbeat on time"}

là c'est clair le souci c'est ton disque. etcd repose énormément sur des fsyncs rapides pour écrire les transactions de manière durable. 200ms d'await c'est énorme pour etcd ça pète le quorum.

ok donc il faut creuser le disque. un fio sur le répertoire data d'etcd pour simuler les writes?

oui un fio c'est une bonne idée pour isoler. essaie un truc comme ça sur chaque master quand y a pas de charge etcd

fio --name=etcd-benchmark --ioengine=psync --rw=randwrite --bs=4k --numjobs=1 --size=1G --time_based --runtime=60 --group_reporting --direct=1 --directory=/var/lib/etcd

des noisy neighbors sur tes masters? d'autres trucs qui tournent et qui tapent sur le disque au même moment? des backups, du logging, un monitoring qui tourne un peu trop fort?

les résultats fio sont pas constants. des fois c'est super rapide, des fois j'ai des latences qui montent à 150ms pour les fsyncs. c'est aléatoire mais ça arrive.

ça confirme le problème de latence disque. ça ressemble à une contention ou un flush du kernel qui arrive mal.

j'ai fouillé et j'ai un job de backup qui utilise rsync qui se lance toutes les heures sur les masters pour sauvegarder des configs système. il tape pas sur le /var/lib/etcd mais sur d'autres répertoires. ça pourrait être ça?

ah bah oui rsync ça peut consommer énormément de bande passante I/O même sur d'autres disques ou partitions. ça impacte le système de fichiers global et la capacité du kernel à répondre aux fsync d'etcd rapidement.

tu peux limiter rsync avec ionice ou cgroups pour le I/O ou le décaler à des heures creuses. ou le faire tourner sur un node dédié si c'est possible.

ok je vais tenter de mettre des limites I/O avec cgroups pour le process rsync. genre un truc simple pour voir si ça calme le jeu.

# Exemple de commande pour un PID
echo 100 > /sys/fs/cgroup/blkio/blkio.weight_device

fais gaffe avec cgroups blkio c'est un peu tricky. faut bien cibler le périphérique disque. l'idéal serait de déplacer le job rsync carrément hors des masters.

j'ai mis en place un cgroup pour rsync avec un weight très bas sur le disque. les premières heures c'est beaucoup plus stable, plus de messages de heartbeat timeout sur etcd.

top. c'est souvent ces petites interactions inattendues qui foutent la merde dans les systèmes distribués sensibles comme etcd.

je vais faire un déplacement permanent de ce job rsync c plus sûr. mais la limitation cgroup montre bien que c'était ça le problème.

problème résolu merci beaucoup à tous les deux pour l'aide. c'était bien un problème de contention I/O causé par un job de backup rsync qui tournait en douce sur les masters. etcd n'aime pas du tout ça.