Skill Kubernetes pour OpenClaw

Présentation du Skill Kubernetes pour OpenClaw

Le skill Kubernetes connecte OpenClaw à vos clusters Kubernetes via kubectl et un ensemble d'utilitaires de gestion de clusters. Une fois installé, votre agent OpenClaw peut déployer des applications, résoudre les défaillances de pods, mettre à l'échelle les charges de travail, générer des manifests et effectuer des audits de sécurité — le tout grâce à des commandes en langage naturel.

Kubernetes est le standard de l'industrie pour l'orchestration de conteneurs, mais sa surface de commandes CLI est vaste. Le skill OpenClaw Kubernetes élimine le besoin de mémoriser des centaines de sous-commandes et d'options kubectl. Au lieu de basculer entre les fenêtres du terminal et la documentation, vous décrivez ce dont vous avez besoin et l'agent s'occupe du reste.

Flux de travail typique :

1. Demandez à OpenClaw de vérifier l'état de santé de votre cluster de production.
2. L'agent exécute kubectl get nodes, kubectl top pods et des scripts de vérification de santé en arrière-plan.
3. Les résultats sont présentés dans un résumé lisible avec des recommandations concrètes — aucun changement de contexte nécessaire.

Ce skill prend en charge Kubernetes 1.31+, OpenShift 4.17+ et les services managés incluant Amazon EKS, Azure AKS et Google GKE. Il s'associe naturellement avec le skill Docker Essentials pour un flux de travail conteneurisé complet.

Prérequis pour le Skill Kubernetes

Avant d'installer le skill Kubernetes, assurez-vous de disposer de :

• OpenClaw installé et en cours d'exécution (v1.0+)
• kubectl installé (v1.20+) — guide d'installation
• Un fichier kubeconfig valide pointant vers au moins un cluster
• clawhub CLI installé pour la gestion des skills

Vérifiez votre configuration :

# Vérifier la version d'OpenClaw
openclaw --version

# Vérifier la version de kubectl
kubectl version --client

# Vérifier la connectivité au cluster
kubectl cluster-info

# Lister les contextes disponibles
kubectl config get-contexts

Si kubectl cluster-info renvoie une erreur, assurez-vous que votre kubeconfig est correctement configuré. Pour les clusters managés, utilisez le CLI de votre fournisseur pour générer les identifiants (par exemple, aws eks update-kubeconfig, az aks get-credentials ou gcloud container clusters get-credentials).

Comment Installer le Skill Kubernetes

Installez le skill Kubernetes avec une seule commande :

npx clawhub@latest install kubernetes

Pour vérifier l'installation :

clawhub list

Vous devriez voir kubernetes dans la liste des skills installés. Le skill inclut des scripts utilitaires pour les vérifications de santé des clusters, les audits de sécurité, la maintenance des nœuds et la génération de manifests.

Configuration du Skill Kubernetes

Le skill Kubernetes s'appuie sur votre kubeconfig existant pour l'authentification. Aucune clé API ni jeton supplémentaire n'est requis — si kubectl fonctionne sur votre machine, le skill fonctionne également.

Configuration du Kubeconfig

Le skill lit le kubeconfig par défaut situé à ~/.kube/config. Pour utiliser un fichier différent ou gérer plusieurs clusters :

# Définir un chemin kubeconfig personnalisé
export KUBECONFIG=/path/to/your/kubeconfig

# Fusionner plusieurs fichiers kubeconfig
export KUBECONFIG=~/.kube/config:~/.kube/staging-config

# Basculer entre les contextes
kubectl config use-context production-cluster

Portée des Namespaces

Pour des raisons de sécurité, nous recommandons de limiter le skill à des namespaces spécifiques plutôt que d'accorder un accès à l'ensemble du cluster :

# Définir un namespace par défaut pour le contexte actuel
kubectl config set-context --current --namespace=my-app

# Vérifier le namespace actif
kubectl config view --minify --output 'jsonpath={..namespace}'

Important : N'accordez jamais au skill les privilèges cluster-admin en production. Utilisez des rôles RBAC limités aux namespaces et aux ressources dont vous avez réellement besoin. Consultez la section Sécurité et Bonnes Pratiques ci-dessous.

Exemples d'Utilisation du Skill Kubernetes

1. Diagnostiquer les Crashs de Pods

Vous : « Pourquoi les pods dans le namespace payments plantent-ils ? »

L'agent exécute kubectl get pods -n payments, identifie les pods en état CrashLoopBackOff, récupère les journaux avec kubectl logs et vérifie les événements avec kubectl describe pod. Il retourne un diagnostic comme « OOMKilled — le conteneur a dépassé sa limite de mémoire de 256Mi. Nous recommandons de l'augmenter à 512Mi. »

2. Mettre à l'Échelle un Déploiement

Vous : « Mettez à l'échelle le déploiement API à 5 réplicas dans staging. »

L'agent exécute kubectl scale deployment api --replicas=5 -n staging, surveille le déploiement avec kubectl rollout status et confirme lorsque les 5 pods sont en cours d'exécution et en bonne santé.

3. Générer un Manifest de Production

Vous : « Créez un manifest de déploiement pour une application Node.js avec 3 réplicas, une limite de mémoire de 256Mi, des vérifications de santé et un service ClusterIP. »

L'agent utilise le générateur de manifests intégré pour produire un fichier YAML complet avec des paramètres de sécurité par défaut — utilisateur non-root, système de fichiers en lecture seule, limites de ressources, sondes de vivacité et de disponibilité, et une définition de Service correspondante.

4. Exécuter un Audit de Sécurité

Vous : « Auditez le namespace default pour détecter les problèmes de sécurité. »

L'agent exécute le script d'audit de sécurité intégré, vérifiant les conteneurs exécutés en tant que root, les limites de ressources manquantes, les liaisons RBAC trop permissives et les pods sans labels Pod Security Standards. Les résultats sont présentés sous forme de liste de problèmes classés par priorité avec des étapes de remédiation.

5. Effectuer une Mise à Jour Progressive

Vous : « Mettez à jour le déploiement web vers l'image v2.3.1 et surveillez le déploiement. »

L'agent exécute kubectl set image deployment/web web=myregistry/web:v2.3.1, puis surveille kubectl rollout status en temps réel. Si le déploiement stagne ou si les pods échouent aux vérifications de santé, il vous alerte et suggère kubectl rollout undo pour revenir en arrière.

Sécurité et Bonnes Pratiques

Les opérations Kubernetes peuvent affecter les charges de travail en production. Suivez ces recommandations pour rester en sécurité :

• Utilisez le RBAC avec le principe du moindre privilège. Créez des ServiceAccounts dédiés avec uniquement les permissions nécessaires. Évitez cluster-admin pour les opérations quotidiennes. La documentation RBAC de Kubernetes détaille la création de rôles.
• Limitez la portée aux namespaces. Définissez un namespace par défaut dans le contexte de votre kubeconfig afin que le skill ne puisse pas modifier accidentellement les ressources dans d'autres namespaces.
• Vérifiez avant d'appliquer. OpenClaw demande une confirmation avant les opérations destructrices comme la suppression de pods, la mise à l'échelle à zéro ou le drainage de nœuds. Vérifiez toujours les modifications proposées.
• Utilisez le mode dry-run. Pour la génération de manifests et les opérations d'application, le skill prend en charge --dry-run=client pour prévisualiser les modifications sans affecter le cluster.
• Renouvelez régulièrement les identifiants. Si vous utilisez des jetons de compte de service, définissez des politiques d'expiration. Pour les clusters managés, appuyez-vous sur les identifiants à durée de vie courte du fournisseur cloud.
• Activez la journalisation d'audit. Configurez la journalisation d'audit Kubernetes pour suivre tous les appels API effectués via le skill. Consultez la Liste de contrôle de sécurité pour les recommandations générales de sécurité d'OpenClaw.

Résolution des Erreurs Courantes

« error: You must be logged in to the server (Unauthorized) »

Vos identifiants kubeconfig ont expiré ou sont invalides.

# Pour AWS EKS
aws eks update-kubeconfig --name my-cluster --region us-east-1

# Pour Azure AKS
az aks get-credentials --resource-group myRG --name my-cluster

# Pour Google GKE
gcloud container clusters get-credentials my-cluster --zone us-central1-a

« error: the server doesn't have a resource type 'deployments' »

Le serveur API peut être inaccessible, ou vos permissions RBAC sont insuffisantes.

1. Exécutez kubectl cluster-info pour vérifier la connectivité.
2. Vérifiez que votre rôle dispose des permissions get, list et watch sur le groupe API apps/v1.
3. Demandez à l'administrateur de votre cluster de vérifier votre RoleBinding.

« pod has unbound immediate PersistentVolumeClaims »

Le pod nécessite un PersistentVolume qui n'existe pas ou n'est pas encore provisionné.

1. Exécutez kubectl get pvc -n <namespace> pour vérifier le statut de la demande.
2. Vérifiez que la StorageClass existe : kubectl get storageclass.
3. Pour les fournisseurs cloud, assurez-vous que le pilote CSI est installé et que le quota de stockage n'est pas dépassé.