L’IA avec Kubernetes : La promesse du kubectl en langage naturel

Différencier les outils

Dans les documentations officielles, Kubiya est présenté comme une interface d’orchestration en langage naturel capable de coordonner agents, équipes, environnements et workflows.

K8sGPT est lui décrit comme un outil qui scanne les clusters Kubernetes, diagnostique les incidents et les explique en langage clair.

Autrement dit, quand on parle d’assistant IA pour Kubernetes, il faut déjà distinguer deux familles d’usage :

• La première cherche à transformer une intention humaine en action contrôlée.
• La seconde cherche à transformer l’état technique d’un cluster en diagnostic compréhensible.

C’est précisément pour cela que comparer Kubiya et K8sGPT est intéressant : ils évoluent sur le même terrain sémantique, mais pas sur la même couche opérationnelle.

Une maitrise en profondeur de l’architecture Kubernetes est cruciale pour optimiser l’efficacité des outils de pilotage IA.
Notre formation Kubernetes avancé vous permettra de maitriser tout les niveaux de vos infrastructures CLoud Natives.

L’équipe Ambient IT

Kubiya : du prompt à l’action

Vous êtes là pour ça donc autant le dire tout de suite : la promesse qui ressemble le plus à “écrire une commande Kubernetes à partir d’un prompt” se retrouve surtout chez Kubiya.

Sa documentation décrit le Meta Agent comme une couche d’orchestration en langage naturel, construite sur MCP, qui comprend l’intention de l’utilisateur puis coordonne les ressources, agents, équipes et workflows adaptés.

Ce n’est pas seulement un chatbot qui suggère une ligne de commande : c’est une interface qui peut choisir le bon contexte d’exécution et lancer une tâche réelle.

Cette logique est encore plus claire dans la documentation d’On-Demand Execution. Kubiya y détaille un cycle d’exécution complet : analyse du prompt, découverte des ressources disponibles, sélection de l’agent, estimation du coût, génération d’un plan, éventuelle approbation humaine, choix d’une file de workers, exécution de la tâche et streaming en temps réel des résultats.

Il faut noter également que Kubiya documente aussi une vraie couche de gouvernance. Les policies sont pilotées avec OPA, afin d’encadrer les agents, tâches et workflows.

K8sGPT : analyser et expliquer Kubernetes

Avant d’aborder K8sGPT, il faut comprendre que ce n’est PAS un outil pensé pour exécuter des ordres généraux en langage naturel.

Son dépôt officiel le présente comme un outil pour scanner les clusters Kubernetes, diagnostiquer et trier les problèmes.

Le workflow standard pourrait se résumer comme ça : La référence CLI met surtout en avant k8sgpt analyze --explain, avec des variantes pour filtrer par type de ressource, cibler un namespace, sortir du JSON et anonymiser certaines données lors de l’explication.

K8sGPT est aussi plus souple qu’un simple wrapper autour d’un seul modèle. Il est compatible avec de nombreux backends, dont OpenAI, Azure OpenAI, Amazon Bedrock, Google Gemini, Hugging Face, LocalAI ou Ollama.

Cela renforce son rôle d’analyste Kubernetes enrichi par l’IA, plutôt que comme assistant unique lié à un fournisseur précis.

Si vous n’étiez pas convaincu, son operator confirme encore cette orientation. Le projet k8sgpt-operator est décrit comme un opérateur destiné à exécuter K8sGPT directement dans le cluster via une custom resource qui définit le comportement et le périmètre du workload.

Sur le terrain : quelle différence pour une équipe DevOps ?

La différence la plus simple à retenir est la suivante :

• Kubiya aide à agir, K8sGPT aide à comprendre. Kubiya prend une intention, trouve les bons agents et le bon environnement, prépare un plan, peut demander une validation et exécute la tâche via des workers.
• K8sGPT, lui, inspecte le cluster, applique ses analyzers, puis retourne un diagnostic enrichi par l’IA.

La question qui fâche : Peut-on vraiment générer des commandes kubectl à partir d’un prompt ?

Pour être très clair : oui, mais il faut être précis sur le type d’outil.

Chez Kubiya, les exemples officiels montrent bien un usage où un prompt déclenche un agent DevOps qui exécute ensuite des commandes kubectl pour vérifier l’état d’un cluster.

Chez K8sGPT, la promesse centrale est différente. Sa CLI et son dépôt mettent l’accent sur l’analyse, les explications, les filtres et l’operator, pas sur un flux généraliste de génération puis d’exécution de commandes Kubernetes.

Cela ne veut pas dire que l’outil est moins utile ; cela veut simplement dire qu’il répond à une autre question : “qu’est-ce qui ne va pas dans mon cluster ?” plutôt que “quelle action dois-je exécuter maintenant ?”.

Sécurité des données : le vrai enjeu pour les DevOps modernes

Dès qu’on parle d’IA pour Kubernetes en production, le sujet n’est plus seulement l’ergonomie. Il devient aussi question de permissions, de validation humaine et d’exposition de données.

Chez Kubiya, il existe des OPA pour les garde-fous, ainsi que la gestion sécurisée des connecteurs, le chiffrement des credentials et l’audit trail.

Pour K8sGPT, l’utilisation de l’option --anonymize est la norme. De plus, lorsque l’IA est activée, les réponses enrichies peuvent impliquer une communication hors cluster vers le backend choisi ; vous pouvez choisir de désactiver ce traitement IA.

C’est sans doute la chose la plus importante à garder en tête : l’IA Kubernetes devient vraiment intéressante quand elle s’insère dans un cadre opérationnel sérieux.

Sans politiques, sans audit et sans contrôle du périmètre, “faire des commandes depuis un prompt” reste une promesse séduisante mais fragile.