Latence etcd délirante avec du gros churn K8s et CSI

ouais classique les leader elections ça pue. t'as des métriques sur `etcd_server_proposals_failed_total` ou `etcd_server_leader_changes_total` et le `etcd_mvcc_db_total_size_in_bytes` il grossit de ouf

les `proposals_failed` sont à quelques milliers par jour et les `leader_changes` genre 5-10 par heure. le `db_total_size` est à 20GB alors que ça devrait être moins de 10GB. ça semble s'accumuler même avec la compaction par défaut

20GB c'est déjà gros t'as une idée de ce qui prend de la place genre bcp de CRDs ou des objects persistents pour tes PVCs qui sont pas nettoyés correctement

on a pas mal de crds pour le csi driver mais c'est surtout les `pv` et `pvc` objets qui churnent. chaque job crée un nouveau pvc temporaire

ok si c'est les objets PV/PVC en churn regarde ta politique de `reclaimPolicy` sur tes `StorageClass` c'est ptete `Retain` au lieu de `Delete` ce qui laisse des PVs orphelins et ça fait gonfler etcd

non on est bien en `delete` pour nos classes de stockage. les `pv` sont bien delete après les jobs mais l'historique dans etcd semble persister ou la compaction galère

la compaction c'est tous les combien chez toi par défaut c'est 5 minutes. et le `etcd_mvcc_blobs_total_bytes` il est aussi en hausse

compaction est par défaut ouais. `blobs_total_bytes` est aussi en hausse. j'ai l'impression que le disque I/O est pas top non plus pour etcd pourtant c'est des NVMe dédiés

I/O disk c'est super critique pour etcd. fais un `fio` sur le volume etcd avec des petits blocs et du `fsync` pour voir les vraies latences en écriture synchrone. et tu peux augmenter `etcd_max_txn_ops` si t'as bcp de transactions simultanées

j'ai lancé un `fio` sur le volume etcd les latences en écriture synchrone sont à 20-30ms ce qui est affreux pour du NVMe. ça devrait être sous la milliseconde

20-30ms c'est la mort pour etcd. c'est quoi ton CSI driver et ton backend de stockage. y'a ptete un bug dans le driver ou une config réseau / raid qui limite les perfs

le driver CSI est custom comme j'ai dit c'est pour du stockage hyperconvergé et le support nous dit que c'est ok. mais je suspecte le driver ou l'intégration k8s avec le driver

si le `fio` est pourri c'est une piste solide. ton CSI driver il utilise des volumes block direct ou des filesystems montés sur les workers et si c'est des FS comment ils sont montés `noatime` `nodiratime` `barrier=0` ça peut aider

c'est des volumes block formatés en XFS montés avec `noatime`. on avait pas touché à `barrier`. je vais voir si le CSI driver a des options pour optimiser la latence de ses volumes

demande au support du CSI s'ils ont des options genre `fsGroupChangePolicy: Always` ou `ReadOnlyMany` pour alléger les opérations sur etcd. parfois les drivers font des opérations de validation en background qui tapent fort sur le control plane

j'ai contacté le support du CSI driver et ils m'ont confirmé une option `optimizeStorageIO: true` pour les volumes etcd qu'on avait pas activé. après l'avoir mis en place et recréé les volumes les latences `fio` sont tombées à 0.5ms. etcd respire enfin et plus de leader elections. c'était bien le stockage bas niveau via le CSI. merci pour les pistes encore