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é
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équentes
Les petites équipes ont-elles vraiment besoin de Kubernetes ?
Pour des charges minuscules, 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 du autoscaling riche, Kubernetes s’amortit vite.
Argo CD ou Flux ?
Les deux sont CNCF-gradués et éprouvés. Argo CD a une UI plus forte ; Flux est plus léger et Git-first. Choisissez-en un et standardisez.
Comment Kubernetes gère-t-il le partage de GPU ?
Via le NVIDIA GPU Operator, MIG, time-slicing ou virtualisation. KServe et vLLM ajoutent le batching pour augmenter l’utilisation.
