etcd perf en PLS avec mon operator custom + istio

salut! déjà tu as regardé combien de watches ton operator fait sur etcd? un operator mal codé peut spammer etcd de requêtes list/watch. istio en fait déjà pas mal de base.

ouais y'a pas mal de CRD istio c'est clair. mon operator watch principalement des secrets et des configmaps pour sa config. c'est des objets standards ça devrait pas impacter autant non?

pas forcément. même si c standard si tu en as des milliers ou si les watches sont mal gérées ça peut faire bobo. t'as les metrics `etcd_object_counts`? genre via un `kubectl get --raw "/metrics" | grep etcd_object_counts`

les counts sont ok pour les secrets/configmaps. pas des millions. par contre les `etcd_request_duration_seconds_bucket` montrent des pics de latence réguliers pour les requêtes de lecture.

istio lui-même utilise bcp de watches sur les configmaps et secrets pour ses policies et ses configurations. si ton operator fait pareil, ça peut créer une tempête de lecture sur etcd, surtout si les watchers sont pas optimisés côté client.

t'as des webhooks mutation ou validation configurés pour ton operator? un webhook synchrone qui prend du temps à répondre peut complètement freezer le control plane et donc les appels à l'API K8s.

ah oui bien vu j'ai un webhook de validation pour mes CRDs qui vérifie des trucs assez complexes avant de laisser passer l'objet. j'y ai pas pensé.

voilà c'est sûrement ça. si ton webhook fait des appels externes ou des traitements lourds, chaque création/maj de CRD via ton operator va bloquer le kube-apiserver le temps de la validation. regarde les logs du controller-manager et du kube-apiserver, tu devrais voir des délais liés aux webhooks.

et aussi la `resyncPeriod` de ton operator. si elle est trop courte (genre quelques secondes) et que ton operator gère un scope large, il va spammer etcd avec des listes régulières même si rien n'a changé. ça peut aggraver le souci.

la `resyncPeriod` est à 30s. c'est la valeur par défaut pour les operators go non? je pense pas que ce soit ça le souci.

même avec 30s, si tu as des centaines de pods créés/updatés avec istio, chaque pod doit passer par les admission webhooks, et ça génère bcp de trafic etcd pour les secrets/configmaps qu'istio injecte ou référence. c un effet combiné.

le plus simple pour tester c'est de désactiver temporairement ton `ValidatingWebhookConfiguration` et voir si l'api K8s retrouve la patate. si c'est le cas, t'as ta réponse.

ok je tente de désactiver le webhook de validation de mon operator là tout de suite.

PUTAIN C'EST ÇA! l'API K8s est redevenue super fluide. mon webhook faisait des appels externes pour vérifier des politiques et ça prenait trop de temps. c'était pas optimisé du tout.

classique. les webhooks doivent être ultra légers et rapides. toute logique lourde doit être déportée dans le controller lui-même qui agit asynchronement après la création de l'objet.

ou si la validation n'est pas strictement bloquante, tu peux utiliser `failurePolicy: Ignore` dans ton `ValidatingWebhookConfiguration`, mais attention ça peut laisser passer des configs invalides.

non il faut que ça bloque. je vais revoir l'architecture de mon webhook pour qu'il soit ultra rapide ou que la logique de validation complexe soit faite ailleurs. gros merci la team pour le coup de main c nickel!