Aller au contenu

Assistants IA et agents

Que vous travailliez avec Claude, Cursor, Copilot ou un agent qui pilote kubectl, votre assistant IA est un utilisateur de la plateforme comme un autre. Nous l’outillons comme tel — voici tout ce qui est en place pour qu’il soit efficace chez nous, et pourquoi ça change votre quotidien.

Un assistant généraliste connaît Kubernetes, pas Kontainers : il vous proposera spontanément des manifests presque justes (une limite mémoire différente de la request, un Service LoadBalancer par réflexe…). La parade tient en une URL — cette documentation est publiée au format llms.txt, le standard de documentation lisible par les LLM :

URL Contenu Usage
/llms.txt L’index + les spécificités plateforme essentielles Point d’entrée, découverte automatique par les outils
/llms-full.txt Les 40+ pages en markdown brut, Référence en tête À charger dans le contexte de votre assistant
/llms-small.txt Version compacte Petites fenêtres de contexte

En pratique :

Lis https://docs.blackswift.cloud/llms-full.txt puis génère le manifest
de déploiement de mon application sur mon namespace Kontainers.

Un assistant qui a lu ces pages produit spontanément des manifests conformes : requests = limits en mémoire, Ingress plutôt que LoadBalancer, classes de stockage correctes, CNPG pour PostgreSQL.

Le talon d’Achille des agents IA sur un cluster managé : les lectures interdites. Un agent qui enchaîne les Forbidden sur events ou resourcequotas abandonne — ou pire, invente. Sur Kontainers, le rôle client a été élargi précisément pour que la boucle de diagnostic se fasse sans intervention humaine :

Symptôme Ce que votre agent peut lire
Pod qui ne se crée pas events, conditions du ReplicaSet, resourcequotas (avec le message de rejet exact)
OOMKilled describe pod, kubectl top pods, limitranges
Certificat bloqué Toute la chaîne ACME : certificates, certificaterequests, orders, challenges
Connexion refusée Les networkpolicies réellement appliquées, endpointslices

Et les messages d’erreur de la plateforme sont documentés verbatim : quand votre agent rencontre un rejet Kyverno ou PodSecurity, le texte exact de l’erreur est cherchable dans cette doc — donc dans son llms-full.txt.

Un accès dédié, borné et révocable pour vos agents

Section intitulée « Un accès dédié, borné et révocable pour vos agents »

Ne prêtez pas votre kubeconfig personnel à un agent. Créez-lui un kubeconfig permanent :

  • périmètre limité à un namespace — l’agent ne voit rien d’autre ;
  • n’expire pas en pleine session de travail ;
  • révocable en une commande (kubectl delete blackswiftpermanentkubeconfig) ;
  • traçable : la colonne LAST USED vous dit s’il sert encore.

Et si votre agent s’emballe, les garde-fous de la plateforme jouent pour lui comme pour vous : quotas plafonnés, requests injectées, pods privilégiés rejetés, namespaces des autres clients inaccessibles par design. Un agent ne peut ni faire déborder votre facture au-delà des quotas, ni toucher au reste du cluster.

Des exemples que votre IA peut recopier les yeux fermés

Section intitulée « Des exemples que votre IA peut recopier les yeux fermés »

Chaque exemple de cette documentation (WordPress, stack complète, n8n…) a été réellement déployé et testé sur la plateforme avant publication. Un assistant qui s’en inspire part d’une base qui fonctionne — pas d’un extrait de blog de 2021.

Un assistant outillé reste un assistant : relisez ce qu’il applique sur un namespace de production, et préférez lui donner un namespace de dev pour itérer (les environnements sont faits pour ça). La sauvegarde quotidienne est votre filet — pour vous comme pour lui.