OVHcloud monte en puissance au sein de la Cloud Native Computing Foundation (CNCF).
A l’occasion de l’Open Source Summit Europe, qui se tenait à Prague, le groupe de Roubaix a annoncé son changement de statut, passant de « membre » à » membre platnimum ».
« Pour nous, devenir membre Platinum signifie jouer un rôle plus actif dans les technologies et les communautés qui façonnent l’avenir de l’infrastructure cloud.» indique-t-il sur son blog.
Un statut qui crédibilise une stratégie
Le passage au rang Platinum intervient après plus de dix ans d’investissement d’OVHcloud dans les infrastructures ouvertes, l’interopérabilité et la portabilité du cloud.
La CNCF souligne notamment l’usage d’OpenStack depuis 2012, l’adhésion à l’OpenStack Foundation en 2014 et la contribution, en 2020, d’un opérateur Kubernetes développé en interne à Harbor, le registre open source devenu projet gradué de la CNCF.
Ce statut donne à OVHcloud une place plus visible au sein d’un écosystème qui héberge des briques devenues centrales dans les architectures modernes, dont Kubernetes, Prometheus et Envoy. La fondation revendique près de 800 membres et fait partie de la Linux Foundation.
Selon la grille publiée par la CNCF, l’adhésion Platinum coûte 350 000 dollars par an pour une entreprise déjà membre de la Linux Foundation, avec un engagement minimal de trois ans. La cotisation à la Linux Foundation est facturée séparément.
Peser sur les standards de l’IA
La raison la plus stratégique de cette adhésion réside dans la convergence entre cloud natif et IA. La CNCF rappelle que les organisations doivent désormais faire évoluer des applications cloud natives tout en déployant des charges de travail d’IA en production, dans des environnements publics, privés et hybrides.
OVHcloud participe au Certified Kubernetes AI Conformance Program, qui définit une base commune, développée par la communauté, pour exécuter de manière fiable des charges IA et machine learning sur Kubernetes. En mars 2026, ses services AI Deploy et Managed Kubernetes Service ont été approuvés dans ce programme.
Pour Octave Klaba, PDG et fondateur d’OVHcloud, l’indépendance technologique ne signifie pas tout construire seul, mais pouvoir s’appuyer sur des standards ouverts, contribuer aux technologies utilisées et éviter l’enfermement dans un écosystème unique. Le groupe veut ainsi contribuer à façonner les technologies ouvertes, l’IA et leur gouvernance.[cncf]
L’adhésion Platinum s’appuie aussi sur une démonstration opérationnelle. OVHcloud exploite des milliers de clusters Kubernetes en production dans 20 régions de cloud public, avec Cilium pour le réseau multi-tenant, l’observabilité et la sécurité.
La question est désormais de mesurer la capacité du fournisseur à convertir cet engagement en contributions techniques visibles, notamment dans les projets liés à l’IA, à la sécurité et à la portabilité des charges de travail.
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).
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 %).
Connexion
