KI-Agenten ziehen auf Kubernetes um: Was kagent und OpenChoreo über den nächsten Plattform-Stack verraten

Ein Paar Open-Source-Projekte, die die Cloud-Native-Sydney-Community diesen August hervorgehoben hat, fängt eine wichtige Verschiebung in Kubernetes ein. kagent ist ein Kubernetes-natives Framework zum Erstellen, Bereitstellen und Verwalten von KI-Agenten. OpenChoreo ist eine Open-Source-Entwicklerplattform für Kubernetes, die Entwicklern und KI-Agenten höhere Abstraktionsebenen bietet, um Anwendungen und agentische Workloads zu erstellen, bereitzustellen und zu betreiben.

Das Interessante daran ist nicht einfach, dass KI in einem Kubernetes-Cluster laufen kann. Teams platzieren bereits seit Längerem Inferenzdienste, Modellserver, Vektordatenbanken und GPU-Workloads auf Kubernetes. Die neuere Frage ist, was passiert, wenn Agenten gleichzeitig Workloads und aktive Nutzer der Plattform werden.

Das macht die bestehenden operativen Grundlagen umso wichtiger. Bevor eine Agenten-Schicht hinzugefügt wird, müssen Teams weiterhin das Cluster-Modell, Workload-Grenzen, Speicher, Netzwerk, Sicherheit und Wiederherstellung verstehen, die im Mr.PlanB-Kubernetes-Hub behandelt werden. Agentisches Tooling fügt diesem Stack eine weitere Kontrollebene hinzu.

Kubernetes gibt Agenten eine Betriebsumgebung

kagent beschreibt sich selbst als Kubernetes-natives Framework für KI-Agenten. Der Reiz ist einfach zu erklären. Kubernetes bietet bereits ein deklaratives Kontrollmodell, APIs, Namespaces, Service Discovery, Scheduling, Secrets, Policies und ein großes Automatisierungs-Ökosystem. Ein für diese Umgebung gebauter Agent lässt sich mit vielen derselben Mechanismen bereitstellen und verwalten, die Plattform-Teams bereits für Anwendungen nutzen.

Das schafft ein potenziell nützliches Muster für den Betrieb. Ein Agent kann als verwalteter Workload verpackt, mit explizit begrenzten Berechtigungen ausgestattet, an freigegebene Tools angebunden und wie andere Dienste beobachtet werden. Statt einem externen Automatisierungssystem uneingeschränkten Zugriff auf einen Cluster zu geben, können Teams die Automatisierung in einen kontrollierten Kubernetes-Kontext stellen.

Das macht den Agenten nicht automatisch sicher. Es macht seine Grenzen sichtbarer. RBAC, Service Accounts, Netzwerk-Policies, Admission-Controls, Secrets und Audit-Daten werden Teil des Agenten-Designs. Platform-Engineers müssen wissen, was ein Agent lesen kann, was er ändern kann, welche Tools er aufrufen kann und was passiert, wenn ein Modell eine schlechte Empfehlung liefert.

OpenChoreo deutet auf eine höhere Plattformebene hin

OpenChoreo nähert sich dem Problem aus einer anderen Richtung. Das Projekt beschreibt eine Entwicklerplattform für Kubernetes mit Abstraktionen, einem Entwicklerportal, CI/CD, GitOps und Observability. Das Ziel ist, die den Anwendungsentwicklern ausgesetzte rohe Kubernetes-Komplexität zu reduzieren und gleichzeitig die Governance für Plattform-Teams zu erhalten.

Diese Idee wird interessanter, sobald KI-Agenten hinzukommen. Menschen sind nicht mehr die einzigen Nutzer einer Plattform-API. Ein Agent muss womöglich eine Komponente bereitstellen, eine Umgebung inspizieren, eine Ressource anfordern oder auf ein operatives Ereignis reagieren. Abstraktionen auf höherer Ebene können diese Aktionen wirksamer einschränken, als wenn jedem Automatisierungsprozess direkter Zugriff auf Cluster-Objekte niedriger Ebene gegeben würde.

Das Ergebnis wirkt weniger wie ein an Kubernetes angehängtes KI-Feature und mehr wie ein neuer Plattform-Client. Entwickler, Pipelines, Operatoren und Agenten interagieren möglicherweise alle mit derselben zugrunde liegenden Infrastruktur, jeweils über unterschiedliche Schnittstellen und Berechtigungsgrenzen.

Platform Engineering wird zu einem KI-Infrastrukturproblem

Hier beginnen sich KI-Infrastruktur und Platform Engineering zu überschneiden. Modelle effizient zu betreiben ist nur ein Teil des Problems. Teams brauchen außerdem wiederholbare Deployments, Secrets-Management, Speicher, Netzwerk, Observability, Policy, Identität, Skalierung und Wiederherstellung.

Der Leitfaden zu KI- und GPU-Workloads auf Kubernetes deckt die Infrastrukturseite ab: Accelerator-Discovery, Scheduling, Node-Pools, Treiber, Speicherdurchsatz, Netzwerk, Modelldaten, Resilienz und Kosten. Agenten-Frameworks sitzen über vielen dieser Belange. Ruft ein Agent einen Inferenzdienst auf, braucht das zugrunde liegende Modell weiterhin zuverlässige GPU-Kapazität und Datenzugriff. Erledigt ein Agent operative Arbeit, braucht der Cluster weiterhin Kontrollen, die verhindern, dass ein einzelner Automatisierungsfehler zu einem Plattform-Ausfall wird.

Das ist wichtig, weil KI-Agenten die Änderungsrate erhöhen können. Ein menschlicher Administrator nimmt während eines Wartungsfensters vielleicht eine Handvoll bewusster Änderungen vor. Ein automatisierter Agent kann viel schneller inspizieren, entscheiden und handeln. Schnelleres Handeln ist nur dann nützlich, wenn Berechtigungen, Validierung, Rollback und Auditierbarkeit ebenso ausgereift sind.

Managed- versus Self-managed-Kubernetes bleibt relevant

Der Aufstieg von agentischem Tooling beseitigt nicht die alten Infrastrukturentscheidungen. Er macht sie folgenreicher. Teams müssen weiterhin entscheiden, wie viel von der Kubernetes-Control-Plane und der unterstützenden Infrastruktur sie selbst betreiben wollen.

Der Vergleich zwischen Managed Kubernetes und Bare Metal rahmt diese Entscheidung anhand von Kontrolle, Hardware-Zugriff, Performance, Kosten, Personalbedarf, Upgrades, Sicherheit und operativem Aufwand. KI-Workloads können Teams in beide Richtungen drängen. Managed Services reduzieren einen Teil der Plattformwartung, während Bare Metal engere Kontrolle über Beschleuniger, Hochgeschwindigkeitsnetzwerke, Speicher und Datenlokalität bieten kann.

Agenten-Frameworks können in beiden Modellen laufen, aber die Verantwortlichkeiten im Fehlerfall unterscheiden sich. Bei einem Managed Service besitzt der Cloud-Anbieter womöglich Teile der Control-Plane, während der Kunde weiterhin Workloads, Identitäten, Policies und Daten verantwortet. Bei Bare Metal besitzt das Plattform-Team einen viel größeren Teil des Stacks und muss Upgrades, Verfügbarkeit, Netzwerk, Speicher und Wiederherstellung selbst planen.

Agenten sollten mit eng begrenzten Befugnissen beginnen

Der praktikabelste Einführungsweg ist wahrscheinlich ein schrittweiser. Infrastruktur-Teams müssen nicht damit beginnen, einem KI-Agenten zu erlauben, Produktionsprobleme automatisch zu beheben. Reine Lesezugriffs-Analysen, Troubleshooting-Unterstützung, Runbook-Anleitung, Inventarabfragen und kontrollierte Aktionen außerhalb der Produktion können nützliche Erfahrung liefern und gleichzeitig den Blast Radius klein halten.

Mit wachsendem Vertrauen können Teams Genehmigungs-Gates und eng gefasste Schreiboperationen einführen. Das Ziel sollte sein, Agenten-Aktionen beobachtbar und reversibel zu machen. Eine Plattform sollte beantworten können, welcher Agent gehandelt hat, welche Identität er genutzt hat, welche Ressourcen sich geändert haben, welche Evidenz die Aktion begründet hat und wie die Änderung zurückgerollt werden kann.

Das ist vertrautes DevOps-Denken, angewendet auf einen neuen Akteur. Infrastructure as Code machte Änderungen wiederholbarer. GitOps machte den gewünschten Zustand und Review-Workflows expliziter. Agentischer Betrieb wirft nun die Frage auf, wie viel Entscheidungsfindung automatisiert werden kann, ohne die Kontrolle zu verlieren.

Die nächste Kubernetes-Plattform könnte zwei Arten von Nutzern haben

kagent und OpenChoreo sind frühe Signale einer breiteren Entwicklung. Kubernetes-Plattformen wurden ursprünglich für Operatoren und Anwendungs-Workloads gebaut. Platform Engineering schuf dann bessere Schnittstellen für Entwickler. KI-Agenten führen nun eine weitere Nutzerklasse ein, die dieselben Abstraktionen programmatisch und mit hoher Geschwindigkeit nutzen kann.

Das bedeutet nicht, dass jede Kubernetes-Umgebung ein Agenten-Framework braucht. Es bedeutet aber, dass Plattform-Teams anfangen sollten, Agenten als Infrastruktur-Teilnehmer mit Identitäten, Berechtigungen, Abhängigkeiten, Kosten und Fehlermodi zu betrachten.

Am meisten profitieren wahrscheinlich die Teams, die das Fundament bewusst unspektakulär halten: klare Cluster-Eigentümerschaft, zuverlässiger Speicher, beobachtbare Workloads, kontrollierte Credentials, getestete Wiederherstellung und klar definierte Automatisierungsgrenzen. Darauf aufbauend können KI-Agenten ein weiteres Werkzeug für den Betrieb komplexer Systeme werden statt eine weitere Quelle unkontrollierter Komplexität.

Ursprünglich veröffentlicht im Mr.PlanB-Blog.