KubeShark : Détecter les YAML Kubernetes hallucinés par l'IA

Lukas Niessen a créé KubeShark, une compétence Kubernetes pour Claude Code et Codex qui résout un problème spécifique : les LLM hallucinent lorsqu'ils écrivent du YAML Kubernetes. Ils génèrent des versions d'API obsolètes, oublient les contextes de sécurité, créent des Services qui ne sélectionnent aucun pod, configurent mal les sondes, omettent les demandes de ressources et produisent des déploiements qui semblent valides mais échouent sous charge. Kubernetes est impitoyable ici : un sélecteur de Service erroné ou une sonde de vivacité cassée s'applique avec succès mais provoque des échecs silencieux ou des redémarrages de pods.

Workflow axé sur les modes de défaillance

KubeShark n'est pas un simple recueil de bonnes pratiques. Avant de générer du YAML, l'agent doit raisonner sur ce qui peut mal tourner dans six domaines de défaillance :

Valeurs par défaut non sécurisées des charges de travail
Privation de ressources
Exposition réseau
Extension des privilèges
Déploiements fragiles
Dérive des API

Ce n'est qu'après ce raisonnement qu'il produit des manifests, des chartes Helm, des overlays Kustomize, des RBAC, des NetworkPolicies ou des étapes de validation. L'idée est de rendre les détails opérationnels incontournables plutôt que facultatifs.

Erreurs spécifiques détectées

Sélecteur de Service ne correspondant pas aux étiquettes du Deployment
Ingress utilisant une version d'API supprimée dans Kubernetes moderne
Deployment fonctionnant en root sans contexte de sécurité
Sonde de vivacité pointant vers une base de données externe
ClusterRoleBinding alors qu'un RoleBinding suffirait
StatefulSet supposant que les PVC disparaissent lors de la réduction d'échelle
Template Helm générant un YAML valide avec une API Kubernetes erronée
Patch Kustomize ciblant silencieusement la mauvaise ressource

Architecture économe en tokens

Le fichier principal SKILL.md de KubeShark reste compact et procédural. Les connaissances plus approfondies résident dans des fichiers de référence ciblés, chargés uniquement lorsque cela est pertinent — par exemple, les conseils sur les sondes ne chargent pas les règles RBAC, et les tâches Helm ne chargent pas les conseils NetworkPolicy. Cela évite le gaspillage de tokens et réduit les risques que l'agent mélange des concepts non liés.

La compétence prend également en charge des contextes spécifiques à la plateforme via le Conditional Reference Retrieval. Elle détecte des signaux comme IRSA, Karpenter, Azure Workload Identity, GKE Autopilot, OpenShift Routes, ApplicationSet, HelmRelease, ServiceMonitor ou OpenTelemetry Collector, puis charge la référence correspondante. Cela permet une génération et une révision de manifests adaptées à EKS, AKS, GKE, OpenShift, GitOps ou observabilité — uniquement lorsque le contexte est pertinent.

Les valeurs par défaut penchent vers la sécurité : normes de sécurité des pods, vérifications de cohérence entre ressources, alignement étiquettes/sélecteurs/ports, évitement des API obsolètes et conseils de rollback sont intégrés.