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.
Donnez cette documentation à votre IA
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 manifestde 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.
Un RBAC qui permet le diagnostic autonome
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
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 USEDvous 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
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.
Le mot de prudence
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.