Kubernetes a franchi un seuil que la plupart des technologies d’infrastructure n’atteignent jamais : c’est désormais le substrat par défaut sur lequel tourne l’inférence IA. Les données CNCF placent l’usage de Kubernetes à 82 % chez les adoptants de conteneurs. KubeCon + CloudNativeCon Europe 2026 à Amsterdam a consacré la majeure partie de sa scène principale aux charges IA plutôt qu’aux microservices classiques. Les contrôleurs GitOps Argo CD et Flux sont utilisés par 42 % des utilisateurs K8s pour la livraison en production. La question pour les équipes plateforme en 2026 n’est plus s’il faut utiliser Kubernetes — c’est comment faire évoluer la plateforme pour héberger inférence, model serving et agents autonomes aux côtés des services traditionnels.
Pourquoi Kubernetes a gagné la couche inférence IA
Quatre raisons expliquent ce statut par défaut :
Hétérogénéité des ressources. Les charges IA nécessitent un mix de CPU, GPU, mémoire et parfois d’accélérateurs spécialisés. Les ordonnanceurs Kubernetes gèrent node selectors, taints, tolérations et device plugins (NVIDIA GPU operator, AMD GPU operator) de façons que les frameworks spécialisés ne couvrent pas.
Autoscaling adapté aux formes de trafic. HPA, Cluster Autoscaler, Karpenter et KEDA offrent ensemble aux plateformes d’inférence des façons de passer de zéro à des milliers de répliques selon la profondeur de file d’attente, l’utilisation GPU ou des métriques personnalisées.
Multi-tenancy. Namespaces, quotas de ressources, network policies et gouvernance OPA/Kyverno permettent à un cluster unique d’héberger recherche, staging et production sous des frontières propres — critique quand les GPU sont rares.
Gravité de l’écosystème. KServe, Ray, Kubeflow, vLLM Production Stack, NVIDIA Triton et Hugging Face TGI ciblent tous Kubernetes. Choisir K8s, c’est accéder au catalogue le plus riche de primitives prêtes à l’emploi.
À quoi ressemble « l’inférence à l’échelle du cluster » en 2026
Les plateformes IA modernes sur Kubernetes partagent des patterns récurrents :
- Routage de modèles. Une passerelle centrale (Istio, Envoy Gateway ou couche maison) route les requêtes vers la bonne version, gère les splits A/B et applique les limites par tenant.
- Partage de GPU. MIG sur NVIDIA et time-slicing laissent plusieurs pods d’inférence partager un accélérateur.
- Batching dynamique. vLLM et Triton regroupent les requêtes entrantes pour améliorer le débit.
- Tiering du cache KV. Les caches de génération de tokens sont promus/rétrogradés entre HBM GPU, mémoire hôte et NVMe.
- GitOps partout. Versions de modèles, configs de serving, règles de routage et quotas vivent dans Git. Argo CD ou Flux réconcilient le cluster.
Enseignements de KubeCon EU Amsterdam
La couverture CNCF de KubeCon 2026 a mis en avant trois fils :
- Le platform engineering se consolide. Les organisations adoptent des plateformes réutilisables bâties sur Backstage, Crossplane et l’outillage Kubernetes-natif.
- La dynamique des projets continue. Les données CNCF montrent une croissance soutenue des projets cœur (Kubernetes, Istio, Prometheus) et une adoption forte des projets récemment gradués (Argo, Cilium).
- La sécurité se déplace à gauche. Sécurité runtime eBPF (Cilium Tetragon, Falco), politique à l’admission (Kyverno) et contrôles supply-chain (Sigstore, in-toto) sont désormais des primitives standard.
Ressources à suivre
Le « Top 28 Kubernetes Resources for 2026 » de CNCF met en avant :
- Kubernetes the Hard Way et kind/minikube pour les fondamentaux
- Archives de sessions KubeCon pour les patterns en production
- Argo Rollouts et Flagger pour la progressive delivery
- Kueue pour la mise en file d’attente des jobs batch et IA
- Kyverno et OPA Gatekeeper pour policy-as-code
Publicité
Ce que les responsables platform engineering devraient adopter cette année
Les données CNCF 2026 placent l’usage de Kubernetes à 82 % parmi les adoptants de conteneurs, et KubeCon EU Amsterdam a consacré la majeure partie de sa scène principale aux charges IA. La question n’est plus s’il faut standardiser sur Kubernetes — c’est quels add-ons et pratiques séparent les plateformes prêtes pour l’inférence des clusters qui font juste tourner des pods. Ces trois priorités adressent les lacunes qui ralentissent le plus la livraison IA.
1. Ajouter le scheduling GPU-aware et l’observabilité avant d’embarquer la première équipe ML
L’erreur la plus courante lorsqu’on ajoute des charges IA à un cluster Kubernetes existant est d’embarquer les équipes ML avant que la couche scheduling et observabilité soit prête. Sans l’NVIDIA GPU Operator (ou équivalent AMD) installé et testé, les nœuds GPU ne peuvent pas être ordonnancés de façon prévisible. Sans Prometheus et l’exporteur DCGM, l’utilisation GPU est invisible, et les équipes plateforme ne peuvent pas diagnostiquer si un modèle est limité par la mémoire, le compute, ou simplement en attente dans la file. Installer et valider ces deux couches prend deux à quatre jours et devrait se faire avant que n’importe quelle équipe ML écrive un manifeste de déploiement. Kueue — le contrôleur de file d’attente équitable hébergé par la CNCF — ajoute la capacité de gérer les jobs de training batch concurrents entre équipes partageant une capacité GPU coûteuse, empêchant qu’une équipe consomme l’intégralité du quota du cluster.
2. Standardiser sur GitOps pour les versions de modèles et les configs de serving
L’enquête CNCF montre qu’Argo CD et Flux ensemble sont adoptés par 42 % des utilisateurs Kubernetes pour la livraison en production. Pour les charges d’inférence, GitOps n’est pas une bonne pratique — c’est une exigence de gouvernance. Versions de modèles, configurations de serving, règles de routage et quotas de ressources ont tous besoin d’une source de vérité unique qui produit une piste d’audit de qui a changé quoi et quand. Les sessions platform engineering de KubeCon EU Amsterdam ont confirmé que les organisations se consolidant sur des plateformes développeur internes basées sur Backstage utilisent systématiquement GitOps comme couche de réconciliation en dessous. Une équipe qui livre des mises à jour de modèles en éditant directement des manifestes Kubernetes — sans commit Git dans une branche nommée — ne peut pas reproduire les configurations de serving passées, ne peut pas faire de rollback en sécurité, et ne peut pas satisfaire les exigences d’audit de contrôle d’accès que les clients enterprise demandent de plus en plus dans les questionnaires d’achat IA.
3. Déployer KServe ou vLLM Production Stack comme couche d’inférence, pas un serveur personnalisé
Les deux frameworks de serving d’inférence les plus adoptés en 2026 — KServe et le vLLM Production Stack — couvrent les patterns de serving qui comptent : autoscaling depuis zéro, déploiements canary pour les transitions de version de modèle, serving multi-modèles sur hardware GPU partagé et batching dynamique pour élever le débit. Construire un serveur de modèle personnalisé au-dessus de FastAPI ou Flask brut est le pattern qui cause le plus de travail de ré-ingénierie quand le trafic d’inférence grandit ou quand la cadence de mise à jour des modèles augmente. Les données McKinsey 2026 sur la main-d’œuvre data-center ont noté que la disponibilité d’ingénieurs en infrastructure IA est le deuxième goulot d’étranglement dans les déploiements IA enterprise — ce qui signifie que le coût de ré-ingénierie d’une couche de serving personnalisée est plus élevé que celui d’apprendre la surface de configuration KServe ou vLLM. Standardisez une fois et investissez dans l’écosystème, pas dans une abstraction sur mesure qui doit être maintenue indéfiniment.
Add-ons pour les charges d’inférence
Pour les équipes qui exploitent Kubernetes mais n’hébergent pas encore d’inférence, les add-ons les plus rapides sont :
- Kueue — file d’attente équitable pour training et batch-inference
- KServe ou vLLM Production Stack — model serving avec autoscaling, canary, traffic splitting
- NVIDIA GPU Operator / AMD GPU Operator
- Prometheus + DCGM exporter
- Karpenter ou Cluster Autoscaler
- Collecteurs OpenTelemetry
À surveiller sur 12 mois
- WASM sur Kubernetes pour fonctions d’inférence légères en edge
- Confidential computing (TDX, SEV-SNP) pour charges régulées
- Fédération de clusters pour inférence multi-région sous contrainte de souveraineté
- Primitives orientées agents pour orchestrer les agents IA autonomes
Bilan
Kubernetes est le défaut sûr pour l’inférence IA en 2026. Les équipes plateforme qui investissent dans le scheduling GPU-aware, le GitOps et les add-ons inférence dépenseront moins en cloud et livreront leurs modèles plus vite.
Questions Fréquemment Posées
Les petites équipes ont-elles vraiment besoin de Kubernetes ?
Pour les charges très légères, les services de conteneurs managés (ECS, Cloud Run, Fly.io) peuvent être plus simples. Dès qu’il faut du scheduling GPU, de l’isolation multi-tenant ou un autoscaling plus riche, Kubernetes devient rapidement rentable.
Quelle solution GitOps choisir pour une nouvelle équipe — Argo CD ou Flux ?
Les deux sont diplômés CNCF et éprouvés en production. Argo CD dispose d’une UI plus solide et est souvent choisi par les équipes qui souhaitent un tableau de bord centralisé. Flux est plus léger et davantage axé Git. Choisissez-en un, standardisez-vous dessus.
Comment Kubernetes gère-t-il le partage de GPU ?
Via le NVIDIA GPU Operator et le time-slicing ou le partitionnement MIG (Multi-Instance GPU). Le time-slicing donne à plusieurs pods un accès séquentiel à un GPU ; MIG crée des partitions matérielles isolées. Les deux sont désormais stables en production et essentiels pour exécuter plusieurs petites charges d’inférence sur un seul GPU de manière économique.
