Por que não Helm?
O OpenClaw é um único contêiner com alguns arquivos de configuração. A personalização mais relevante está no conteúdo dos agentes (arquivos markdown, Skills, substituições de configuração), não na modelagem de infraestrutura. O Kustomize lida com sobreposições sem a sobrecarga de um chart Helm. Se sua implantação ficar mais complexa, um chart Helm pode ser aplicado sobre estes manifests.O que você precisa
- Um cluster Kubernetes em execução (AKS, EKS, GKE, k3s, kind, OpenShift etc.)
kubectlconectado ao seu cluster- Uma chave de API para pelo menos um provedor de modelos
Início rápido
./scripts/k8s/deploy.sh --show-token imprime o token após a implantação.
Teste local com Kind
Se você não tiver um cluster, crie um localmente com Kind:./scripts/k8s/deploy.sh.
Passo a passo
1) Implantar
Opção A — chave de API no ambiente (uma etapa):--show-token com qualquer comando se quiser que o token seja impresso em stdout para teste local.
2) Acessar o Gateway
O que é implantado
Personalização
Instruções do agente
Edite oAGENTS.md em scripts/k8s/manifests/configmap.yaml e reimplante:
Configuração do Gateway
Editeopenclaw.json em scripts/k8s/manifests/configmap.yaml. Consulte Configuração do Gateway para a referência completa.
Adicionar provedores
Execute novamente com chaves adicionais exportadas:Namespace personalizado
Imagem personalizada
Edite o campoimage em scripts/k8s/manifests/deployment.yaml:
Expor além do port-forward
Os manifests padrão vinculam o Gateway ao loopback dentro do pod. Isso funciona comkubectl port-forward, mas não funciona com um Service do Kubernetes ou um caminho de Ingress que precise alcançar o IP do pod.
Se você quiser expor o Gateway por meio de um Ingress ou balanceador de carga:
- Altere o bind do Gateway em
scripts/k8s/manifests/configmap.yamldeloopbackpara um bind não loopback que corresponda ao seu modelo de implantação - Mantenha a autenticação do Gateway habilitada e use um ponto de entrada adequado com TLS encerrado
- Configure a Control UI para acesso remoto usando o modelo de segurança web compatível (por exemplo, HTTPS/Tailscale Serve e origens explicitamente permitidas quando necessário)
Reimplantar
Remoção
Observações de arquitetura
- O Gateway se vincula ao loopback dentro do pod por padrão, portanto a configuração incluída é para
kubectl port-forward - Nenhum recurso com escopo de cluster — tudo fica em um único namespace
- Segurança: recursos
readOnlyRootFilesystem,drop: ALL, usuário não root (UID 1000) - A configuração padrão mantém a Control UI no caminho mais seguro de acesso local: bind de loopback mais
kubectl port-forwardparahttp://127.0.0.1:18789 - Se você for além do acesso por localhost, use o modelo remoto compatível: HTTPS/Tailscale mais o bind de Gateway apropriado e as configurações de origem da Control UI
- Os segredos são gerados em um diretório temporário e aplicados diretamente ao cluster — nenhum material secreto é gravado no checkout do repositório