Principe du pipeline Jev‑driven

Le pipeline présenté par SREGym exploite Jev, un moteur de décision basé sur des choix multiples, pour automatiser le diagnostic d’incidents Kubernetes. Au lieu d’un agent LLM, le système collecte d’abord les objets du cluster (déploiements, événements, logs récents, métriques) puis les transforme en résumés structurés. Ces résumés sont fournis à Jev qui, à chaque étape, sélectionne le composant le plus probable, le type d’objet fautif et les preuves les plus pertinentes. Le processus itère tant que les preuves ne soutiennent pas l’hypothèse retenue.

Mécanisme de collecte et d’interrogation

Le collecteur lit les objets Kubernetes et regroupe les observations par composant. Pour le cas mutating_webhook_resource_limits_social_network, il a identifié 27 déploiements et a produit le résumé suivant :

Component: deployment/nginx-thrift
Signals: Pod was OOMKilled and restarted.
Live Pod memory limit: 16Mi (Deployment template: 256Mi).
Matching Pod-creation webhook: gatekeeper-mutating-webhook-configuration.

Jev a alors répondu « deployment/nginx-thrift » comme origine probable et « admission_webhook » comme type d’objet. Le pipeline a enrichi le contexte avec 26 items de preuve, dont deux exemplaires :

E6: The nginx-thrift Pod was OOMKilled.
E10: The Pod has a 16Mi memory limit, although its template says 256Mi. gatekeeper-mutating-webhook-configuration matches this Pod.

Sur la base de ces éléments, Jev a indiqué que l’objet gatekeeper-mutating-webhook-configuration était à l’origine du changement de limite mémoire, ce qui a conduit à la rédaction du rapport de diagnostic.

Résultats expérimentaux

Le protocole a été exécuté sur 21 scénarios de défauts SREGym‑Lite, chaque scénario testé cinq fois avec Jev 1.13.0. Au total, 105 diagnostics ont été générés. Le critère de validation était un score ≥ 0.70 selon le ruban de neuf questions de SREGym, évalué par le modèle gpt‑6‑astra. Les chiffres clés :

  • Passages : 80/105 (76,2 %)
  • Temps médian de diagnostic : 14,6 s
  • Appels Jev totaux : 252, soit 2,4 appels par tentative
  • Latence moyenne de l’API Jev : 0,53 s
  • Tokens d’entrée consommés : 3,48 M, coût d’inférence estimé à 0,15 $

Les performances se sont avérées très homogènes : pour chaque défaut, les cinq exécutions ont toutes réussi ou toutes échoué, et 18 défauts ont reçu le même score dans toutes les tentatives, indiquant une stabilité du processus de décision.

Limites et perspectives

Les 5 défauts qui ont systématiquement échoué révèlent les limites actuelles du modèle : absence de preuves suffisantes pour distinguer l’origine, ou besoin d’une exploration multi‑candidats simultanée. Le pipeline examine les candidats un à un, ce qui peut empêcher la découverte de relations complexes entre plusieurs composants. De plus, le coût d’inférence, bien que faible (0,15 $), reste proportionnel au nombre d’appels Jev, ce qui pourrait devenir un facteur limitant à grande échelle. Les auteurs suggèrent d’enrichir le collecteur avec des corrélations temporelles et d’explorer des stratégies de sélection de candidats parallèles afin d’accroître le taux de réussite au‑delà des 76 % actuels.