etcd lent avec beaucoup de writes sur k8s

salut check tes métriques disk i/o sur le serveur etcd même si tu penses que c'est ok. regarde le `wal_fsync_duration_seconds` et `backend_commit_duration_seconds` dans prometheus. des fois c'est pas le througput mais la latence

oui carrément la latence est critique pour etcd. tu es sur quel type de stockage ? hdd ssd nvme ? et le réseau entre tes membres etcd est clean ? pas de pertes de paquets ?

on est sur du ssd gp2 sur aws. le réseau est ok entre les membres ping est <1ms. le `wal_fsync_duration_seconds` est souvent au-dessus de 50ms et des pics à 200ms. `backend_commit_duration_seconds` suit le même pattern. ça sent le disque non ?

clairement ça sent le disque. gp2 c'est bien mais si t'as beaucoup d'iops et que t'es pas provisionné assez ou que ton burst credit est mort ça va ramer sec. as-tu regardé les métriques d'iops et de débit de ton volume ebs ?

oui et check aussi le `snapshot-count` et `auto-compaction-retention` de ta config etcd. un snapshot trop fréquent ou une compaction mal tunée ça peut impacter le i/o

les iops ebs sont dans les choux quand ça arrive genre on tape le max provisionné. `snapshot-count` est à 10000 par défaut. `auto-compaction` à 1h en revision mode. ptete réduire `snapshot-count` ?

10000 c'est pas mal en vrai. j'augmenterais plutôt les iops du volume ebs direct ou passer sur du gp3 en provisionnant bien. ou même io2 block express si le budget le permet. gp2 si t'es hors burst c'est la mort

pour `wal_fsync_duration_seconds` si t'as un noyau linux récent tu peux regarder du côté de `io_uring` pour optimiser les écritures asynchrones. mais c'est un peu plus avancé à configurer

avant d'aller sur `io_uring` je pense qu'un simple upgrade de volume ebs ou des instances avec du local nvme serait plus simple et efficace. on parle de etcd, la stabilité c'est primordial

totalement d'acc avec user 2. la solution la plus simple c'est souvent la meilleure pour ce genre de truc. un `etcdctl check perf` peut aussi t'aider à confirmer que le bottleneck c'est bien le disk i/o

ok je vais tester `etcdctl check perf`. pour le moment on a up le volume gp2 à 3000 iops et ça a un peu amélioré les choses mais c'est pas parfait. les pics sont moins hauts mais toujours là

si les pics sont toujours là même après avoir augmenté les iops ça peut venir d'autres choses. regarde les logs pour des `leader election timeout` ou des `network partition` warnings

non pas de warnings de leader election. les membres etcd se parlent bien. `etcdctl check perf` confirme que le `write throughput` est limité par le `disk sync duration`.

bon là c'est clair faut taper fort sur le stockage. si tu peux pas aller sur io2 block express direct le nvme local est une excellente option mais attention à la réplication de etcd si tu perds une instance

les instance types comme i3/i3en/m5d avec du nvme local c'est le top pour etcd. la latence est imbattable. juste gère bien tes volumes etcd avec un `data-dir` sur le nvme et `member-remove` si une instance meurt

on vient de migrer sur des instances i3 avec nvme local. les métriques `wal_fsync_duration_seconds` sont tombées en dessous de 1ms quasi tout le temps. l'api server est stable maintenant.

franchement passer sur du nvme local a tout changé. plus un seul warning de slow apply. thx à tous pour les tips !