Inference requests can consume far more resources than “traditional” API calls, making routing decisions critical and dependent on AI-specific strategies such as buffering, streaming and timeouts. On that basis, Istio introduced in summer 2025 a dedicated extension for Kubernetes Gateway API, adding two CRDs: `InferenceModel` and `InferencePool`. `InferenceModel` defines logical endpoints, while `InferencePool` acts as a specialized back-end service that understands AI workload characteristics. Incoming traffic still follows Gateway API `HTTPRoute` rules, but with different load-balancing algorithms that take into account GPU memory usage, queue depth and adapter affinity — for example, directing LoRA requests to servers where the right adapter is already loaded.

That inference extension has now reached beta with Istio 1.29, released in mid-February. At the same time, Istio’s multicluster ambient mode also moved to beta after telemetry work. In a local cluster, or across clusters on the same network, peer-to-peer xDS discovery can enumerate all endpoints. Across multiple networks, however, replication becomes unwieldy and information can be lost. To address this, HBONE was extended with specific headers to exchange peer metadata between endpoints and gateways on different networks. Istio also ties this to the concept of “namespace sameness”: in a multicluster mesh, namespaces with the same name are treated as a single namespace.

Each cluster has its own east-west gateway with an IP address serving as the entry point for ztunnels (“zero trust tunnels”) deployed on every node. To secure traffic, ambient multicluster uses two nested HBONE connections: one encrypts traffic between the ztunnel and the gateway and lets them verify each other’s identities; the other encrypts end-to-end traffic and allows the source and destination ztunnels to authenticate one another as well. Multicluster on the same network remains alpha. More recent — and still experimental — is support for Agent Gateway as a data-plane component. This Solo.io proxy uses A2A and MCP protocols to provide more flexible traffic management for AI workloads.

The inference extension is also becoming relevant to Kubernetes “AI certification.” The CNCF’s AI conformance program, introduced in autumn 2025, defines the capabilities, APIs and configurations a Kubernetes-certified cluster must provide to run AI/ML workloads reliably and efficiently, with the explicit goal of avoiding fragmentation that would hurt portability. For Kubernetes 1.35, the mandatory baseline includes dynamic resource allocation (DRA), Gateway API support with advanced inference-service management such as weighted traffic distribution, header-based routing and service-mesh integration, at least one gang-scheduling solution, correct HorizontalPodAutoscaler behavior for accelerator-backed pods if HPA is present, accelerator and workload metrics exposure, container-level isolation of accelerator access, support for at least one complex AI operator with a CRD such as Ray or KubeFlow, and — when an autoscaler or equivalent exists — the ability to resize accelerator-specific node groups based on pods requesting those accelerators.

With Kubernetes 1.35, the spec also added three recommendations around disaggregated architectures: a verifiable mechanism to ensure the right drivers and configurations are installed on accelerator nodes, support for at least one static resource-sharing strategy on accelerators that can handle it, and the ability to expose virtualized accelerators. Additional recommendations were added a few weeks ago for Kubernetes 1.36, due on April 22, including support for the Gateway API inference extension, DRA for attaching pods to multiple network interfaces, and disaggregated inference architectures such as vLLM with separate prefill and decode instances, llm-d and Dynamo. Today, Kubernetes distro vendors self-certify against these requirements, but an automated test suite is expected to take over this year.

Another CNCF project reaching a milestone is Dapr Agents, a Python framework for building agentic applications on top of the distributed Dapr runtime, which has reached v1. The terminology has shifted from “agent” to “durable agents,” reflecting the runtime’s persistence features: storage in Python lists, vector databases or Dapr stores; automatic retries; and deterministic or event-driven orchestration. Version 1 adds the ability to invoke agents as tools, choose between sequential and parallel tool execution, and use Redis as a vector-store option.

Kyverno is not an AI-centric project, though support for AI/MCP gateways is on its roadmap, but it has now reached CNCF’s highest maturity level. The policy-as-code engine, created by US company Nirmata, underpins infrastructure-governance products built on top of it. Under CNCF stewardship since 2020, Kyverno is used at Adidas, Bloomberg, Coinbase, Deutsche Telekom, LinkedIn, Spotify, Vodafone and Yahoo, among others. It began as a Kubernetes admission controller and is now available as a CLI, SDK and container. Its latest release fully adopts CEL (Common Expression Language) alongside YAML.

The CNCF’s latest quarterly platform-engineering radar shows that maturity does not always translate into adoption. Kyverno appears there, as does another policy-as-code engine, OPA (Open Policy Agent). Despite reaching graduated status in the foundation, OPA is still only at the first adoption stage among developers — based on a survey of about 400 respondents. The survey covered workflow automation, application delivery and security/compliance management, and assessed tools across four dimensions: actual usage, usefulness, maturity and willingness to recommend them. The result is three categories: “adopt” for reliable tools suitable for most use cases, “trial” for tools worth exploring, and “assess” for tools that should be evaluated cautiously.

The radar shows a broad spread of tools across CNCF maturity levels. In workflow automation, the “adopt” group includes Flux, Knative, Argo CD, Jenkins and Helm, while “trial” includes Crossplane, SpinKube, Spinnaker, wasmCloud, Karmada, Tekton, Buildpacks and Jenkins X, and “assess” includes werf and Armada. In application delivery, Dapr, Backstage, Helm and kro are in “adopt,” while Buildpacks, KubeVela, Operator Framework and Score are in “trial,” and Crossplane, kcp, Kusionstack and Microcks are in “assess.” In security/compliance, Sigstore, SPIFFE/SPIRE, cert-manager, Falco, in-toto and OPA are in “adopt”; Cloud Custodian, Kyverno, KubeScape, Notary and OpenCost are in “trial”; and KubeArmor, KubeWarden, Bank-Vaults, Bpfman, Capsule, External-Secrets Operator and Keycloak are in “assess.”

The survey also highlights how organizations approach AI workflows depending on how they build developer platforms. In 41% of cases, multiple teams — DevOps, SRE and infrastructure — contribute capabilities. In 10%, a platform team builds internally; in 18%, it mainly integrates third-party tools; in 6%, it relies primarily on commercial products; and in 16%, each team chooses and manages its own tooling. For AI workflows specifically, 17% extended an existing platform, 19% built a dedicated AI platform, 18% use market platforms, 35% follow a hybrid model with separate experimentation and shared production, and only 5% let AI teams operate directly without platform support.

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).

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…).

À 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.

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 %

The post KubeCon 2026 : d’Istio à Dapr, quand tout un écosystème parle d’IA appeared first on Silicon.fr.