Degradation etcd sous un operator K8s custom

salut! 500ms c'est chaud t'as regardé les métriques latency p99 pour les writes sur etcd? souvent un operator mal écrit peut spammer etcd avec des updates trop fréquentes ou des payloads énormes

ouais les p99 writes sont à 450ms. l'opérateur gère des CRD avec des configs genre 10-20KB par objet pas énorme. par contre il update un bon paquet d'objets toutes les 5-10s si y'a un changement dans l'infra

10-20KB par objet c'est pas rien si tu en as des centaines. et 5-10s c'est une fréquence pas négligeable. t'as jeté un œil à mvcc_keys_total ou mvcc_compaction_pauses_total? ça peut donner une idée du garbage collection d'etcd

mvcc_keys_total est stable mais mvcc_compaction_pauses_total on a des spikes réguliers et ça corréle avec les ralentissements. c'est ça le souci?

clairement les pauses de compaction sont un signal fort que etcd galère à nettoyer l'historique. ça veut dire que ton operator génère bcp de révisions. faut optimiser les writes ou réduire la rétention historique

t'as essayé de réduire les events au lieu de faire des updates full state à chaque fois? ou de batcher les updates pour plusieurs crd en une seule transaction?

batcher les updates c'est une bonne idée pour les CRD qui changent en même temps. mais pour la rétention etcd on est déjà au minimum pour nos besoins. faut que je revois comment l'operator écrit

vérifie aussi si ton operator utilise des watch en continu sur trop de ressources ou s'il fait des list tous les X temps sur des gros objets. les lectures aussi peuvent impacter la perf du leader

il fait des list pour des reconciliations complètes toutes les 30s. c'est peut-être ça le combo. grosses writes fréquentes et list globales en plus

le list global sur des crd volumineuses est un antipattern. essaie de te baser sur des événements plus ciblés. utilise des index si possible sur tes crd si tu as des champs récurrents pour tes requêtes

ok je vais refactorer l'operator pour qu'il utilise des informers avec des filtres plus précis au lieu des list full. et je vais essayer de batcher les updates des CRD qui sont souvent modifiées ensemble

pense aussi à l'impact du garbage collection du client-go lui-même si ton operator manipule bcp d'objets en mémoire. ça peut créer des pauses gc

j'ai refactoré l'operator pour moins de list et plus de watch ciblés. j'ai aussi revu les updates pour batcher les petites modifications. le p99 est revenu sous les 30ms et plus de spikes de compaction pause. thx pour les pistes