La commande Helm peut tenir sur une ligne. Le déploiement en production, non.

Déployer des agents IA sur Kubernetes revient à opérer une application stateful qui dépend de bases de données, secrets, API externes, stockage, ingress, TLS, observabilité et mécanismes de reprise. Le conteneur n’est qu’une partie de l’ensemble.

Ce guide transforme le retour d’expérience DEV.to “The Honest One-Command Version” en méthode de déploiement réutilisable, adaptée aux contraintes d’une vraie production.

Faut-il déployer ses agents IA sur Kubernetes ?

Kubernetes est pertinent lorsque l’entreprise dispose déjà d’une culture plateforme et cherche :

• un déploiement auto-hébergé ou privé ;

• des contrôles standardisés d’identité, secrets et réseau ;

• plusieurs services applicatifs ;

• des dépendances persistantes ;

• de l’autoscaling ;

• des rollouts contrôlés et GitOps ;

• une portabilité cloud ou on-premise.

Pour un agent simple et stateless, Kubernetes peut être inutilement complexe. Si un service managé couvre les besoins de disponibilité et conformité, il peut être préférable.

Le chemin complet d’un déploiement Kubernetes

image conteneur → namespace → secrets → base/stockage → runtime → service → ingress → TLS → DNS → probes → observabilité → sauvegarde → stratégie de rollout

Helm peut décrire beaucoup de ces ressources, mais pas fournir à lui seul toutes les capacités dont elles dépendent.

1. Conteneuriser correctement le runtime

• versions d’image immuables ;

• dépendances figées ;

• utilisateur non-root lorsque possible ;

• endpoints de readiness et liveness ;

• gestion propre des signaux d’arrêt ;

• aucun état métier critique limité au filesystem du conteneur.

2. Isoler le workload

Utilisez un namespace dédié, un ServiceAccount explicite et le minimum de droits RBAC. Un agent ne doit pas obtenir des permissions Kubernetes larges simplement parce qu’il tourne dans le cluster.

3. Gérer les secrets comme une vraie dépendance d’infrastructure

Clés API, credentials de base et secrets de signature doivent suivre un cycle de vie clair : stockage, rotation, audit et révocation. Kubernetes Secrets n’est qu’une interface, pas une stratégie complète.

4. Décider où vit l’état durable

Les agents peuvent nécessiter :

• sessions et événements de conversation ;

• états de runs ;

• mémoire long terme ;

• documents et artefacts ;

• queues et événements ;

• données vectorielles ou relationnelles.

Un pod qui redémarre proprement ne garantit pas que l’état applicatif survive. Voir gestion de l’état des agents IA.

5. StorageClass et volumes persistants sont spécifiques au cluster

Un chart Helm peut créer un PersistentVolumeClaim. Encore faut-il qu’un StorageClass et un provisioner puissent réellement le satisfaire.

• StorageClass disponible ;

• mode d’accès compatible ;

• capacité suffisante ;

• expansion connue ;

• snapshots ou backups disponibles ;

• procédure de restauration testée.

6. Installer avec Helm, mais versionner les valeurs

helm upgrade --install apowerb oci://REGISTRY/apowerb-chart \
  --namespace apowerb \
  --create-namespace \
  -f values.production.yaml

helm upgrade --install apowerb oci://REGISTRY/apowerb-chart \
  --namespace apowerb \
  --create-namespace \
  -f values.production.yaml

Cette commande est volontairement illustrative. Il faut utiliser le registre, la version du chart et les valeurs actuellement documentés par ApowerB.

Un fichier de production doit expliciter :

• version de l’image ;

• replicas ;

• requests/limits ;

• base externe ou interne ;

• stockage ;

• hostname ingress ;

• TLS ;

• références de secrets ;

• autoscaling ;

• observabilité.

7. Ingress, TLS et DNS sont trois sujets distincts

Créer un objet Ingress n’installe pas un ingress controller. Déclarer TLS n’installe pas cert-manager. Écrire un hostname dans YAML ne crée pas un enregistrement DNS.

DNS → load balancer / ingress controller → règle Ingress → Service → pod runtime

8. Readiness vaut plus que “le pod est Running”

Un service peut être vivant sans être prêt : base indisponible, migrations incomplètes, dépendances non joignables.

• liveness : faut-il redémarrer le processus ?

• readiness : peut-il recevoir du trafic ?

• startup : faut-il lui laisser du temps avant de commencer les probes normales ?

9. Les API modèles et outils restent des dépendances externes

Le cluster peut être sain alors qu’un fournisseur LLM renvoie des 429 ou qu’une API métier time out. Les stratégies de timeout, backoff et retry doivent donc exister au niveau du runtime.

Kubernetes redémarre les processus ; le runtime décide si répéter l’action de l’agent est sûr.

10. L’observabilité doit comprendre la sémantique agentique

• run ID et attribution utilisateur/tenant ;

• latence modèle ;

• appels d’outils et résultats ;

• tokens et coût ;

• transitions d’état ;

• validations humaines ;

• échecs et replay.

Voir aussi l’observabilité IA.

11. Scaler un agent ne signifie pas seulement ajouter des pods

Les goulets d’étranglement peuvent être la concurrence des workers, les quotas fournisseurs, la queue, la latence des outils, le nombre de connexions ou le coût token. Ajouter des replicas ne corrige pas un quota externe.

12. Sauvegardes et upgrades doivent être state-aware

Avant une mise à jour, il faut savoir quelles données doivent survivre, comment passent les migrations, comment restaurer une sauvegarde et si un rollback reste compatible avec le schéma de base.

Déployer le runtime open source sur votre propre infrastructure

ApowerB est conçu pour des workloads d’agents auto-hébergés et fournit les artefacts nécessaires au déploiement du runtime.

La checklist honnête du “one-command”

Séquence de déploiement recommandée

1. choisir cluster et namespace ;

2. vérifier StorageClass ;

3. installer ou vérifier ingress controller ;

4. installer ou vérifier certificat management ;

5. préparer DNS ;

6. provisionner les secrets ;

7. définir base et sauvegardes ;

8. versionner les valeurs Helm ;

9. déployer en staging ;

10. vérifier migrations, readiness et connectivité outils ;

11. activer métriques, traces et logs ;

12. tester restart et disruption ;

13. tester restauration ;

14. promouvoir avec rollout contrôlé.

Contrôles de sécurité spécifiques aux agents

• identité workload et RBAC minimal ;

• NetworkPolicies et contrôle egress ;

• credentials séparés par intégration ;

• autorisation au niveau du runtime ;

• validation humaine des écritures à fort impact ;

• audit des tool calls ;

• sandboxing de l’exécution de code.

Où intervient ApowerB ?

ApowerB apporte la couche runtime/applicative que Kubernetes ne fournit pas : exécution des agents, état applicatif, intégration modèles/outils et logique de plateforme. Kubernetes fournit le control plane infrastructure.

Le guide DEV.to original reste le compagnon pratique du déploiement : lire l’article.

Pour une vue plus large, voir Agents IA prêts pour la production.

À retenir

La commande qui crée les ressources peut tenir sur une ligne. La production, c’est tout ce qui permet à ces ressources de rester utiles après l’installation.

Kubernetes doit récupérer l’infrastructure. Le runtime doit récupérer le travail de l’agent.