etcd latency spikes cluster instable

check tes logs etcd d'abord. t'as des warnings genre 'apply took too long' ou des 'leader changed' frequents

regarde aussi l'utilisation disque. io bound souvent etcd. ssd nvme c'est un must. t'es sur quel type de stockage

ouais on a du 'wal fsync took too long'. on est sur gp3 avec iops provisionnés mais ptete pas assez

gp3 c'est pas toujours la joie pour etcd. tu peux avoir des iops burst mais si t'es en continu ça peut butter. provisionne bien

et ton reseau entre les etcd members. latence elevee aussi ça flingue le raft. ping les nodes entre elles tu vois quoi

reseau semble ok. par contre on a pas mal de deployments qui se lancent avec des milliers de pods en meme temps au demarrage. ça cree du churn sur l'api server et etcd non

ah oui ça c'est une piste. le rate limit de l'api server est ptete trop haut ou pas assez agressif pour etcd. trop de requetes d'un coup

regarde tes metrics etcd_server_proposals_pending et etcd_network_peer_round_trip_time_seconds. si proposals_pending monte en fleche qd ça lag c'est que ça suit pas

les pending montent effectivement. on a aussi vu des 'mvcc: database space exceeded' dans les logs recemment apres un gros spike

espace db exceeded c'est critique. etcd a une limite par defaut pour la db size. faut compact. et si ça arrive souvent faut augmenter le quota mais surtout trouver la cause du bloating

y'a ptete un operator qui spamme etcd avec des CRD enormes ou des events inutiles. faut monitorer les requetes api server par source

exactement. audit logs de l'api server pour voir les top talkers. qui ecrit le plus dans etcd

on a trouvé un bug dans notre custom admission controller qui créait plein d'objets temporaires inutiles. une fois fix ça va mieux. merci les gars