Ich betreibe ein stark angepasstes Claude-Code-Setup und habe im letzten Jahr darunter zwei Dinge gebaut, die unmittelbar zu dem passen, was Arseny Zinchenko in seinem Beitrag über einen Kubernetes-Debugging-Agenten beschreibt: ein VictoriaMetrics-Skill auf Basis von sechs Bash-Skripten, das ich gegen den Live-Cluster vm.ethinking.xyz durchgespielt habe, und ein mehrwöchiges EKS-Rightsizing-Projekt (Phasen A/B, OOM-Jagd, Limit-Klassen und JAVA_OPTS). Deshalb habe ich seinen Text nicht als Technologieüberblick gelesen, sondern als Beschreibung einer Weggabelung, an der ich selbst gestanden habe.
Zinchenko baut einen read-only Pod-Debugging-Agenten, verpackt ihn in ein Claude-Code-Plugin mit eigenem Marktplatz, bindet die offiziellen VictoriaMetrics-Skills für Metriken, Logs und Alerts ein — und verzichtet bewusst auf MCP zugunsten von Skills. Das Ziel formuliert er entwaffnend offen: einen Agenten zu haben, dem ein Entwickler die Frage «why the hell did that Kubernetes Pod crash» stellen kann. Und er gibt vorab zu, dass dies hinsichtlich der Instruktionen noch ein PoC ist. Das ist der richtige Rahmen, und damit will ich nicht streiten — ich möchte eine Engineering-Achse herauspräparieren, die der Artikel anschneidet, aber nicht zu Ende führt.
Meine Position: Beide Schemata sind richtig, aber an unterschiedlichen Punkten
Die These ist einfach. Zinchenko gibt dem LLM Vorlagen für MetricsQL und LogsQL und lässt den Agenten die konkreten Abfragen spontan zusammensetzen. In meinem eigenen VM-Skill habe ich genau das Gegenteil getan: Jeder HTTP-Aufruf läuft durch Bash-Skripte, und der Agent sieht ausschließlich voraggregierte Ausgaben und arbeitet damit. Das ist kein „besser" gegen „schlechter" — es sind zwei Enden einer Achse: Flexibilität für Ad-hoc-Untersuchung gegen Reproduzierbarkeit und Auditierbarkeit.
Sein Ansatz gewinnt dort, wo die Abfrage im Voraus unbekannt ist: Man setzt sich hin, um „warum startet Grafana neu" zu debuggen (so hat er übrigens die Ursache seiner eigenen Neustarts gefunden), und braucht die Freiheit, MetricsQL fünfmal pro Minute umzuformulieren. Mein Ansatz gewinnt dort, wo der Durchlauf wiederholbar und im Nachhinein erklärbar sein muss: Dasselbe Skript liefert dasselbe Aggregat, der Reviewer sieht genau das, was der Agent gesehen hat, und eine Woche später lässt sich die Zahl reproduzieren. Genau deshalb hat mein Schema die A/B-Rightsizing-Phasen überlebt — dort darf der Agent nicht jedes Mal eine neue Abfrage erfinden: Man braucht eine Methodik, die über Dutzende Services hinweg vergleichbare Zahlen gegen eine OOM=0-Basislinie liefert.
Wo er recht hat — und das ist keine Kleinigkeit
Das zentrale Argument des Artikels teile ich vollständig. Zinchenko trifft den Punkt, dass MCP nicht das Wissen trägt, hinter dem man eigentlich her ist. Seine Formulierung sitzt: «MCP only defines how to execute the query - not the query structure itself», und weiter — «the agent/LLM still decides on the query and the filters». Ein typisiertes query(query: string) validiert, dass man einen String übergeben hat, aber den MetricsQL-String selbst setzt nach wie vor das Modell zusammen. Ein Skill hingegen kann tragen, was MCP schlicht nicht kann: welcher Stream-Filter genau in unserem VictoriaLogs gilt, welches Pflicht-Label cluster in unserem VictoriaMetrics gilt, welche Korrelationen CrashLoopBackOff von OOMKilled unterscheiden. Das ist Umgebungskontext, keine Funktionssignatur.
Bei kubectl hat er ebenfalls recht: Es in MCP zu kapseln bringt wenig, weil jedes Modell die kubectl-Syntax auswendig kennt und die Cluster-Spezifika genügt es in die SKILL.md zu legen. Und die Use-Case-Grenze zieht er ehrlich — «we're building a read-only agent that debugs, not deploys», weshalb ein fertiges Deploy-Skill nicht zu ihm passt. Seine Zusammenfassung der Wahl — «Bash + curl + our own skill with our context + official VictoriaMetrics skills» — ist für explorative Fehlersuche völlig gerechtfertigt.
Wo das Schema zu kurz greift: read-only per Blacklist ist schwächer, als es aussieht
Hier beginnt mein Haupteinwand, und er ist technischer Natur. Zinchenkos read-only-Garantie ruht auf deny-tools — einer Glob-Blacklist: Sie verbietet kubectl delete, *curl* -X *, Pipes in sh/bash, Umleitungen >/>>, rm/mv/cp. Die Liste sieht solide aus, aber eine Glob-Muster-Blacklist ist ein Spiel, das der Verteidiger stets verliert. Ein Schreibvorgang in eine Datei ohne das Zeichen > erfolgt über tee. Ein POST ohne -X erfolgt mit --data in einer Form, die das Muster verfehlt hat, oder über ein Here-String und Kommandosubstitution. xargs und env tragen ein verbotenes Kommando in einer Hülle, die die Blacklist nie inspiziert. Jeder übersehene Vektor ist ein Loch, und man kann sie endlos einzeln stopfen.
In meinem Setup vertraue ich der umgekehrten Logik: eine Allowlist (was explizit erlaubt ist, ist zulässig, alles andere ist standardmäßig verboten) plus ein Intent-Level-Gate für Produktionsaktionen — jedes kubectl exec/port-forward, SSH in die Prod oder terraform apply erfordert eine explizite, namentliche Freigabe in der laufenden Sitzung. Eine Allowlist leidet nicht unter dem Problem „einen weiteren Vektor zu verbieten vergessen", denn standardmäßig ist alles verboten.
Aber ich nenne offen eine Nuance, die der Artikel nicht betonen muss: Wir arbeiten unter unterschiedlichen Bedrohungsmodellen. Sein Agent ist read-only Debug auf einem Dev-Cluster, wo die Fehlerkosten gering sind und die Blacklist die groben Ausrutscher des Modells abfängt. Mein Gate ist für Write/Prod gebaut, wo die Fehlerkosten ein Incident sind. Das ist also kein Verriss seines Designs — es zeigt die Obergrenze: deny-tools ist gut als Defence-in-Depth und schlecht als alleinige Garantie, sobald die Vertrauensschwelle gegenüber der Umgebung steigt.
Was in der Praxis zu tun ist
Die Wahl zwischen den beiden Schemata würde ich auf eine einzige Frage reduzieren: Ist der Durchlauf einmalig oder wiederholbar? Für untersuchendes Debugging — „warum ist dieser Pod gerade jetzt abgestürzt" — nehmen Sie Zinchenkos Variante: Abfragevorlagen plus die Freiheit des Modells, sie zu kombinieren, ist schneller und verlangt nicht, für jeden neuen Datenschnitt ein Skript zu schreiben. Für alles, was Sie reproduzieren, reviewen oder gegenüber einem Kunden verteidigen müssen — kapseln Sie das HTTP in Skripte und füttern Sie den Agenten mit einem fertigen Aggregat; dann ist die Ausgabe deterministisch und das Audit trivial.
Die A/B-Phasen haben mich davon konkret überzeugt: Wenn Rightsizing über Wochen läuft, über Dutzende Services, mit Limit-Klassen und JAVA_OPTS-Tuning hin zu einer OOM-freien Basislinie, wird ein Agent, der Abfragen zusammensetzt, zur Quelle unvergleichbarer Zahlen. Das Skript ist jener billige, langweilige, zuverlässige Teil, über den ich bereits in „The Harness Is the Cheap Part" geschrieben habe: Das Teure und Interessante ist das Schließen des Modells, während Reproduzierbarkeit genau aus dem kommt, was Sie in der Halterung festgenagelt haben.
Und der Verzicht auf MCP zugunsten von Skills für kubectl ist eine Entscheidung, die ich vorbehaltlos mitunterzeichne. Wo das Modell die Syntax ohnehin kennt, fügt eine typisierte Hülle Installationsaufwand hinzu und kein Wissen. Zinchenko hat das richtige Werkzeug gewählt; ich zeichne nur die andere Hälfte der Karte nach — den Punkt, an dem man der Flexibilität eine Reproduzierbarkeitssteuer abverlangt.