KI · 20. Oktober 2026
Auch veröffentlicht auf Português (Brasil), Français, Italiano, Svenska, Norsk, Polski, Türkçe, Русский
Kubernetes und KI-Agenten: Klare Trennung von Planung und Ausführung im Betrieb
Die Cloud-native-Infrastruktur entwickelt sich rasant, da KI-Agenten in den vergangenen achtzehn Monaten vom Nebenprojekt zu einem festen Bestandteil des Stacks geworden sind. Die Cloud Native Computing Foundation hat Agenten-Frameworks in ihre Sandbox aufgenommen, und die Kubernetes SIG Apps Gruppe hat das Agent Sandbox als Untervorhaben gestartet, um Agenten-Workloads sicher auszuführen. Plattformteams entscheiden bereits jetzt, was ein Agent in einem Live-Cluster ändern darf, meist ohne schriftliche Richtlinien und nur durch Konventionen. Diese Entwicklung zwingt die Branche dazu, die Grenzen zwischen dem deduktiven Denken der KI und der deterministischen Ausführung der Infrastruktur neu zu ziehen.
Ein Kubernetes-Operator ist darauf ausgelegt, vorhersehbar zu sein. Er gleicht Ressourcen anhand codierter Regeln aus, wiederholt fehlgeschlagene Operationen und konvergiert auf den deklarierten Zustand. Ein KI-Agent hingegen ist nützlich, wenn das gewünschte Ergebnis klar ist, der Weg dorthin aber unklar bleibt. Er kann unbekannte Situationen untersuchen, Kontext aus mehreren Systemen sammeln, Abwägungen treffen und einen Handlungsplan vorschlagen. Ein sichereres architektonisches Muster kombiniert diese Stärken, indem der Agent das Denken und den Kontext bereitstellt, während Operatoren und Policy-Engines die Kontrolle über die Ausführung behalten.
Das Open-Source-Projekt kagent aus der CNCF-Sandbox bietet ein konkretes Beispiel für dieses Muster. Es führt KI-Agenten als Kubernetes-Ressourcen aus und verbindet sie mit Kubernetes, Helm, Observability und benutzerdefinierten Werkzeugen. Ein Agent kann Ressourcen inspizieren, Protokolle und Ereignisse abrufen, Metriken abfragen, Dokumentation konsultieren und spezialisierte Agenten koordinieren. Nicht alle Werkzeuge sollten jedoch frei ausführbar sein. Unempfindliche Leseoperationen können automatisch ablaufen, während Änderungen wie das Anwenden, Patchen oder Löschen von Ressourcen eine explizite Genehmigung erfordern können. Diese Trennung ermöglicht es dem Agenten, eine breite Untersuchung durchzuführen, ohne einem unsicheren Denkprozess uneingeschränkte Autorität über den Cluster zu geben.
Der resultierende operative Zyklus verläuft in den Schritten beobachten, diagnostizieren, vorschlagen, genehmigen, ausgleichen und verifizieren. Die ersten drei Schritte profitieren vom agentischen Denken, während Kubernetes und seine Operatoren den Ausgleichsschritt übernehmen. Die Verifizierung schließt den Kreislauf, ohne anzunehmen, dass eine erfolgreich angenommene Änderung das beabsichtigte Ergebnis erzielt hat.
Ein Beispiel zeigt den Unterschied deutlich: Karpenter provisioniert Kapazität erfolgreich, aber das Plattformteam sieht unterausgenutzte Knoten, langsame Konsolidierung oder Spot-Wechsel. Karpenter ist bereits ein Operator, der Scheduling-Einschränkungen bewertet und NodePools sowie NodeClaims ausgleicht. Ein auf kagent basierender Betriebsagent sollte über Karpenter arbeiten. Er kann die Konfiguration von NodePool und EC2NodeClass, ausstehende Pods, Kubernetes-Ereignisse, Pod Disruption Budgets, Karpenter-Protokolle und relevante Prometheus-Metriken inspizieren. Er kann dann fragen, warum das beobachtete Verhalten vom Ziel des Teams abweicht. Die Untersuchung könnte ergeben, dass ein Pod Disruption Budget die Konsolidierung blockiert oder dass consolidateAfter für eine burstige Workload zu aggressiv ist. Der Agent sollte keine vage Empfehlung wie die Optimierung des NodePool abgeben, sondern die Beweise präsentieren, den Kompromiss identifizieren und eine enge Konfigurationsänderung erstellen. Die Änderung durchläuft dann ein Genehmigungs- oder Policy-Gate. Nach der Genehmigung gleicht Karpenter mit seiner bestehenden Logik aus, und der Agent beobachtet das Ergebnis über einen definierten Zeitraum.