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.

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

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.

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.

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.

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.