Skip to main content
Un point de départ minimal pour exécuter OpenClaw sur Kubernetes, et non un déploiement prêt pour la production. Il couvre les ressources essentielles et doit être adapté à votre environnement.

​
Pourquoi ne pas utiliser Helm

OpenClaw est un conteneur unique accompagné de quelques fichiers de configuration. Les personnalisations pertinentes concernent le contenu de l’agent (fichiers Markdown, Skills, substitutions de configuration), et non la création de modèles d’infrastructure. Kustomize gère les superpositions sans la charge supplémentaire d’un chart Helm. Ajoutez un chart Helm au-dessus de ces manifestes si votre déploiement devient plus complexe.

​
Prérequis

  • Un cluster Kubernetes opérationnel (AKS, EKS, GKE, k3s, kind, OpenShift, etc.)
  • kubectl connecté à votre cluster
  • Une clé d’API pour au moins un fournisseur de modèles

​
Démarrage rapide

Par défaut, deploy.sh crée une authentification par jeton. Récupérez le jeton Gateway généré pour l’interface de contrôle :
Pour le débogage local, ./scripts/k8s/deploy.sh --show-token affiche le jeton après le déploiement.

​
Tests locaux avec Kind

Si vous ne disposez pas d’un cluster, créez-en un localement avec Kind :
Déployez ensuite normalement avec ./scripts/k8s/deploy.sh.

​
Étapes détaillées

​
1) Déployer

Option A : clé d’API dans l’environnement (une seule étape)
Le script crée un Secret Kubernetes contenant la clé d’API et un jeton Gateway généré automatiquement, puis effectue le déploiement. Si le Secret existe déjà, il conserve le jeton Gateway actuel ainsi que toutes les clés de fournisseur qui ne sont pas modifiées. Option B : créer le Secret séparément
Ajoutez --show-token à l’une ou l’autre commande pour afficher le jeton sur la sortie standard lors des tests locaux.

​
2) Accéder au Gateway

​
Ressources déployées

​
Personnalisation

​
Instructions de l’agent

Modifiez le fichier AGENTS.md dans scripts/k8s/manifests/configmap.yaml, puis redéployez :

​
Configuration du Gateway

Modifiez openclaw.json dans scripts/k8s/manifests/configmap.yaml. Consultez la configuration du Gateway pour obtenir la référence complète.

​
Ajouter des fournisseurs

Réexécutez le déploiement après avoir exporté les clés supplémentaires :
Les clés de fournisseur existantes restent dans le Secret, sauf si vous les remplacez. Vous pouvez également modifier directement le Secret :

​
Espace de noms personnalisé

​
Image personnalisée

Modifiez le champ image dans scripts/k8s/manifests/deployment.yaml :

​
Exposer le service au-delà de la redirection de port

Les manifestes par défaut lient le Gateway à local loopback dans le pod. Cela fonctionne avec kubectl port-forward, mais pas avec un Service Kubernetes ou un chemin Ingress qui doit accéder directement à l’adresse IP du pod. Pour exposer le Gateway au moyen d’un Ingress ou d’un équilibreur de charge :
  • Dans scripts/k8s/manifests/configmap.yaml, remplacez la liaison du Gateway loopback par une liaison qui n’utilise pas local loopback et qui correspond à votre modèle de déploiement.
  • Maintenez l’authentification du Gateway activée et utilisez un point d’entrée approprié avec terminaison TLS.
  • Configurez l’interface de contrôle pour l’accès distant à l’aide du modèle de sécurité Web pris en charge (par exemple, HTTPS/Tailscale Serve et des origines autorisées explicites si nécessaire).

​
Redéployer

Cette commande applique tous les manifestes et redémarre le pod afin de prendre en compte toute modification de configuration ou de Secret.

​
Suppression

Cette commande supprime l’espace de noms et toutes les ressources qu’il contient, y compris le PVC.

​
Remarques sur l’architecture

  • Par défaut, le Gateway est lié à local loopback dans le pod ; la configuration fournie est donc destinée à kubectl port-forward.
  • Aucune ressource à l’échelle du cluster ; tout se trouve dans un seul espace de noms.
  • Renforcement de la sécurité : readOnlyRootFilesystem, capacités drop: ALL, utilisateur non-root (UID 1000).
  • La configuration par défaut maintient l’interface de contrôle sur la voie d’accès local la plus sûre : liaison local loopback et kubectl port-forward vers http://127.0.0.1:18789.
  • Si vous étendez l’accès au-delà de localhost, utilisez le modèle distant pris en charge : HTTPS/Tailscale, avec la liaison Gateway et les paramètres d’origine de l’interface de contrôle appropriés.
  • Les secrets sont générés dans un répertoire temporaire et appliqués directement au cluster ; aucun contenu secret n’est écrit dans la copie de travail du dépôt.

​
Structure des fichiers

​
Pages connexes