Degradation etcd sous un operator K8s custom

Question

yo la team! on a un operator k8s custom qui gère des centaines de CRD et depuis qq temps etcd est à la ramasse. des requêtes take 500ms au lieu de 50. ça nous freeze tout le cluster on dirait que ça bloque le leader etcd pas de compaction alarm visible
kubectl exec -it etcd-0 -c etcd -- etcdctl metrics --endpoints=localhost:2379 |
  grep -e "etcd_mvcc_db_total_size_in_bytes|etcd_mvcc_delete_total_range_count"

claudine-moreau · Answer

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

lbesson · Answer

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

qdelaunay · Answer

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

lbesson · Answer

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?

claudine-moreau · Answer

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

valerie79 · Answer

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?

lbesson · Answer

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

qdelaunay · Answer

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

lbesson · Answer

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

claudine-moreau · Answer

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

lbesson · Answer

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

valerie79 · Answer

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

lbesson · Answer

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

Degradation etcd sous un operator K8s custom

13 commentaires

Laisser une réponse

Lire et écrire dans un fichier dans le langage de programmation Go

Les différents objets et composants de Kubernetes

L'histoire du DevOps

Pourquoi et comment créer des branches sur GitLab

L'Ère de l'Observabilité Prédictive : Quand l'IA Anticipe les Pannes et Réinvente la Résilience Opérationnelle

Rejoindre la communauté