OpenClaw auf Kubernetes bereitstellen: Schnellanleitung

Kennst du das? Du willst ein neues Tool in deinem Cluster ausprobieren, aber die Konfiguration ist so komplex, dass du mehr Zeit mit YAML-Dateien verbringst als mit dem eigentlichen Tool. Das nervt und hält dich von der eigentlichen Arbeit ab. Kubernetes sollte uns das Leben leichter machen, nicht schwerer. Hier ist ein unkomplizierter Weg, OpenClaw zum Laufen zu bringen.

OpenClaw auf Kubernetes

Dies ist ein minimaler Startpunkt, um OpenClaw auf Kubernetes auszuführen – kein produktionsreifes Deployment. Es deckt die Kernressourcen ab und ist dafür gedacht, an deine Umgebung angepasst zu werden.

Warum kein Helm?

OpenClaw ist ein einzelner Container mit einigen Konfigurationsdateien. Die interessante Anpassung liegt im Agent-Content (Markdown-Dateien, Skills, Config-Overrides), nicht im Infrastructure-Templating. Kustomize erledigt Overlays ohne den Overhead eines Helm-Charts. Wenn dein Deployment komplexer wird, kann ein Helm-Chart über diese Manifeste gelegt werden.

Was du brauchst

Ein laufender Kubernetes Cluster (AKS, EKS, GKE, k3s, kind, OpenShift, etc.) sowie kubectl mit Verbindung zu deinem Cluster
Ein API Key für mindestens einen Model-Provider

Schnellstart

# Replace with your provider: ANTHROPIC, GEMINI, OPENAI, or OPENROUTER
export <PROVIDER>_API_KEY="..."
./scripts/k8s/deploy.sh

kubectl port-forward svc/openclaw 18789:18789 -n openclaw
open http://localhost:18789

Hol dir den Gateway-Token und füge ihn in die Control UI ein:

kubectl get secret openclaw-secrets -n openclaw -o jsonpath='{.data.OPENCLAW_GATEWAY_TOKEN}' | base64 -d

Für lokales Debugging druckt ./scripts/k8s/deploy.sh --show-token den Token nach dem Deployment aus.

Lokales Testen mit Kind

Wenn du keinen Cluster hast, erstelle lokal einen mit Kind:

./scripts/k8s/create-kind.sh           # auto-detects docker or podman
./scripts/k8s/create-kind.sh --delete  # tear down

Führe das Deployment dann wie gewohnt mit ./scripts/k8s/deploy.sh aus.

Schritt für Schritt

1) Deployment

Option A — API Key in der Umgebung (ein Schritt):

# Replace with your provider: ANTHROPIC, GEMINI, OPENAI, or OPENROUTER
export <PROVIDER>_API_KEY="..."
./scripts/k8s/deploy.sh

Das Script erstellt ein Kubernetes Secret mit dem API Key und einem automatisch generierten Gateway-Token und führt dann das Deployment aus. Wenn das Secret bereits existiert, bleiben der aktuelle Gateway-Token und alle Provider-Keys, die nicht geändert werden, erhalten.

Option B — Das Secret separat erstellen:

export <PROVIDER>_API_KEY="..."
./scripts/k8s/deploy.sh --create-secret
./scripts/k8s/deploy.sh

Verwende --show-token bei beiden Befehlen, wenn du möchtest, dass der Token für lokale Tests im Terminal ausgegeben wird.

2) Zugriff auf das Gateway

kubectl port-forward svc/openclaw 18789:18789 -n openclaw
open http://localhost:18789

Was bereitgestellt wird

Namespace: openclaw (configurable via OPENCLAW_NAMESPACE)
├── Deployment/openclaw        # Single pod, init container + gateway
├── Service/openclaw           # ClusterIP on port 18789
├── PersistentVolumeClaim      # 10Gi for agent state and config
├── ConfigMap/openclaw-config  # openclaw.json + AGENTS.md
└── Secret/openclaw-secrets    # Gateway token + API keys

Anpassung

Agent-Anweisungen

Bearbeite die AGENTS.md in scripts/k8s/manifests/configmap.yaml und führe das Deployment erneut aus:

./scripts/k8s/deploy.sh

Gateway-Konfiguration

Bearbeite openclaw.json in scripts/k8s/manifests/configmap.yaml. Siehe Gateway configuration für die vollständige Referenz.

Provider hinzufügen

Führe das Script erneut mit weiteren exportierten Keys aus:

export ANTHROPIC_API_KEY="..."
export OPENAI_API_KEY="..."
./scripts/k8s/deploy.sh --create-secret
./scripts/k8s/deploy.sh

Bestehende Provider-Keys bleiben im Secret, außer du überschreibst sie.

Oder patche das Secret direkt:

kubectl patch secret openclaw-secrets -n openclaw \
  -p '{"stringData":{"<PROVIDER>_API_KEY":"..."}}'
kubectl rollout restart deployment/openclaw -n openclaw

Eigener Namespace

OPENCLAW_NAMESPACE=my-namespace ./scripts/k8s/deploy.sh

Eigenes Image

Bearbeite das image-Feld in scripts/k8s/manifests/deployment.yaml:

image: ghcr.io/openclaw/openclaw:2026.3.1

Über Port-Forwarding hinaus freigeben

Die Standard-Manifeste binden das Gateway an Loopback innerhalb des Pods. Das funktioniert mit kubectl port-forward, aber nicht mit einem Kubernetes Service oder Ingress-Pfad, der die Pod-IP erreichen muss.

Wenn du das Gateway über einen Ingress oder Load Balancer freigeben willst:

Ändere den Gateway-Bind in scripts/k8s/manifests/configmap.yaml von loopback zu einem Non-Loopback-Bind, der zu deinem Deployment-Modell passt
Lass die Gateway-Auth aktiviert und verwende einen ordnungsgemäßen TLS-terminierten Endpunkt
Konfiguriere die Control UI für den Remote-Zugriff unter Verwendung des unterstützten Web-Sicherheitsmodells (zum Beispiel HTTPS/Tailscale Serve und explizite Allowed Origins, falls erforderlich)

Erneutes Deployment

./scripts/k8s/deploy.sh

Dies wendet alle Manifeste an und startet den Pod neu, um Konfigurations- oder Secret-Änderungen zu übernehmen.

Abbau

./scripts/k8s/deploy.sh --delete

Dies löscht den Namespace und alle darin enthaltenen Ressourcen, einschließlich des PVC.

Architektur-Hinweise

Das Gateway bindet standardmäßig an Loopback innerhalb des Pods, daher ist das enthaltene Setup für kubectl port-forward gedacht
Keine Cluster-scoped Ressourcen – alles befindet sich in einem einzigen Namespace
Sicherheit: readOnlyRootFilesystem, drop: ALL Capabilities, Non-Root User (UID 1000)
Die Standardkonfiguration hält die Control UI auf dem sichereren Pfad für lokalen Zugriff: Loopback-Bind plus kubectl port-forward auf http://127.0.0.1:18789
Wenn du über den Localhost-Zugriff hinausgehst, verwende das unterstützte Remote-Modell: HTTPS/Tailscale plus den entsprechenden Gateway-Bind und Control UI Origin-Einstellungen
Secrets werden in einem temporären Verzeichnis generiert und direkt auf den Cluster angewendet – es werden keine Secret-Inhalte in das Repository geschrieben

Dateistruktur

scripts/k8s/
├── deploy.sh                   # Creates namespace + secret, deploys via kustomize
├── create-kind.sh              # Local Kind cluster (auto-detects docker/podman)
└── manifests/
    ├── kustomization.yaml      # Kustomize base
    ├── configmap.yaml          # openclaw.json + AGENTS.md
    ├── deployment.yaml         # Pod spec with security hardening
    ├── pvc.yaml                # 10Gi persistent storage
    └── service.yaml            # ClusterIP on 18789

AI Setup Assistant

Nächste Schritte

OpenClaw Expert

Noch festgefahren?

Wenn diese Seite nicht hilft, frage OpenClaw Expert nach Schritt-fuer-Schritt-Loesungen.