KubeShark: Eine Kubernetes-Fähigkeit für Claude Code und Codex, um halluziniertes YAML abzufangen

Lukas Niessen hat KubeShark entwickelt, eine Kubernetes-Fähigkeit für Claude Code und Codex, die ein spezifisches Problem angeht: LLMs halluzinieren beim Schreiben von Kubernetes-YAML. Sie generieren veraltete API-Versionen, vergessen Sicherheitskontexte, erstellen Services, die keine Pods auswählen, konfigurieren Probes falsch, lassen Ressourcenanfragen weg und produzieren Rollouts, die gültig aussehen, aber unter Last versagen. Kubernetes ist hier unnachgiebig – ein falscher Service-Selector oder eine defekte Liveness-Probe werden erfolgreich angewendet, verursachen aber stille Ausfälle oder Pod-Neustarts.

Fehlermodus-zuerst-Workflow

KubeShark ist keine Ansammlung bewährter Verfahren. Bevor YAML generiert wird, muss der Agent darüber nachdenken, was in sechs Fehlerdomänen schiefgehen kann:

• Unsicher Workload-Standards
• Ressourcenverknappung
• Netzwerkfreigabe
• Berechtigungsausbreitung
• Fragile Rollouts
• API-Abweichung

Erst nach dieser Überlegung werden Manifests, Helm-Charts, Kustomize-Overlays, RBAC, NetworkPolicies oder Validierungsschritte erstellt. Die Idee ist, betriebliche Details unvermeidbar zu machen, anstatt sie zu überspringen.

Spezifische erkannte Fehler

• Service-Selector, der nicht zu Deployment-Labels passt
• Ingress mit einer in modernem Kubernetes entfernten API-Version
• Deployment, das als root läuft, ohne Sicherheitskontext
• Liveness-Probe, die eine externe Datenbank prüft
• ClusterRoleBinding, wo ein RoleBinding ausreichen würde
• StatefulSet, das annimmt, dass PVCs beim Verkleinern verschwinden
• Helm-Template, das gültiges YAML mit falscher Kubernetes-API rendert
• Kustomize-Patch, das stillschweigend die falsche Ressource anvisiert

Token-effiziente Architektur

Die Hauptdatei SKILL.md von KubeShark bleibt kompakt und prozedural. Tieferes Wissen liegt in fokussierten Referenzdateien, die nur bei Bedarf geladen werden – zum Beispiel lädt Probe-Anleitung keine RBAC-Regeln, und Helm-Aufgaben laden keine NetworkPolicy-Anleitung. Dadurch wird Token-Verschwendung vermieden und die Wahrscheinlichkeit verringert, dass der Agent unzusammenhängende Konzepte vermischt.

Die Fähigkeit unterstützt auch plattformspezifische Kontexte über Conditional Reference Retrieval. Sie erkennt Signale wie IRSA, Karpenter, Azure Workload Identity, GKE Autopilot, OpenShift Routes, ApplicationSet, HelmRelease, ServiceMonitor oder OpenTelemetry Collector und lädt dann die passende Referenz. Dies ermöglicht EKS-bewusste, AKS-bewusste, GKE-bewusste, OpenShift-bewusste, GitOps-bewusste oder observability-bewusste Manifest-Generierung und -Überprüfung – nur wenn der Kontext relevant ist.

Die Voreinstellungen tendieren zur Sicherheit: Pod-Sicherheitsstandards, Ressourcenübergreifende Konsistenzprüfungen, Label/Selector/Port-Ausrichtung, Vermeidung veralteter APIs und Rollback-Anleitung sind eingebaut.

Zielgruppe

Plattformingenieure, SREs, DevOps-Ingenieure und alle, die Claude Code oder Codex für Kubernetes-Arbeiten verwenden.