Un punto di partenza minimale per eseguire OpenClaw su Kubernetes: non un deployment pronto per la produzione. Copre le risorse principali ed è pensato per essere adattato al tuo ambiente.Documentation Index
Fetch the complete documentation index at: https://docs.openclaw.ai/llms.txt
Use this file to discover all available pages before exploring further.
Perché non Helm?
OpenClaw è un singolo container con alcuni file di configurazione. La personalizzazione più rilevante riguarda il contenuto degli agenti (file Markdown, Skills, override di configurazione), non il templating dell’infrastruttura. Kustomize gestisce gli overlay senza il sovraccarico di un chart Helm. Se il deployment diventa più complesso, è possibile aggiungere un chart Helm sopra questi manifest.Cosa serve
- Un cluster Kubernetes in esecuzione (AKS, EKS, GKE, k3s, kind, OpenShift, ecc.)
kubectlconnesso al tuo cluster- Una chiave API per almeno un provider di modelli
Avvio rapido
./scripts/k8s/deploy.sh --show-token stampa il token dopo il deployment.
Test locale con Kind
Se non hai un cluster, creane uno in locale con Kind:./scripts/k8s/deploy.sh.
Passo per passo
1) Esegui il deployment
Opzione A — chiave API nell’ambiente (un solo passaggio):--show-token con uno dei due comandi se vuoi stampare il token su stdout per il test locale.
2) Accedi al gateway
Cosa viene distribuito
Personalizzazione
Istruzioni per l’agente
ModificaAGENTS.md in scripts/k8s/manifests/configmap.yaml ed esegui di nuovo il deployment:
Configurazione del Gateway
Modificaopenclaw.json in scripts/k8s/manifests/configmap.yaml. Consulta Configurazione del Gateway per il riferimento completo.
Aggiungere provider
Esegui di nuovo con chiavi aggiuntive esportate:Namespace personalizzato
Immagine personalizzata
Modifica il campoimage in scripts/k8s/manifests/deployment.yaml:
Esporre oltre il port-forward
I manifest predefiniti associano il Gateway a loopback all’interno del pod. Questo funziona conkubectl port-forward, ma non funziona con un Service Kubernetes o un percorso Ingress che deve raggiungere l’IP del pod.
Se vuoi esporre il Gateway tramite un Ingress o un bilanciatore di carico:
- Cambia il bind del Gateway in
scripts/k8s/manifests/configmap.yamldaloopbacka un bind non loopback compatibile con il tuo modello di deployment - Mantieni l’autenticazione del Gateway abilitata e usa un entrypoint adeguato con terminazione TLS
- Configura la Control UI per l’accesso remoto usando il modello di sicurezza web supportato (per esempio HTTPS/Tailscale Serve e origini consentite esplicite quando necessario)
Rieseguire il deployment
Rimozione
Note sull’architettura
- Il Gateway si associa per impostazione predefinita a loopback all’interno del pod, quindi la configurazione inclusa è per
kubectl port-forward - Nessuna risorsa con ambito cluster: tutto risiede in un singolo namespace
- Sicurezza:
readOnlyRootFilesystem, capabilitydrop: ALL, utente non root (UID 1000) - La configurazione predefinita mantiene la Control UI sul percorso più sicuro di accesso locale: bind loopback più
kubectl port-forwardversohttp://127.0.0.1:18789 - Se passi oltre l’accesso localhost, usa il modello remoto supportato: HTTPS/Tailscale più il bind Gateway appropriato e le impostazioni di origine della Control UI
- I secret vengono generati in una directory temporanea e applicati direttamente al cluster: nessun materiale segreto viene scritto nel checkout del repository