Skip to main content
Een minimaal startpunt om OpenClaw op Kubernetes uit te voeren, geen productieklare implementatie. Het omvat de kernresources en is bedoeld om aan je omgeving te worden aangepast.

​
Waarom geen Helm

OpenClaw is één container met enkele configuratiebestanden. De relevante aanpassingen zitten in de agentinhoud (Markdown-bestanden, Skills, configuratieoverschrijvingen), niet in infrastructuursjablonen. Kustomize verwerkt overlays zonder de overhead van een Helm-chart. Voeg boven op deze manifesten een Helm-chart toe als je implementatie complexer wordt.

​
Wat je nodig hebt

  • Een actief Kubernetes-cluster (AKS, EKS, GKE, k3s, kind, OpenShift enz.)
  • kubectl verbonden met je cluster
  • Een API-sleutel voor ten minste één modelprovider

​
Snel aan de slag

deploy.sh maakt standaard tokenauthenticatie aan. Haal het gegenereerde Gateway-token op voor de Control UI:
Voor lokaal debuggen drukt ./scripts/k8s/deploy.sh --show-token het token na de implementatie af.

​
Lokaal testen met Kind

Als je geen cluster hebt, maak er dan lokaal een aan met Kind:
Implementeer vervolgens zoals gebruikelijk met ./scripts/k8s/deploy.sh.

​
Stap voor stap

​
1) Implementeren

Optie A: API-sleutel in de omgeving (één stap)
Het script maakt een Kubernetes Secret aan met de API-sleutel en een automatisch gegenereerd Gateway-token en voert vervolgens de implementatie uit. Als het Secret al bestaat, blijven het huidige Gateway-token en alle providersleutels die niet worden gewijzigd behouden. Optie B: maak het Secret afzonderlijk aan
Voeg --show-token aan een van beide opdrachten toe om het token voor lokaal testen naar stdout te schrijven.

​
2) Toegang tot de Gateway

​
Wat er wordt geïmplementeerd

​
Aanpassingen

​
Agentinstructies

Bewerk de AGENTS.md in scripts/k8s/manifests/configmap.yaml en implementeer opnieuw:

​
Gateway-configuratie

Bewerk openclaw.json in scripts/k8s/manifests/configmap.yaml. Zie Gateway-configuratie voor de volledige referentie.

​
Providers toevoegen

Voer de implementatie opnieuw uit nadat je aanvullende sleutels hebt geëxporteerd:
Bestaande providersleutels blijven in het Secret staan, tenzij je ze overschrijft. Of patch het Secret rechtstreeks:

​
Aangepaste namespace

​
Aangepaste image

Bewerk het veld image in scripts/k8s/manifests/deployment.yaml:

​
Beschikbaar maken buiten port-forward

De standaardmanifesten koppelen de Gateway binnen de pod aan de loopbackinterface. Dat werkt met kubectl port-forward, maar niet met een Kubernetes-Service of Ingress-pad dat het IP-adres van de pod rechtstreeks moet bereiken. Ga als volgt te werk om de Gateway via een Ingress of loadbalancer beschikbaar te maken:
  • Wijzig de Gateway-binding in scripts/k8s/manifests/configmap.yaml van loopback in een niet-loopbackbinding die overeenkomt met je implementatiemodel.
  • Houd Gateway-authenticatie ingeschakeld en gebruik een correct TLS-beëindigd toegangspunt.
  • Configureer de Control UI voor externe toegang met het ondersteunde webbeveiligingsmodel (bijvoorbeeld HTTPS/Tailscale Serve en indien nodig expliciet toegestane origins).

​
Opnieuw implementeren

Hiermee worden alle manifesten toegepast en wordt de pod opnieuw gestart om eventuele wijzigingen in de configuratie of secrets op te halen.

​
Verwijderen

Hiermee worden de namespace en alle resources daarin verwijderd, inclusief de PVC.

​
Architectuurnotities

  • De Gateway wordt binnen de pod standaard aan de loopbackinterface gekoppeld, dus de meegeleverde configuratie is bedoeld voor kubectl port-forward.
  • Er zijn geen clusterbrede resources; alles bevindt zich in één namespace.
  • Beveiligingsversterking: readOnlyRootFilesystem, drop: ALL capabilities, gebruiker zonder rootrechten (UID 1000).
  • De standaardconfiguratie houdt de Control UI op het veiligere pad voor lokale toegang: loopbackbinding plus kubectl port-forward naar http://127.0.0.1:18789.
  • Als je verder gaat dan localhost-toegang, gebruik dan het ondersteunde externe model: HTTPS/Tailscale plus de juiste Gateway-binding en origin-instellingen voor de Control UI.
  • Secrets worden in een tijdelijke map gegenereerd en rechtstreeks op het cluster toegepast; er wordt geen geheim materiaal naar de repo-checkout geschreven.

​
Bestandsstructuur

​
Gerelateerd