OpenClawDocs
View as MarkdownView this page as plain textOpen in ChatGPTAsk questions about this pageOpen in ClaudeAsk questions about this page

Hosting

Kubernetes

Ein minimaler Ausgangspunkt für den Betrieb von OpenClaw auf Kubernetes, keine produktionsreife Bereitstellung. Er deckt die wichtigsten Ressourcen ab und ist zur Anpassung an Ihre Umgebung vorgesehen.

Warum nicht Helm?

OpenClaw besteht aus einem einzelnen Container mit einigen Konfigurationsdateien. Die interessanten Anpassungen betreffen die Agent-Inhalte (Markdown-Dateien, Skills, Konfigurationsüberschreibungen), nicht die Vorlagenerstellung für die Infrastruktur. Kustomize verwaltet Overlays ohne den zusätzlichen Aufwand eines Helm-Charts. Legen Sie ein Helm-Chart über diese Manifeste, wenn Ihre Bereitstellung komplexer wird.

Voraussetzungen

  • Ein laufender Kubernetes-Cluster (AKS, EKS, GKE, k3s, kind, OpenShift usw.)
  • Mit Ihrem Cluster verbundenes kubectl
  • Ein API-Schlüssel für mindestens einen Modell-Provider

Schnellstart

bash
# Durch Ihren Provider ersetzen: ANTHROPIC, GEMINI, OPENAI oder OPENROUTERexport <PROVIDER>_API_KEY="..."./scripts/k8s/deploy.sh kubectl port-forward svc/openclaw 18789:18789 -n openclawopen http://localhost:18789

deploy.sh erstellt standardmäßig eine Token-Authentifizierung. Rufen Sie das generierte Gateway-Token für die Control UI ab:

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

Für lokales Debugging gibt ./scripts/k8s/deploy.sh --show-token das Token nach der Bereitstellung aus.

Lokales Testen mit Kind

Wenn Sie über keinen Cluster verfügen, erstellen Sie mit Kind einen lokalen Cluster:

bash
./scripts/k8s/create-kind.sh           # Erkennt Docker oder Podman automatisch./scripts/k8s/create-kind.sh --delete  # Fährt den Cluster herunter

Führen Sie die Bereitstellung anschließend wie gewohnt mit ./scripts/k8s/deploy.sh durch.

Schritt für Schritt

1) Bereitstellen

Option A: API-Schlüssel in der Umgebung (ein Schritt)

bash
# Durch Ihren Provider ersetzen: ANTHROPIC, GEMINI, OPENAI oder OPENROUTERexport <PROVIDER>_API_KEY="..."./scripts/k8s/deploy.sh

Das Skript erstellt ein Kubernetes-Secret mit dem API-Schlüssel und einem automatisch generierten Gateway-Token und führt anschließend die Bereitstellung durch. Wenn das Secret bereits vorhanden ist, bleiben das aktuelle Gateway-Token und alle nicht geänderten Provider-Schlüssel erhalten.

Option B: Secret separat erstellen

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

Fügen Sie einem der beiden Befehle --show-token hinzu, um das Token für lokale Tests auf der Standardausgabe auszugeben.

2) Auf das Gateway zugreifen

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

Bereitgestellte Ressourcen

text
Namespace: openclaw (über OPENCLAW_NAMESPACE konfigurierbar)├── Deployment/openclaw        # Einzelner Pod, Init-Container + Gateway├── Service/openclaw           # ClusterIP auf Port 18789├── PersistentVolumeClaim      # 10Gi für Agent-Status und Konfiguration├── ConfigMap/openclaw-config  # openclaw.json + AGENTS.md└── Secret/openclaw-secrets    # Gateway-Token + API-Schlüssel

Anpassung

Agent-Anweisungen

Bearbeiten Sie die Datei AGENTS.md in scripts/k8s/manifests/configmap.yaml und stellen Sie sie erneut bereit:

bash
./scripts/k8s/deploy.sh

Gateway-Konfiguration

Bearbeiten Sie openclaw.json in scripts/k8s/manifests/configmap.yaml. Die vollständige Referenz finden Sie unter Gateway-Konfiguration.

Provider hinzufügen

Führen Sie die Bereitstellung mit zusätzlich exportierten Schlüsseln erneut aus:

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

Vorhandene Provider-Schlüssel bleiben im Secret erhalten, sofern Sie sie nicht überschreiben.

Alternativ können Sie das Secret direkt patchen:

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

Benutzerdefinierter Namespace

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

Benutzerdefiniertes Image

Bearbeiten Sie das Feld image in scripts/k8s/manifests/deployment.yaml:

yaml
image: ghcr.io/openclaw/openclaw:slim # Primär; offizieller Docker-Hub-Spiegel: openclaw/openclaw

Zugriff über die Portweiterleitung hinaus ermöglichen

Die Standardmanifeste binden das Gateway innerhalb des Pods an die Loopback-Schnittstelle. Dies funktioniert mit kubectl port-forward, aber nicht über einen Kubernetes-Service oder einen Ingress-Pfad, der direkt auf die Pod-IP zugreifen muss.

So stellen Sie das Gateway über einen Ingress oder Load Balancer bereit:

  • Ändern Sie die Gateway-Bindung in scripts/k8s/manifests/configmap.yaml von loopback in eine Nicht-Loopback-Bindung, die Ihrem Bereitstellungsmodell entspricht.
  • Lassen Sie die Gateway-Authentifizierung aktiviert und verwenden Sie einen geeigneten Einstiegspunkt mit TLS-Terminierung.
  • Konfigurieren Sie die Control UI für den Remotezugriff mit dem unterstützten Web-Sicherheitsmodell (beispielsweise HTTPS/Tailscale Serve und bei Bedarf ausdrücklich zugelassene Ursprünge).

Erneut bereitstellen

bash
./scripts/k8s/deploy.sh

Dadurch werden alle Manifeste angewendet und der Pod neu gestartet, damit Änderungen an der Konfiguration oder an Secrets übernommen werden.

Entfernen

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

Dadurch werden der Namespace und alle darin enthaltenen Ressourcen einschließlich des PVC gelöscht.

Hinweise zur Architektur

  • Das Gateway ist innerhalb des Pods standardmäßig an die Loopback-Schnittstelle gebunden. Die enthaltene Einrichtung ist daher für kubectl port-forward vorgesehen.
  • Keine clusterweiten Ressourcen; alles befindet sich in einem einzelnen Namespace.
  • Sicherheitshärtung: readOnlyRootFilesystem, drop: ALL-Capabilities, Benutzer ohne Root-Rechte (UID 1000).
  • Die Standardkonfiguration belässt die Control UI auf dem sichereren Pfad für den lokalen Zugriff: Loopback-Bindung sowie kubectl port-forward zu http://127.0.0.1:18789.
  • Wenn Sie den Zugriff über localhost hinaus ermöglichen, verwenden Sie das unterstützte Remote-Modell: HTTPS/Tailscale sowie die entsprechenden Einstellungen für die Gateway-Bindung und die zulässigen Ursprünge der Control UI.
  • Secrets werden in einem temporären Verzeichnis generiert und direkt auf den Cluster angewendet; es wird kein Secret-Material in den Repository-Checkout geschrieben.

Dateistruktur

text
scripts/k8s/├── deploy.sh                   # Erstellt Namespace und Secret, stellt über Kustomize bereit├── create-kind.sh              # Lokaler Kind-Cluster (erkennt Docker/Podman automatisch)└── manifests/    ├── kustomization.yaml      # Kustomize-Basis    ├── configmap.yaml          # openclaw.json + AGENTS.md    ├── deployment.yaml         # Pod-Spezifikation mit Sicherheitshärtung    ├── pvc.yaml                # 10Gi persistenter Speicher    └── service.yaml            # ClusterIP auf 18789

Verwandte Themen

Was this useful?
On this page

On this page