kagent Assess

Überblick

kagent verbindet Kubernetes-Operations mit AI-Agents für Diagnostik, Remediation-Vorschläge und Day-2-Automation (kagent).

Assess zunächst mit Read-only-RBAC. Auto-Remediation gehört erst dann in Produktionscluster, wenn Aktionen idempotent, freigabepflichtig und auditiert sind.

Adoptionssignale

  • CNCF-Status: kagent wurde am 22. Mai 2025 als Sandbox-Projekt in die CNCF aufgenommen, rund zwei Monate nach der Ankündigung durch Solo.io im März 2025 (CNCF-Projektseite, 100 Tage kagent).
  • Contributor-Basis: In den ersten 100 Tagen erreichte kagent über 100 Contributors, mehr als 85 % davon außerhalb von Solo.io; im September 2026 hatte das Repository rund 3.900 Stars und 800 Forks (100 Tage kagent, kagent GitHub).
  • Aktive Entwicklung Richtung 1.0: v0.10.2 ist das aktuelle stabile Release (23. September 2026), die v1.0.0-Alphas ergänzen Sandbox-Runtimes und explizite Agent-Sessions (kagent Releases).
  • Kommerzielle Unterstützung: Solo.io bietet Solo Enterprise for kagent mit globalen SLAs und Architekturberatung durch die Maintainer an und kombiniert kagent mit agentregistry zur Katalogisierung von Agents, MCP-Tools und Skills (kagent Enterprise, Solo.io AI Agents).
  • Sicherheitsbausteine: Agents können Tools unter requireApproval aufführen, sodass Apply-, Patch- und Delete-Aufrufe auf eine menschliche Entscheidung warten, während Read-only-Aufrufe frei laufen (kagent Human-in-the-Loop).

Risiken

  • Agent mit Cluster-Credentials. Ein Agent, der k8s_apply_manifest oder k8s_delete_resource mit einem weit gefassten Service Account aufrufen darf, macht aus einer Prompt Injection in Logs, Events oder Issue-Texten eine Cluster-Änderung. Die Freigabe ist opt-in: Tools laufen standardmäßig ohne Bestätigung (kagent Human-in-the-Loop).
  • Reifegrad. Die CNCF beschreibt Sandbox-Projekte als experimentell und noch nicht breit in Produktion erprobt, die CNCF-Projektseite bewertet die Projektgesundheit von kagent mit „Fair (67)“, und die API ändert sich auf dem Weg zu 1.0 noch (CNCF Sandbox-Projekte, CNCF-Projektseite, kagent Releases).
  • Dünne Produktionsevidenz. Öffentliches Material besteht aus Community-Use-Cases, Demos und Anbieterseiten, nicht aus benannten Produktions-Deployments mit Ergebnissen (100 Tage kagent).
  • Datenfluss zum Modell. Cluster-Zustand, Logs und in Tool-Ausgaben enthaltene Secrets gehen an den konfigurierten LLM-Provider, sofern kein selbst gehostetes Modell genutzt wird; für regulierte Workloads ist das relevant.

Vorteile & Nachteile

Vorteile

  • Kubernetes-natives Design: Agents, Tools und Modellkonfigurationen sind Custom Resources, die mit kubectl, GitOps und RBAC verwaltet werden; Plattform-Teams können Agent-Definitionen wie jedes andere Manifest reviewen und zurückrollen.
  • Liefert MCP-Tool-Server für Kubernetes, Istio, Helm, Argo und Prometheus, unterstützt OpenAI, Azure OpenAI, Anthropic, Vertex AI und Ollama und erzeugt OpenTelemetry-Traces für jeden Agent-Lauf.
  • Neutrale Heimat und breite Beitragsbasis: CNCF-Sandbox-Projekt seit Mai 2025 unter Apache-2.0, mit über 85 % der ersten 100 Contributors von außerhalb von Solo.io, dem ursprünglichen Entwickler.

Nachteile

  • Noch vor 1.0 (v0.10.2 stabil, v1.0.0 im Alpha-Stadium, Stand September 2026), und Sandbox ist die CNCF-Reifestufe für experimentelle, noch nicht breit in Produktion erprobte Projekte.
  • Tools laufen standardmäßig ohne Freigabe; Human-in-the-Loop für destruktive Aufrufe wie k8s_delete_resource oder k8s_apply_manifest muss pro Agent explizit deklariert werden.
  • Es wurden keine namentlich genannten Produktionsanwender oder unabhängigen Case Studies gefunden; die öffentliche Evidenz besteht aus Konferenzvorträgen, Community-Demos und dem kommerziellen Angebot von Solo.io.

Empfehlung

kagent im Assess als Read-only-Diagnoseassistent auf einem Nicht-Produktionscluster erproben: Service Account nur mit lesendem RBAC binden, Modellaufrufe an einen freigegebenen oder selbst gehosteten Provider leiten und die OpenTelemetry-Traces in den bestehenden Observability-Stack exportieren. Zu messen ist, ob die Fehlersuche gegenüber vorhandenen Runbooks und Dashboards schneller wird.

Erst danach sind schreibende Aktionen in einem Staging-Cluster zu testen, mit allen verändernden Tools unter requireApproval, namespace-gebundenen Berechtigungen und GitOps-Reconciliation (Argo CD oder Flux) als Weg für dauerhafte Änderungen. Eine Neubewertung ist sinnvoll, sobald kagent 1.0 erreicht und benannte Produktionsanwender Ergebnisse veröffentlichen; bis dahin kommt kagent für unbeaufsichtigte Remediation in Produktion nicht in Frage.

Quellen

Beratung

Vom Radar zur Umsetzung

Du hast Technologien bewertet — wir helfen dir, sie sicher und messbar in produktive Systeme zu bringen.