18 commentaires
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
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/etcdles 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.
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_devicefais 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.
Laisser une réponse
Vous devez être connecté pour poster un message !
salut la commu, on a un cluster K8s qui fait des siennes. on a 3 etcd members sur les masters et sous charge moyenne-haute on voit des etcd members flapper (unhealthy/healthy). ça rend nos operators custom complètement fous ils partent en réconciliation loops infinis et ça bouffe du CPU. y a un truc qui m'échappe sur l'infra.