16 commentaires
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
Laisser une réponse
Vous devez être connecté pour poster un message !
salut la tech team j'ai mon cluster k8s en prod qui part en vrille le kube-apiserver répond plus par intermittence les logs etcd montrent des election loops à gogo j'ai 3 nodes control plane c'est censé être stable je pige pas