Isolation, Sicherheit, Skalierung: KI-Agenten auf Kubernetes mit kagent und Agent Substrate sandboxen
🇬🇧 Read in English~4 min read
devopskubernetesai-agentssandboxinggvisormicrovmkagentsecuritycloud-native
Das Eingangstür-Muster: Nginx terminiert TLS mit automatischer Let's-Encrypt-Erneuerung über Certbot, gehärtet durch CrowdSec als WAF/IPS mit dem Nginx-Bouncer, aktuell gehalten von Watchtower. Eine C
Einen KI-Agenten in einen gewöhnlichen Container zu packen, ist noch keine Sandbox. Ingress und Egress stehen weit offen, der Workload schickt Pakete, wohin er will, und Policy-Enforcement existiert nicht. Network Policies und Segmentierung helfen zwar, aber Container-Sandboxing ist von Natur aus „flach“ — es endet am Kernel, in dessen User Space alles läuft. Für einen Workload, der Modell-Outputs hält, möglicherweise Credentials besitzt und Tool Calls ausführt, ist das keine Produktionsreife.
Ein heute erschienener Beitrag im CNCF-Blog von Michael Levan (CNCF Ambassador) argumentiert, dass agentische Workloads drei Dinge brauchen, bevor sie in Produktion gehören — Isolation, Sicherheit und Skalierung — und zeigt den Stack, der sie liefert: kagent als Runtime für deklarative und mitgebrachte Agenten (einschließlich Frameworks wie LangGraph und ADK), mit Agent Substrate als Sandbox-Umgebung darunter.
Über den schlichten Container hinaus definiert der Artikel fünf Eigenschaften einer sicheren Sandbox:
Das erfordert Isolation auf Software- und Hardware-Ebene sowie Policy-Enforcement am AI Gateway, dort wo Agent-Traffic sein Ziel erreicht.
Agent Substrate betreibt Agenten in Workern, die Pods sind. Die Agenten selbst werden über Actors abgewickelt, verwaltet von der ateapi — dem Control Plane von Agent Substrate. Die Isolation entsteht aus zwei Schichten:
Wie der Client zum Agenten routet — und was in der Mitte diese Weiterleitung ermöglicht — entscheidet über die Isolation, nicht das Container-Label.
Ohne kagent ist der einzige echte Zugang zu Agent Substrate ein programmatischer Aufruf — etwa ein curl gegen einen Actor. kagent verpackt die Substrate in das, was die Industrie gewohnt ist: ein UI und deklarative Kubernetes-CRDs (kagent.dev/v1alpha3).
Zwei CRDs tragen die Hauptlast:
workerPoolRef, definiert den Ort der snapshotPolicy (etwa einen gs://-Bucket für Snapshots) und begrenzt über einen Label-Selector, welche AgentTemplates es nutzen darf.Eine Helm-Standardinstallation von kagent v1.0 erzeugt einen WorkerPool mit zwei Workern (Pods) über die Einstellung substrateWorkerPool.create=true. Für den Einstieg werden das kubectl-ate-CLI (die Control-Plane-Schnittstelle von Agent Substrate) konfiguriert, Agent Substrate installiert und anschließend kagent installiert — eine Schritt-für-Schritt-Anleitung ist im Originalbeitrag verlinkt. Harness und AgentTemplate lassen sich auch über das UI anlegen: Das Agents-Panel bietet einen + New template-Button und einen + New Harness-Flow mit Namespace, Name, Runtime-Adapter und Image-Ort.
Die Ressourcen-Story ist der Teil, den man verinnerlichen sollte: Ein Actor läuft nur, während eine Session aktiv ist. Der Walkthrough im Artikel beginnt bei 0/8 laufenden Actors. Eine neue Session startet einen frischen Actor; wenn die Session abgeschlossen ist, fährt er wieder herunter (0/9, dann 0/10 bei der nächsten neuen Session). Wer eine bestehende Session wieder öffnet, ändert die Zahl nicht — es ist dieselbe Session. Es ist also nicht „jede Agent-Nutzung erzeugt einen Pod“, sondern nur jede neue Session — die Hardware-Auslastung bleibt proportional zur tatsächlichen Konversationslast.
Für Engineering-Teams wie für Unternehmen ist die Fähigkeit, Agenten zu isolieren, abzusichern, zu governen und zu kontrollieren, heute der Engpasspunkt für produktive agentische Workloads — der Schritt, der aus einer Demo etwas macht, über das ein Operator nachvollziehbar urteilen kann. Sandboxing ist der Mechanismus; kagent plus Agent Substrate ist ein konkreter, deklarativer Weg, das auf Kubernetes zu bekommen.