Ma 4ème édition, mais toujours la même passion#
La KubeCon 2026 s’est déroulée cette année à Amsterdam pendant trois jours du 24 au 26 mars. Ce type d’événement est clairement à ne pas manquer pour avoir les dernières annonces de l’écosystème de la Cloud Native Computing Foundation (CNCF) !
Au-delà de l’aspect purement marketing, c’est aussi l’occasion d’échanger avec des passionnés et des éditeurs sur différents cas d’utilisation, sans oublier de cultiver sa veille technologique !
Pour cette édition, j’ai eu la chance d’être accompagné par mon collègue Mickaël pour qui c’était sa première KubeCon, une grande découverte donc. Je tiens également à remercier mon entreprise, Piguet Galland, de m’avoir permis d’y retourner une année encore. Eh oui, cela fait maintenant ma 4ème KubeCon, le temps passe si vite…
Cette année, l’Intelligence Artificielle (IA) était omniprésente mais avec des cas plus concrets et aboutis que l’année précédente, cela m’a d’ailleurs donné quelques idées. Sans oublier non plus les questions de souveraineté européenne, la sécurité et bien d’autres thèmes.
Dans cet article, je vous propose de faire un point sur les Keynotes, riches en annonces puis, j’ai sélectionné cinq talks ou outils que j’ai trouvés intéressants et pertinents par rapport à mon quotidien.
Si vous souhaitez vivre ou revivre cet événement avec moi, c’est parti…
Des Keynotes et quelques annonces…#
Le coup d’envoi de cette édition a été donné devant une salle comble, comme à chaque fois d’ailleurs : 13'000 participants venus de plus de 100 pays. Le ton est rapidement donné par la CNCF : l’écosystème ne s’est jamais aussi bien porté avec plus de 230 projets et une communauté de contributeurs qui frôle les 300'000 personnes à travers le monde, vraiment impressionnant !
La maturité des projets au rendez-vous#
Comme à chaque édition, le passage de certains projets à l’étape supérieure est un indicateur fort de la santé de l’écosystème. Cette année, deux projets majeurs ont atteint le stade de Graduated :
Kyverno : Le moteur de politiques de sécurité (Policy Engine) que l’on ne présente plus, confirmant son statut de standard pour la gouvernance et la sécurité ;
Dragonfly : La solution de distribution d’images OCI via P2P, essentielle pour les clusters à grande échelle.
Côté incubation, on notera l’arrivée de Tekton et Fluid, montrant que l’innovation continue d’attirer de nouveaux projets dans le giron de la CNCF.
L’IA : du buzzword à l’infrastructure de production#
Si l’année 2025 était celle de la découverte de l’IA, 2026 marque celle de son industrialisation sur Kubernetes. Nvidia, désormais membre Platinum, a frappé fort en annonçant un investissement de 4 millions de dollars en GPU pour la communauté et l’ouverture de ses drivers, tout en rappelant que Kubernetes est devenu la plateforme par excellence pour l’IA.
L’Inference Gateway devient désormais un standard comme une extension de la Gateway API, nouveau standard pour exposer des applications ou outils à l’extérieur du cluster.
Contrairement à un Load Balancer classique, cette Gateway est conçue pour les charges de travail LLM (Large Language Models) avec une capacité de Body-based routing. Elle permet de distribuer intelligemment les requêtes vers des serveurs de modèles (vLLMs) en fonction du contenu de celle-ci.
llm-d, le petit nouveau#
Autre annonce intéressante, le projet llm-d rejoint officiellement le bac à sable (Sandbox) de la CNCF, illustre parfaitement cette volonté d’industrialiser l’IA sur Kubernetes.
Contrairement aux solutions de répartition de charge classiques, llm-d propose une architecture optimisée pour les spécificités de l’inférence.
Son rôle principal est de maximiser le rendement des GPU en séparant les phases de calcul : le prefill (traitement initial de la requête) et le decode (génération des tokens). Cette approche, appelée “disagrégation”, permet d’éviter que de longues requêtes ne bloquent la génération de réponses courtes, réduisant ainsi drastiquement le temps d’attente pour le premier token (TTFT).
L’un des points forts de llm-d réside dans son scheduler intelligent basé sur Envoy et l’API Gateway de Kubernetes. Il est capable de réaliser du routage conscient du cache (cache-aware routing) : si un nœud possède déjà une partie d’un document ou d’un prompt système dans son cache mémoire (KV cache), llm-d y enverra les requêtes similaires pour éviter de recalculer inutilement les mêmes données.
C’est pourquoi, llm-d transforme l’infrastructure en un système capable de comprendre les besoins réels des modèles de langage, permettant à des acteurs comme Uber de gérer des volumes colossaux de 30 millions de prédictions par seconde avec une efficacité maximale.
L’inférence à l’échelle avec Kueue#
L’inférence à grande échelle nécessite une orchestration fine des ressources, souvent très coûteuses comme les GPU. Wayne a mis en lumière lors de sa présentation le rôle central de Kueue dans cet écosystème qui permet de répondre à cette problématique.
Kueue est un gestionnaire de files d’attente natif pour Kubernetes qui permet d’ordonnancer les charges de travail par job de manière intelligente.
Contrairement à l’ordonnanceur par défaut qui traite les Pods individuellement, Kueue gère les ressources à un niveau plus global et permet de définir des priorités, des quotas et des mécanismes de partage de ressources entre différents utilisateurs ou équipes.
Du diagnostic à l’auto-remédation avec HolmesGPT#
L’IA ne se limite pas aux charges de travail applicatives, elle s’invite aussi dans le quotidien des équipes Ops pour transformer la gestion des incidents. Le projet HolmesGPT, qui peut désormais s’exécuter en mode opérateur, marque une transition qui va en intéresser plus d’un : on passe du simple diagnostic réactif à une remédiation proactive.
Plutôt que d’attendre qu’une alerte se déclenche pour fouiller manuellement dans les logs, HolmesGPT peut surveiller les événements du cluster en temps réel.
Grâce à sa capacité d’analyse en se basant sur des outils d’observabilité, il est capable d’identifier la cause racine d’un problème et de proposer des étapes de remédiation concrètes.
Cette approche permet de réduire drastiquement le bruit généré par les alertes (alert fatigue) tout en accélérant la résolution des incidents les plus courants, ouvrant la voie à une auto-remédiation souvent rêvée.
En route vers l’avenir#
Enfin, la première Keynote s’est conclue sur une vision du futur où l’IA devient “agentique” (capable de prendre des décisions et d’agir via des outils). La démo de Google sur GKE montrant l’utilisation du protocole MCP (Model Context Protocol) pour créer dynamiquement des ressources via Argo CD conforte que l’IA peut être utilisée comme un assistant pour aider les équipes Ops
Autre bonne nouvelle, les futures destinations des prochaines KubeCon ont été dévoilées :
- Barcelone pour 2027 (on avait déjà eu l’information à la KubeCon 2025, c’est donc bel et bien validé) ;
- Berlin pour 2028.
Une chose est sûre : Kubernetes n’est plus seulement un orchestrateur de conteneurs, c’est l’API universelle quel que soit le cas d’utilisation.
La souveraineté au cœur des enjeux#
Un autre thème majeur de cette édition concernait la souveraineté numérique et la place de l’open source dans un monde de plus en plus régulé. Ce thème a longuement été évoqué lors de la deuxième journée.
L’enjeu est de taille : comment maintenir une collaboration technologique globale tout en construisant des déploiements capables de s’adapter aux réglementations locales ?
Le Cyber Resilience Act (CRA) a été au centre des discussions. Ce règlement impose désormais une véritable liste d’ingrédients (le fameux SBOM) pour s’assurer de la sécurité des composants logiciels. Dans ce cadre, les fondations open source (comme la CNCF) jouent un rôle de Steward, garantissant la mise à disposition de logiciels sûrs et servant de point de contact pour les vulnérabilités de sécurité.
Bien que les standards définitifs ne soient attendus que pour décembre 2027, la direction est claire : la transparence devient la norme.
Les retours d’expérience de grandes entreprises européennes ont illustré ce besoin grandissant de souveraineté :
Saxo Bank a présenté son “Service Blueprint”, un système de réconciliation automatique pour tous les services externes (bases de données, files de messages) nécessaires aux charges de travail Cloud Native. L’objectif ? Zéro intervention manuelle après l’approbation initiale et, surtout, une liberté totale de changement de fournisseur ;
La SNCF, de son côté, mise sur des solutions valables, fiables, interchangeables et non-toxiques. Leur vision de la souveraineté passe par des choix d’hébergement réfléchis et une modularité avancée.
Pour répondre aux défis civils et militaires modernes, la souveraineté multi-cloud s’appuie désormais sur trois piliers : la souveraineté des données, la modularité des composants et l’interopérabilité des systèmes.
La souveraineté n’est pas seulement le fait d’utiliser une infrastructure locale, c’est également la capacité à s’équiper de solutions logicielles de manière à ne pas être lié à une infrastructure ou un fournisseur particulier.
Ma sélection côté talks et outils#
Après une belle overdose d’IA lors des Keynotes, il est maintenant temps de mettre en lumière cinq talks ou outils !
Kyverno-authz et Agentgateway : le moindre privilège appliqué à l’IA#
Titre : Least-Privilege for AI: Authorizing Agents and MCP Tools with Agentgateway and Kyverno Speakers : Nina Polshakova et Luc Chmielowski
La sécurisation des agents IA est devenue un sujet central lors de cette KubeCon. Le talk Least privilege for AI a parfaitement illustré ce besoin : comment éviter qu’un agent IA ne réalise des actions destructrices, comme la suppression d’utilisateurs dans une base de données, en utilisant des outils externes ?
La réponse réside dans l’utilisation du Model Context Protocol (MCP) combiné à Kyverno-authz et à Agentgateway.
Autre composant pour exposer tout cela, Agentgateway qui est un data plane performant conçu en Rust, idéal pour gérer les flux de données massifs des charges de travail IA.
Il agit comme un proxy inverse sans état pour MCP et permet un routage fin basé sur le contenu des requêtes (body-based routing) et sur les tokens consommés plutôt que sur le simple nombre de requêtes HTTP. Il peut être déployé n’importe où, même en dehors d’un cluster Kubernetes.
L’apport majeur de Kyverno-authz est d’utiliser le moteur de Kyverno au plus proche de l’appel. Il intercepte les appels MCP et utilise les objets familiers de Kyverno (comme les ValidationPolicy) pour valider les arguments des fonctions appelées par l’IA via des expressions CEL.
Cette approche permet de ne pas réinventer la roue en s’appuyant sur les outils IAM et les politiques de sécurité déjà éprouvés, tout en permettant d’utiliser le principe du moindre privilège pour les agents IA.
C’est donc une première brique pour protéger sa production et gagner en sérénité tout en exploitant le protocole MCP à travers différents outils.
Talos et Zarf : le Kubernetes déclaratif à l’Edge#
Titre : Declarative Edge Kubernetes: Immutable Clusters with Talos + Zarf Speakers : Merijn Keppel et Brandt Keller
Le déploiement de Kubernetes à l’edge, souvent dans des environnements isolés (air-gapped) et sans aucun accès internet, pose des défis importants en termes de gestion des dépendances et d’inventaire.
Le talk Declarative Edge Kubernetes a mis en avant un duo intéressant pour répondre à ces problématiques : Talos Linux et Zarf.
Le premier, Talos Linux se distingue comme le système d’exploitation idéal pour l’edge grâce à sa nature minimaliste, immuable et entièrement déclarative.
Mais comment acheminer les images et les configurations dans un environnement sans accès internet ? C’est là qu’intervient Zarf.
Zarf, quant à lui, peut packager l’intégralité d’un cluster Kubernetes, de ses composants (comme des images OCI) et de ses applications dans un seul bundle auto-suffisant.
Lors des démonstrations, j’ai pu voir la puissance de cette méthode avec le déploiement de Doom (le jeu que l’on ne présente plus) mais aussi, de manière plus impressionnante, une mise à jour complète de Talos réalisée entièrement hors-ligne via Zarf.
Enfin, pour la partie GitOps, Zarf s’intègre parfaitement avec Flux CD en embarquant son propre registre d’images, transformant ainsi la complexité du “airgap” en un processus sans prise de tête mais surtout, reproductible.
Cluster API : les In-place updates et les Chained upgrades#
Titre : In-place Updates with Cluster API: The Sweet Spot Between Immutable and Mutable Infrastructure Speakers : Stefan Büringer et Fabrizio Pandini
L’immuabilité est l’un des piliers de Cluster API (CAPI) : chaque mise à jour de machine entraînait jusqu’ici la création d’une nouvelle et la suppression d’une autre, à l’image d’un Pod.
Cependant, cette façon de faire peut s’avérer lente selon les fournisseurs d’infrastructure ou problématique pour certaines applications sensibles aux redémarrages fréquents.
Le talk In-place updates with Cluster API a présenté deux nouvelles fonctionnalités de la version v1.12.0 de Cluster API : Les mises à jour sans ajout et suppression de nœuds (In-place updates) et les mises à jour en chaîne (Chained upgrades).
Grâce aux nouvelles Update extensions, Cluster API est désormais capable de mettre à jour une machine existante sans la détruire, dès lors que le changement le permet comme une modification de configuration système ne nécessitant pas de redémarrage (exemple: ajout d’une clé SSH).
L’expérience utilisateur reste identique car CAPI arbitre automatiquement entre une mise à jour in-place ou un remplacement complet en fonction de la stratégie définie (maxUnavailable, maxSurge) et de l’état de santé du cluster.
Pour l’autre nouveauté : les Chained upgrades, cette fonctionnalité simplifie considérablement les montées de version importantes (par exemple de la v1.30 à la v1.34).
Auparavant fastidieux, ce processus est désormais automatisé : les controlplanes enchaînent les versions mineures de manière séquentielle pour garantir la stabilité, tandis que les nœuds workers peuvent passer directement à la version finale cible.
Ces deux fonctionnalités permettent de confirmer la maturité de Cluster API, offrant une flexibilité accrue quelles que soient les contraintes côté infrastructure ou système.
La sécurité au service de la vélocité chez Shopify#
Titre : Kubernetes Security at Shopify Scale: Automating Security Across an Infrastructure Monorepo Speakers : Pulkit Garg et Jie Wu
Avec 60'000 déploiements par semaine et plus de 500 clusters à travers le monde, la mise en place d’une sécurité préventive chez Shopify n’est pas un long fleuve tranquille.
Le talk Kubernetes Security at Shopify Scale a mis en lumière un défi de taille : la gestion d’une source unique de vérité à travers un mono repo pour déployer des charts Helm, qui est aussi une source de risque importante.
L’infrastructure est organisée en dossiers d’applications et de services partagés : une seule modification de template peut donc impacter des centaines de services instantanément. Ce qui peut s’avérer extrêmement critique au niveau des répercussions.
Face à un flux constant de 1'000 PR par semaine, Shopify a dû abandonner les revues manuelles, trop inconsistantes, avec pour objectif de mettre en place des garde-fous automatisés.
Pour cela, ils utilisent Semgrep comme inspecteur de code, capable d’appliquer plus de 50 règles pour interdire les privilèges excessifs dans le securityContext ou l’utilisation de namespaces hôtes. Ils utilisent également des expressions régulières pour bannir l’usage du tag latest.
Cette approche de policy-as-code s’étend à Terraform où OPA (Open Policy Agent) analyse les plans en intégration continue (CI) pour détecter toute anomalie avant qu’elle n’atteigne l’environnement de production.
L’idée centrale est de traiter les règles de sécurité avec la même rigueur que le code de production, en commençant par un warm mode pour identifier les faux positifs avant de bloquer réellement les déploiements.
En fournissant des étapes de remédiation en cas de problème et en automatisant les scans, Shopify a réussi à maintenir sa rapidité de déploiement avec zéro incident lié à une mauvaise configuration, sans oublier d’acclimater ses développeurs aux meilleures pratiques de l’industrie (CIS Benchmarks, MITRE, OWASP).
Au-delà de l’utilisation de Semgrep ou OPA, il y a une réelle réflexion sur la mise en place d’une sécurité en amont des déploiements pour limiter les effets de bord.
Kargo, l’épreuve de la production#
Kargo n’est plus un petit nouveau sur ce blog, je vous en ai déjà parlé dans un article dédié (Kargo : Déployez d’un environnement à l’autre en mode GitOps), et, j’ai eu l’occasion de discuter avec quelques personnes du stand d’Akuity sur les nouvelles évolutions de celui-ci.
J’affectionne cet outil et je suis l’évolution de ce projet de près depuis sa version 0.3.0. Aujourd’hui, avec la version 1.9.5, Kargo confirme son statut d’outil de référence pour orchestrer les promotions d’environnements.
Pour rappel, Kargo ne remplace pas vos outils de déploiement en mode GitOps comme Argo CD, mais se place au-dessus de ce dernier pour piloter la transition d’une version d’image ou d’une configuration, d’un environnement à l’autre (par exemple, du staging vers la production) de manière totalement déclarative.
L’une des grandes forces de Kargo réside dans sa richesse en termes de fonctionnalités, notamment à travers ses étapes de promotion (promotion steps). Que ce soit pour mettre à jour un tag d’image, modifier une configuration via Kustomize ou Helm, ou encore déclencher une analyse de santé via un job externe, Kargo propose une multitude d’intégrations prêtes à l’emploi.
Cette flexibilité offre la possibilité de construire des pipelines de promotion adaptées aux contraintes métiers les plus complexes.
Mais ce qui fait réellement passer Kargo dans une autre dimension, c’est son architecture basée sur des agents. Cette approche permet de déployer un controlplane dans un cluster tout en ayant des agents sous forme de Kargo controllers dans chacun de vos clusters Kubernetes.
Cette architecture est le meilleur compromis pour adresser la promotion de vos images et configurations dans l’ensemble de vos clusters Kubernetes sans compromettre la sécurité de ces derniers. En effet, les Kargo controllers utilise la technique du phone home vers le controlplane. Ce qui fait que le controlplane n’a pas accès aux controllers.
Tous ces éléments, de la richesse côté intégrations aux possibilités d’architecture, font de Kargo un outil qui s’impose naturellement pour les organisations cherchant une solution de promotion dans un cadre GitOps.
Quelques mots pour conclure#
La KubeCon 2026 à Amsterdam a marqué un tournant décisif : l’écosystème Kubernetes n’est plus seulement en phase de maturité, il est devenu le socle indispensable pour l’industrialisation de l’IA et un levier stratégique pour la souveraineté numérique !
Que ce soit à travers l’optimisation de l’Inference Gateway avec llm-d, l’ordonnancement intelligent avec Kueue ou encore l’auto-remédiation avec HolmesGPT, Kubernetes prouve qu’il est capable d’absorber les charges de travail les plus complexes et les plus exigeantes.
Mais au-delà de l’IA, cette édition a mis en lumière des avancées majeures sur des sujets de fond : la sécurité préventive à l’échelle de Shopify, la flexibilité des mises à jour avec Cluster API, ou encore la puissance du Kubernetes à l’ère de l’edge avec Talos et Zarf. Des outils comme Kargo confirment également que la promotion d’environnements en mode GitOps est désormais possible.
Une fois de plus, la KubeCon a été un moment d’échange exceptionnel avec une communauté toujours aussi passionnée ! C’est aussi toute cette énergie collective qui continue de faire progresser le futur du Cloud Native et de transformer nos manières de concevoir l’infrastructure.
Hâte de vous retrouver pour la prochaine édition à Barcelone !
