18 commentaires
check la compaction etcd. si t'as pas de compaction régulière ou si elle est pas finie à temps ça explose la db etcd. et regarde ton wal_dir et data_dir sur des disques séparés c'est mieux
ouais la compaction est auto. je l'ai forcée manuellement une fois ça a rien changé. wal_dir et data_dir sur le même volume pour l'instant
t'as combien de membres etcd ? et le network c'est bon ? genre pas de latence intra-cluster. check etcd_network_peer_round_trip_time_seconds
3 membres. la latence réseau inter-nœuds est genre 0.5ms. c'est pas ça
quelle version de k8s/etcd ? y'a eu des fixs sur les versions récentes. et ton tuning disque c'est quoi ? xfs ext4 ? noatime ?
k8s 1.25 etcd 3.5. ext4 avec noatime. rien de spécial sur le tuning
regarde etcd_disk_wal_fsync_duration_seconds et etcd_disk_backend_commit_duration_seconds. c'est souvent le bottleneck. si t'es sur des instances trop petites ou avec des bursting credits utilisés c'est mort
les wal_fsync sont genre 10-20ms. pas cool du tout. et backend_commit pareil
10-20ms c'est énorme. c'est sensé être sous la milliseconde. tes gp3 sont-ils saturés en iops/débit ? t'as pas de read replicas sur tes volumes ?
non pas de read replicas. les iops sont genre 500-800 sur un volume qui peut faire 3000. c'est bizarre
si t'es sur des instances avec des credits bursting type t3 t4g t'es ptete en train de taper le fond. essaie de passer sur du m ou du c. ou augmenter la taille du volume gp3 pour avoir plus d'iops de base
on est sur des m5.large. ça devrait être ok. j'ai regardé les métriques disque. les iops write sont bas mais les latences sont hautes. ptete un problème de queue length coté os ou block device
t'as des snapshots réguliers sur ces volumes gp3 ? ça peut impacter les perfs quand un snapshot est en cours
ouais y'en a un toutes les 6h. je vais tenter de le désactiver pour voir pendant une heure
si tu vois une amélioration significative pendant l'arrêt des snapshots c'est ta cause. faut revoir ta strat de backup ou les fenêtres de snapshot
arrêt des snapshots. wal_fsync descend à 2ms. backend_commit aussi. c fou. les métriques etcd reviennent au vert
bon ben voilà le coupable. gp3 avec snapshots trop fréquents et volume trop petit pour la charge d'écriture aléatoire d'etcd. merci pour le retour
franchement je m'attendais pas à ça. on va revoir la taille de nos volumes et la fréquence des snapshots. thx les gars pour l'aide précieuse !
Laisser une réponse
Vous devez être connecté pour poster un message !
Salut les techs ! on a un cluster k8s avec pas mal d'écritures genre 500 req/s sur l'api. etcd commence à ramer de ouf le qps chute la latence explose. le dispo est ok les métriques iops sont pas folles. on est sur ssd gp3 sur aws. ya un truc que je rate avec etcd ou k8s ?