Por qué no Helm
OpenClaw es un único contenedor con algunos archivos de configuración. La personalización interesante está en el contenido del agente (archivos Markdown, skills, sobrescrituras de configuración), no en las plantillas de infraestructura. Kustomize gestiona superposiciones sin la sobrecarga de un chart de Helm. Añade un chart de Helm encima de estos manifiestos si tu despliegue se vuelve más complejo.Qué necesitas
- Un clúster de Kubernetes en ejecución (AKS, EKS, GKE, k3s, kind, OpenShift, etc.)
kubectlconectado a tu clúster- Una clave de API para al menos un proveedor de modelos
Inicio rápido
deploy.sh crea autenticación por token de forma predeterminada. Recupera el token generado del Gateway para la Control UI:
./scripts/k8s/deploy.sh --show-token imprime el token después del despliegue.
Pruebas locales con Kind
Si no tienes un clúster, crea uno localmente con Kind:./scripts/k8s/deploy.sh.
Paso a paso
1) Desplegar
Opción A: clave de API en el entorno (un paso)--show-token a cualquiera de los comandos para imprimir el token en stdout para pruebas locales.
2) Acceder al Gateway
Qué se despliega
Personalización
Instrucciones del agente
Edita elAGENTS.md en scripts/k8s/manifests/configmap.yaml y vuelve a desplegar:
Configuración del Gateway
Editaopenclaw.json en scripts/k8s/manifests/configmap.yaml. Consulta Configuración del Gateway para ver la referencia completa.
Añadir proveedores
Vuelve a ejecutar con claves adicionales exportadas:Espacio de nombres personalizado
Imagen personalizada
Edita el campoimage en scripts/k8s/manifests/deployment.yaml:
Exponer más allá de port-forward
Los manifiestos predeterminados enlazan el Gateway a loopback dentro del pod. Eso funciona conkubectl port-forward, pero no con un Service de Kubernetes o una ruta de Ingress que necesite llegar directamente a la IP del pod.
Para exponer el Gateway mediante un Ingress o un balanceador de carga:
- Cambia el enlace del Gateway en
scripts/k8s/manifests/configmap.yamldeloopbacka un enlace que no sea loopback y que coincida con tu modelo de despliegue. - Mantén habilitada la autenticación del Gateway y usa un punto de entrada adecuado con terminación TLS.
- Configura la Control UI para acceso remoto usando el modelo de seguridad web admitido (por ejemplo, HTTPS/Tailscale Serve y orígenes permitidos explícitos cuando sea necesario).
Volver a desplegar
Desmontaje
Notas de arquitectura
- El Gateway se enlaza a loopback dentro del pod de forma predeterminada, por lo que la configuración incluida es para
kubectl port-forward. - No hay recursos con ámbito de clúster; todo vive en un único espacio de nombres.
- Refuerzo de seguridad:
readOnlyRootFilesystem, capacidadesdrop: ALL, usuario no root (UID 1000). - La configuración predeterminada mantiene la Control UI en la ruta de acceso local más segura: enlace loopback más
kubectl port-forwardahttp://127.0.0.1:18789. - Si vas más allá del acceso localhost, usa el modelo remoto admitido: HTTPS/Tailscale más el enlace de Gateway adecuado y la configuración de orígenes de la Control UI.
- Los secretos se generan en un directorio temporal y se aplican directamente al clúster; no se escribe material secreto en el checkout del repositorio.