● Silicon.fr Télécom 📅 30/03/2026 à 14:51

Data Science 👤 Clément Bohic

🏷️ Tags : llm cert chatgpt kubernetes python rag réseau rte rust stoc

Les requêtes d’inférence peuvent consommer bien plus de ressources que les requêtes API « traditionnelles ». Leur routage est donc d’autant plus critique et doit reposer sur des stratégies adaptées (buffers, streaming, timeouts…). Partant de ce postulat, le projet Istio avait introduit, à l’été 2025, une extension spécifique pour la Gateway API de Kubernetes. Elle apporte des CRD InferenceModel et InferencePool. La première permet de définir des endpoints logiques. La seconde fonctionne comme un service back-end spécialisé qui comprend les caractéristiques des workloads IA. Quant aux requêtes entrantes, elles suivent les règles HTTPRoute de la Gateway API, mais avec des algorithmes de load balancing distincts. Entrent notamment en compte l’utilisation de la mémoire GPU, l’évolution des files d’attente et l’affinité d’adaptateur (pour les modèles LoRA, on préfère diriger les requêtes vers des serveurs où le bon adaptateur est déjà chargé). Istio s’ouvre à Agent Gateway Cette extension est récemment passée en bêta (mi-février, avec la publication d’Istio 1.29). Lire aussi : { Tribune Expert } – Sécuriser la GenAI commence par un inventaire clair et une visibilité réelle sur ses composants Le mode ambient multicluster a atteint le même stade à la même occasion, après des travaux en matière de télémétrie. Dans un cluster local (ou entre des clusters situés sur un même réseau), la découverte xDS entre pairs permet de connaître tous les endpoints. À l’échelle de plusieurs réseaux, le mécanisme est moins pratique : des informations peuvent se perdre, vu la quantité à répliquer. Pour permettre l’échange de métadonnées de pairs entre endpoints et gateways situés sur des réseaux différents, le protocole HBONE a été enrichi d’en-têtes spécifiques. Istio y associe le concept de namespace sameness : dans un mesh multicluster, toutes les namespaces ayant le même nom sont considérés comme un même namespace. Chaque cluster a sa passerelle est-ouest avec une IP faisant office de point d’entrée pour les ztunnels (« tunnels zero trust ») déployés sur chaque nœud. Pour sécuriser le trafic, le mode ambient multicluster imbrique deux connexions HBONE. L’une chiffre le trafic du ztunnel vers la passerelle et leur permet de vérifier leurs identités respectives. L’autre chiffre le trafic de bout en bout et permet aux ztunnels source et destination de vérifier également leurs identités. Le multicluster sur un même réseau reste en version alpha. Plus récente – et également expérimentale – est la prise en charge d’Agent Gateway comme composant du plan de données. Ce proxy made in Solo.io se nourrit des protocoles A2A et MCP pour apporter une gestion plus flexible du trafic dans le contexte des workloads IA. L'extension inférence, prise en compte pour la « certification IA » des clusters Kubernetes... Gérer une implémentation de l'extension inférence pour la Gateway API devrait bientôt devenir un critère dans le cadre du « programme de conformité IA » de la CNCF. Ce dispositif introduit à l'automne 2025 définit un ensemble de capacités, d'API et de configurations qu'un cluster certifié « conforme Kubernetes » doit proposer pour exécuter de façon fiable et efficace des workloads IA/ML. Principal objectif : éviter une fragmentation qui compromettrait la portabilité. Chaque version de K8s a sa liste d'exigences associée. Pour la dernière en date (1.35), le socle obligatoire est le suivant : Prendre en charge l'allocation dynamique des ressources (DRA) Gérer la Gateway API dans une implémentation permettant une « gestion avancée » pour les services d'inférence (distribution pondérée du trafic, routage sur la base des en-têtes, intégration avec les maillages de services...) Permettre d'installer et d'exploiter au moins une solution de planification des gangs Fonctionnement correct de l'HorizontalPodAutoscaler - si présent - pour les pods qui exploitent des accélérateurs Exposer des métriques sur les accélérateurs et les workloads pris en charge Isoler les accès aux accélérateurs depuis les conteneurs Gérer au moins un opérateur IA complexe disposant d'un CRD (Ray, KubeFlow...) En présence d'un autoscaler ou d'un mécanisme équivalent, permettre de redimensionner les groupes de nœuds contenant des accélérateurs spécifiques en fonction des pods qui sollicitent ces accélérateurs ... comme les architectures désagrégées Seul ce dernier point n'est pas obligatoire avec les versions précédentes de Kubernetes (il est recommandé avec la 1.34). Avec la 1.35, la spec s'est enrichie de trois autres recommandations : Mécanisme vérifiable pour s'assurer de l'installation des pilotes et des configurations adéquats sur les nœuds dotés d'accélérateurs Possibilité de mettre en œuvre au moins une stratégie de partage statique de ressources avec les accélérateurs qui le gèrent Capacité à exposer des accélérateurs virtualisés Il y a quelques semaines, plusieurs recommandations ont été intégrées dans la perspective de K8s 1.36, attendu pour le 22 avril. Gérer une implémentation de l'extension inférence pour la Gateway API en fait donc partie. Il en va de même avec l'utilisation du DRA pour attacher des pods à plusieurs interfaces réseau. Et avec la prise en charge d'architectures d'inférence désagrégées (vLLM avec instances prefill et decode séparées, llm-d, Dynamo...). Lire aussi : Vers une certification IA pour les clusters Kubernetes À l'heure actuelle, les fournisseurs de distros Kubernetes les autocertifient. Une suite de tests automatisés doit prendre le relais cette année. Dapr Agents en GA Autre projet de l'écosystème CNCF qui vient de franchir un cap : Dapr Agents. Ce framework Python, destiné au développement d'applications agentiques sur la base du runtime distribué Dapr, est passé en v1. À cette occasion, le concept d'« agent » devient obsolète, laissant place aux « agents durables ». Une évolution terminologique censée illustrer les bénéfices du runtime en matière de persistance - stockage sur listes Python, bases vectorielles ou magasins Dapr ; retry automatique ; orchestration déterministe ou orientée événements... La v1 apporte la possibilité d'invoquer des agents en tant qu'outils. Elle donne aussi le choix entre exécution séquentielle et parallèle des outils. Et ajoute Redis comme option de base vectorielle. Kyverno n'est pas un projet AI-centric (quoique la gestion des passerelles IA/MCP soit sur sa roadmap), mais il vient de monter en grade à la CNCF, y atteignant le plus haut niveau de maturité. On doit ce moteur de policy-as-code à l'entreprise américaine Nirmata. Laquelle a développé, sur cette base, des solutions de gouvernance d'infrastructure. Lire aussi : ChatGPT peut-il sécuriser Kubernetes ? Sous l'aile de la CNCF depuis 2020, Kyverno est aujourd'hui utilisé chez Adidas, Bloomberg, Coinbase, Deutsche Telekom, LinkedIn, Spotify, Vodafone et Yahoo, entre autres. Il s'agissait à l'origine d'un contrôleur d'admission Kubernetes. Il est désormais disponible en CLI, SDK et conteneur. La dernière release marque l'adoption complète du CEL (Common Expression Language) en plus du YAML. Platform engineering : maturité CNCF ne rime pas toujours avec adoption Kyverno figure dans le dernier radar trimestriel de la CNCF relatif aux outils de platform engineering. Un autre moteur PaC s'y trouve : OPA (Open Policy Agent). Bien qu'arrivé au plus haut niveau de maturité au sein de la fondation, il n'apparaît encore qu'au premier stade d'adoption chez les développeurs. En tout cas les quelque 400 qui ont participé à l'enquête. Cette dernière a couvert trois domaines : automatisation de workflows, livraison d'applications et gestion de la sécurité/conformité. Elle a pris en compte quatre dimensions : L'usage des outils (quels devs s'en servent ou s'en sont servis) Leur utilité (jugement de l'adéquation aux besoins des projets) Leur maturité (évaluation de stabilité et de fiabilité) La propension à les recommander Il en résulte trois catégories : « adopt » (outils fiables et applicables à la plupart des cas d'usage), « trial » (qui valent le coup d'être explorés) et « assess » (à évaluer avec précaution). Le tableau suivant synthétise la situation. « S » signifie qu'un outil est en sandbox à la CNCF (premier niveau de maturité). « I », qu'il en est au deuxième (incubation). « G », qu'il a atteint le dernier (graduated). Assess Trial Adopt Automatisation de workflows Crossplane (I) Flux (G) Knative (G) SpinKube (I) Spinnaker (I) wasmCloud (I) Jenkins X (I) Karmada (I) Tekton (I) werf (S) Argo CD (G) Armada (S) Buildpacks (I) Jenkins (G) Livraison d'applications Crossplane (I) kcp (S) Kusionstack (S) Microcks (S) Buildpacks (I) Dapr (G) KubeVela (I) Operator Framework (I) Score (S) Backstage (I) Helm (G) kro (G) Gestion sécurité/conformité Falco (G) in-toto (G) KubeArmor (S) KubeWarden (S) Kyverno (I) Sigstore (G) Bank-Vaults (S) Bpfman (S) Capsule (S) Cloud Custodian (I) External-Secrets Operator (S) KubeScape (I) Notary (I) OpenCost (I) SPIFFE/SPIRE (G) cert-manager (G) Keycloak (I) OPA (G) Quatre approches plate-forme, quatre approches IA L'enquête donne aussi un aperçu de l'approche que les organisations ont des workflows IA en fonction de la façon dont elles constituent leurs plates-formes développeurs. Le plus souvent (41 % de l'échantillon), plusieurs équipes - DevOps, SRE, infra - contribuent à fournir des capacités. Dans 10 % des cas, une équipe plate-forme développe en interne ; dans 18 % des cas, elle intègre principalement des outils tiers. Il arrive aussi qu'elle s'appuie essentiellement sur des solutions du marché (6 %) ou que chaque équipe choisisse et gère son outillage (16 %). Pour traiter les workflows IA, certains ont étendu leur plate-forme existante (17 %). D'autres en ont construit une spécifique (19 %), utilisent des plates-formes du marché (18 %) ou ont une approche hybride (expérimentation séparée, prod partagée ; 35 %). La gestion directe par les équipes IA sans support au niveau plate-forme est plus rare (5 %). Approche plate-forme ↓ Approche IA → Extension Plate-forme IA dédiée Hybride Solution du marché Développement interne 28 % 11 % 25 % 17 % Intégration d'outils tiers 18 % 26 % 26 % 26 % Fonctionnement collaboratif 19 % 16 % 48 % 10 % Choix par équipe 8 % 25 % 26 % 25 %

🔗 Lire l'article original 👁️ 1 lecture