etcd hyper lent sur k8s le cluster agonise

Yo. slow_apply_total c'est pas bon du tout. t'as quelle version d'etcd et de k8s. t'as regardé les iops sur tes disques nvme ou les latences disk

k8s 1.28 et etcd 3.5.7. les nvme sont à genre 10% d'utilisation selon les métriques de l'hyperviseur pas de latence anormale du côté infra

hum intéressant. regarde ton wal fsync_duration_seconds et commit_duration_seconds dans les métriques etcd. c'est souvent le coupable. ptete aussi trop de mvcc revisions sur etcd

ok je regarde ça. le wal_fsync_duration est dans les 50ms et le commit_duration monte parfois à 500ms. ça sent pas bon. mvcc_put_total est à des millions

500ms pour un commit c'est n'importe quoi. tes snapshots et compactions ça se passe comment t'as des erreurs de ça dans les logs etcd

pas d'erreurs visibles sur les snapshots mais j'ai des warnings sur les compactions qui prennent trop de temps

ok ça confirme. t'as pas un souci de network latency entre tes membres etcd. genre les vms sont sur des hôtes différents avec une interco pourrie ou un firewall qui fait du packet inspection

non l'infra est plate le réseau est censé être en 10gbps sans bottleneck. j'ai run un iperf entre les nodes et c ok

t'as le snapshot-count par défaut ou tu l'as modifié. des fois trop peu de snapshots ça veut dire des grosses compactions qui bloquent tout. et ta taille de base tu l'as check. etcdctl db size

snapshot-count est par défaut à 100k. la db size est à 4gb. c'est pas énorme pour 5 nodes. j'ai vu des trucs sur auto-compaction-retention faut ptete baisser ça

4gb c'est pas si petit que ça non plus. auto-compaction-retention c'est pas bête. si tu gardes trop d'historique ça alourdit les compactions. essaie de le mettre à 1h au lieu du 24h par défaut si t'en as besoin

j'ai mis auto-compaction-retention à 1h. j'ai redémarré les membres un par un pour appliquer la config. ça a l'air un peu mieux. les commit_duration sont tombés à 100ms max. c'est pas encore parfait mais c'est jouable

good start. regarde aussi tes métriques de cpu et memory sur les nodes etcd. si un node galère ça ralentit tout le quorum

les cpu sont à 30% la ram à 50%. pas de bottleneck là. j'ai remarqué que le leader prend plus cher en cpu. c'est normal j'imagine

ouais le leader est plus sollicité. t'as check si t'as pas des crd ou des webhooks qui spam etcd avec des updates inutiles. ça arrive souvent

putain bien vu. j'ai un webhook pour un admission controller qui fait des checks un peu trop lourds sur chaque objet. je vais le désactiver temporairement pour voir

JE CROIS QUE C'ÉTAIT ÇA! après avoir désactivé le webhook les commit_duration sont redescendus sous les 50ms et le cluster est de nouveau réactif. MERCI ENCORE j'aurais jamais trouvé tout seul le coup du webhook.