AI Agents auf Kubernetes: AutoGPT und CrewAI produktiv betreiben

TL;DR

• AI Agents sind zustandsbehaftete, langlebige Prozesse -- das erfordert andere Deployment-Patterns als klassische Microservices
• CrewAI eignet sich fuer strukturierte Multi-Agent-Workflows, AutoGPT fuer explorative Einzelagenten
• KEDA (Kubernetes Event-Driven Autoscaling) skaliert Agent-Pods anhand von Queue-Laenge statt CPU-Auslastung
• LLM-Zugang ueber lokale Modelle (vLLM, Ollama) oder externe APIs -- die Wahl beeinflusst Latenz, Kosten und Datenschutz
• Ohne Persistent Storage verlieren Agents ihren Kontext bei Pod-Restarts -- das macht sie unbrauchbar

Was sind AI Agents und warum Kubernetes?

Ein AI Agent ist mehr als ein Chatbot. Er plant, fuehrt Aktionen aus, beobachtet die Ergebnisse und iteriert. Ein CrewAI-Agent "Research Analyst" koennte beispielsweise Web-Recherche durchfuehren, die Ergebnisse zusammenfassen, Luecken identifizieren und gezielt nachrecherchieren -- ohne menschliche Zwischenschritte.

Das Problem: Diese Agenten laufen Minuten bis Stunden. Sie brauchen Zugang zu externen Tools (APIs, Datenbanken, Dateisysteme). Sie verbrauchen unvorhersagbar viel Compute, weil die Anzahl der LLM-Aufrufe vom Aufgabeninhalt abhaengt. Und sie muessen ihren Zustand zwischen den Schritten persistieren.

Kubernetes loest genau diese Probleme: Pod-Restarts mit Persistent Volumes, Autoscaling basierend auf Queue-Laenge, Resource Limits pro Agent, Namespace-Isolation zwischen verschiedenen Agent-Teams.

AutoGPT vs. CrewAI: Wann welches Framework?

Beide Frameworks verfolgen unterschiedliche Philosophien. Die Wahl haengt vom Anwendungsfall ab.

Fuer den produktiven Einsatz in einer Unternehmensumgebung ist CrewAI in der Regel die bessere Wahl, weil die Workflows vorhersagbar und die Kosten kontrollierbar sind. AutoGPT ist stark fuer R&D und Prototyping, aber der unkontrollierte Token-Verbrauch macht den Produktionsbetrieb schwierig.

Container-Architektur fuer AI Agents

Ein AI Agent ist kein typischer stateless Microservice. Die Container-Architektur muss das beruecksichtigen.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: crewai-research-agent
  namespace: ai-agents
  labels:
    app: crewai-research
    agent-type: crew
spec:
  replicas: 1
  selector:
    matchLabels:
      app: crewai-research
  template:
    metadata:
      labels:
        app: crewai-research
        agent-type: crew
    spec:
      containers:
        - name: agent
          image: registry.internal/crewai-research:1.2.0
          env:
            - name: LLM_BACKEND
              value: "http://vllm-service.llm:8000/v1"
            - name: TASK_QUEUE_URL
              valueFrom:
                secretKeyRef:
                  name: agent-secrets
                  key: redis-url
            - name: AGENT_MAX_ITERATIONS
              value: "20"
            - name: AGENT_TIMEOUT_SECONDS
              value: "3600"
          resources:
            requests:
              cpu: 500m
              memory: 1Gi
            limits:
              cpu: "2"
              memory: 4Gi
          volumeMounts:
            - name: agent-workspace
              mountPath: /workspace
            - name: agent-cache
              mountPath: /cache
          livenessProbe:
            httpGet:
              path: /healthz
              port: 8080
            initialDelaySeconds: 30
            periodSeconds: 60
            timeoutSeconds: 10
          readinessProbe:
            httpGet:
              path: /ready
              port: 8080
            periodSeconds: 10
      volumes:
        - name: agent-workspace
          persistentVolumeClaim:
            claimName: agent-workspace-pvc
        - name: agent-cache
          emptyDir:
            sizeLimit: 2Gi
      terminationGracePeriodSeconds: 120
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: agent-workspace-pvc
  namespace: ai-agents
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 10Gi
  storageClassName: fast-ssd

Einige bewusste Design-Entscheidungen in diesem Manifest:

terminationGracePeriodSeconds: 120 -- Agents brauchen Zeit, um ihren aktuellen Schritt abzuschliessen und den Zustand zu persistieren, bevor der Pod terminiert wird. Die Standard-30-Sekunden reichen nicht.

Liveness Probe mit 60s Interval -- Agents koennen laenger als 10 Sekunden auf eine LLM-Antwort warten. Eine zu aggressive Liveness Probe wuerde den Pod faelschlicherweise als tot markieren.

Separates emptyDir fuer Cache -- Zwischenergebnisse, die bei einem Restart verloren gehen duerfen (z.B. heruntergeladene Webseiten), landen im emptyDir. Der eigentliche Agent-State liegt auf dem PVC.

KEDA: Event-Driven Autoscaling fuer Agents

Agents werden nicht nach CPU-Last skaliert. Ein Agent, der auf eine LLM-Antwort wartet, verbraucht kaum CPU, braucht aber trotzdem einen eigenen Pod. Die richtige Metrik ist die Queue-Laenge: Wie viele Aufgaben warten auf Bearbeitung?

KEDA (Kubernetes Event-Driven Autoscaling) ermoeglicht genau das. Hier ein Beispiel mit Redis als Task Queue:

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:
  name: crewai-research-scaler
  namespace: ai-agents
spec:
  scaleTargetRef:
    name: crewai-research-agent
  minReplicaCount: 0
  maxReplicaCount: 10
  cooldownPeriod: 300
  pollingInterval: 15
  triggers:
    - type: redis
      metadata:
        address: redis.ai-agents.svc.cluster.local:6379
        listName: research-tasks
        listLength: "2"
        activationListLength: "1"
      authenticationRef:
        name: redis-auth
---
apiVersion: keda.sh/v1alpha1
kind: TriggerAuthentication
metadata:
  name: redis-auth
  namespace: ai-agents
spec:
  secretTargetRef:
    - parameter: password
      name: agent-secrets
      key: redis-password

Diese Konfiguration sagt: Wenn mindestens 1 Task in der Queue liegt, skaliere auf mindestens 1 Pod. Pro 2 wartende Tasks kommt ein weiterer Pod dazu, bis maximal 10. Wenn die Queue leer ist, skaliere nach 5 Minuten auf 0. Das spart erheblich Kosten, weil Agents nur dann laufen, wenn es Arbeit gibt.

LLM-Anbindung: Lokal vs. API

Jeder AI Agent braucht Zugang zu einem Large Language Model. Die Entscheidung zwischen lokalem Hosting und externer API hat weitreichende Konsequenzen.

Fuer datensensible Anwendungen -- und das betrifft die meisten Geschaeftsprozesse -- ist ein lokal gehostetes LLM die sicherere Wahl. vLLM als OpenAI-kompatibler Inference-Server laesst sich als Kubernetes Service bereitstellen, sodass Agents ueber den gleichen API-Standard kommunizieren koennen, egal ob das Modell lokal oder extern laeuft.

Mehr zum Thema GPU-Workloads auf Kubernetes finden Sie unter GPU-Cluster mit Kubernetes und GPU-Monitoring.

Secrets und API-Keys verwalten

AI Agents brauchen Zugang zu vielen externen Services: LLM-APIs, Datenbanken, SaaS-Tools. Jeder dieser Zugaenge hat Credentials. Diese gehoeren nicht in Umgebungsvariablen im Deployment-Manifest und schon gar nicht ins Git-Repository.

Kubernetes Secrets sind der Mindeststandard. Besser ist ein externer Secret Store wie HashiCorp Vault oder der External Secrets Operator, der Secrets aus AWS Secrets Manager, Azure Key Vault oder anderen Backends synchronisiert.

# External Secrets Operator installieren
helm repo add external-secrets https://charts.external-secrets.io
helm install external-secrets external-secrets/external-secrets \
  -n external-secrets --create-namespace

# Beispiel: ExternalSecret, das einen API-Key aus Vault zieht
kubectl apply -f - <<'EOF'
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
  name: llm-api-credentials
  namespace: ai-agents
spec:
  refreshInterval: 1h
  secretStoreRef:
    name: vault-backend
    kind: ClusterSecretStore
  target:
    name: agent-secrets
    creationPolicy: Owner
  data:
    - secretKey: openai-api-key
      remoteRef:
        key: secret/ai-agents/openai
        property: api-key
    - secretKey: redis-password
      remoteRef:
        key: secret/ai-agents/redis
        property: password
EOF

Ausfuehrlicher behandelt in Secrets Management mit Vault.

Typische Probleme und Loesungen

Problem: Agent-Pods werden wegen OOM gekillt. LLM-Responses werden im Speicher gehalten, und bei langen Konversationen waechst der Speicherbedarf kontinuierlich. Loesung: Memory Limits grosszuegig setzen (4-8 Gi) und in der Agent-Logik ein Kontext-Fenster implementieren, das aeltere Nachrichten zusammenfasst statt alles zu behalten.

Problem: Agent haengt in einer Endlosschleife. AutoGPT ist dafuer beruehmt. Der Agent versucht immer wieder den gleichen Ansatz, weil das LLM keine bessere Idee hat. Loesung: AGENT_MAX_ITERATIONS begrenzen und ein Timeout setzen. Bei CrewAI kann man zusaetzlich max_rpm (Requests per Minute) pro Agent definieren.

Problem: Kosten explodieren. Jeder LLM-Aufruf kostet Geld (oder GPU-Zeit). Ein Agent, der 50 Iterationen macht, verbraucht 50x mehr als einer, der in 5 Schritten fertig ist. Loesung: Token-Budget pro Task definieren, Monitoring der Token-Nutzung pro Agent ueber Prometheus Custom Metrics, Alerting bei Ueberschreitung.

Problem: Datenbank-Verbindungen gehen aus. Wenn KEDA schnell auf 10 Pods skaliert und jeder Pod eine DB-Verbindung oeffnet, laeuft der Connection Pool voll. Loesung: PgBouncer oder ein aehnlicher Connection Pooler als Sidecar oder separater Service.

Monitoring und Observability

Standard-Metriken (CPU, Memory, Netzwerk) reichen fuer AI Agents nicht aus. Folgende Custom Metrics sollten erfasst werden:

• task_duration_seconds -- Wie lange braucht ein Agent fuer eine Aufgabe?
• llm_calls_per_task -- Wie viele LLM-Aufrufe pro Task? (Korreliert direkt mit Kosten)
• tokens_consumed_total -- Gesamter Token-Verbrauch (Input + Output)
• task_success_rate -- Wie viele Tasks werden erfolgreich abgeschlossen?
• queue_depth -- Wie viele Tasks warten? (KEDA-Metrik)

Diese Metriken lassen sich ueber einen /metrics-Endpoint im Agent-Container exponieren und von Prometheus scrapen. Grafana-Dashboards geben dann einen Ueberblick ueber Kosten, Performance und Zuverlaessigkeit.

Mehr zum Aufbau eines umfassenden Monitoring-Stacks unter Kubernetes Observability Stack und OpenTelemetry mit Kubernetes.

Architektur-Entscheidung: Job vs. Deployment

Nicht jeder Agent-Workload passt in ein Deployment. Wenn ein Agent genau eine Aufgabe erledigt und dann fertig ist, ist ein Kubernetes Job oder ein CronJob die bessere Abstraktion.

Fuer die meisten Produktions-Use-Cases ist das Deployment + KEDA Pattern der richtige Ansatz. Jobs eignen sich fuer Batch-Verarbeitung, CronJobs fuer zeitgesteuerte Aufgaben.

Sicherheit und Isolation

AI Agents fuehren Code aus, der vom LLM generiert wird. Das ist ein erhebliches Sicherheitsrisiko. Ein Agent, der Tools wie "execute_python" oder "run_shell_command" hat, kann potenziell beliebigen Code im Container ausfuehren.

Gegenmassnahmen:

• Pod Security Standards auf "restricted" -- Kein Root, kein privilegierter Modus, Read-Only Root Filesystem
• NetworkPolicies -- Agents duerfen nur mit definierten Endpunkten kommunizieren (LLM-Service, Task Queue, spezifische APIs)
• Resource Quotas auf Namespace-Ebene -- Ein ausser Kontrolle geratener Agent kann nicht den gesamten Cluster lahmlegen
• gVisor oder Kata Containers -- Fuer maximale Isolation eine Sandbox-Runtime verwenden

Details zur Absicherung von Kubernetes-Workloads finden Sie unter Kubernetes Runtime Security.

Fazit

AI Agents auf Kubernetes zu betreiben ist machbar, aber kein Standard-Deployment. Die zustandsbehaftete Natur der Agents, der unvorhersagbare Ressourcenverbrauch und die Sicherheitsimplikationen von LLM-generiertem Code erfordern durchdachte Architekturentscheidungen.

Die wichtigsten Takeaways: KEDA statt HPA fuer Autoscaling, Persistent Volumes fuer Agent-State, grosszuegige Timeouts und Memory-Limits, Token-Budgets zur Kostenkontrolle, und strikte Isolation ueber NetworkPolicies und Pod Security Standards.

Wenn Sie AI Agents in Ihrer Infrastruktur evaluieren oder einen bestehenden Prototyp produktionsreif machen wollen, unterstuetzen wir Sie bei Architektur und Betrieb. Schreiben Sie uns unter /kontakt.