AI-Agenten auf Kubernetes betreiben: Runtime, Limits, Isolation

TL;DR

Ein KI-Agent auf Kubernetes ist ein kurzlebiger, werkzeugführender Workload mit eigenem Risikoprofil. Betrieben wird er in einem eigenen Namespace je Team, mit Resource Limits, definierter Laufzeit, verstärkter Isolation bei Bedarf und einem Lebenszyklus, der jeden Lauf frisch startet und danach entsorgt. Dazu kommen eigene Identität, Gateway-Anbindung und vollständiges Lauf-Logging.

Was Agenten von normalen Workloads unterscheidet

Normale Services laufen lange und antworten auf Anfragen. Agenten laufen minuten- bis stundenweise, starten Shells und Werkzeuge, verändern Dateien und rufen Modelle auf. Daraus folgen drei Betriebsregeln: Läufe sind wegwerfbar und bekommen kein persistentes Dateisystem außer freigegebenen Arbeitsverzeichnissen, Ressourcen werden begrenzt, damit ein Endlos-Loop weder Cluster noch Modell-Budget leer fährt, und jeder Lauf ist einem Team, einer Umgebung und einer Identität zugeordnet, sonst ist kein Audit möglich.

Isolation nach Schutzbedarf

Die Basis ist ein Namespace je Team mit Network Policies, Resource Quotas und Pod Security Standards auf restricted. Für Agenten, die fremden oder generierten Code ausführen, reicht das nicht immer: Dann kommt eine Sandbox-Runtime wie gVisor oder Kata dazu, die dem Container einen eigenen Kernel-Rand gibt. Die Entscheidung treffen Sie je Umgebung, Entwicklungs-Agenten mit freigegebenen Repos brauchen weniger Härte als eine Umgebung, die ungeprüfte Artefakte ausführt. Wichtig ist, dass die Stufe eine bewusste Einstellung der Plattform ist und kein Zufall des ersten Deployments.

Anbindung: Gateway, Secrets, Registry

Drei Anbindungen gehören in jedes Agenten-Template. Modell-Aufrufe laufen nur über das zentrale AI Gateway, damit Freigaben, Budgets und Logs an einer Stelle entstehen. Secrets kommen zur Laufzeit aus dem zentralen Speicher in den Container, nie als Klartext in Manifeste oder Images. Packages kommen nur aus der geprüften Registry, damit Agenten-Vorschläge keine ungeprüften Abhängigkeiten in den Bau ziehen. Mit diesen drei Vorgaben ist ein Agenten-Lauf technisch eingezäunt, bevor die erste Zeile Code entsteht.

Lebenszyklus und Kosten

Jeder Lauf hat Start, Zeitlimit und Entsorgung. Arbeitsverzeichnisse werden nach dem Lauf archiviert oder gelöscht, der Container verschwindet. Kosten entstehen an zwei Stellen, Cluster-Ressourcen und Modell-Aufrufe, und beide tragen dieselben Labels, damit Team-Kosten eine einzige Auswertung sind. Wer Agenten als Plattform betreibt statt als Einzel-Experiment, bietet Templates als Golden Paths an: Ein Team startet eine freigegebene Umgebung per Self-Service, statt eigene Manifeste zu schreiben. Den Gesamtaufbau aus Runtime, Governance und Betrieb beschreibt die Seite zur AI-Agenten-Plattform von Pexon Consulting.

Fazit

Agenten-Betrieb ist kein neues Produkt, sondern eine disziplinierte Workload-Klasse auf dem vorhandenen Cluster. Namespace-Trennung, Limits, passende Isolation, Gateway- und Secret-Anbindung sowie ein frischer Lauf je Aufgabe machen daraus einen betreibbaren Zustand statt einer Demo.