Avant de commencer…#
Après une année d’absence, me voici de retour pour la KubeCon et CloudNativeCon qui se déroulait cette année à Londres ! Comme à chaque fois, cet événement regroupe les passionnés mais aussi les contributeurs des technologies Cloud Native et liées de près ou de loin à Kubernetes.
Du 1er au 4 avril, j’ai eu la chance de participer à cette grande conférence notamment grâce à mon entreprise SoKube que je remercie fortement.
Cette édition 2025 a marqué les esprits avec des thématiques très tendances, notamment l’Intelligence Artificielle qui était omniprésente que ce soit lors des keynotes, des stands ou bien des conférences.
On retrouve aussi l’observabilité accompagnée d’OpenTelemetry, le Platform Engineering et enfin, la sécurité qui garde une place très importante elle aussi.
Pour changer des retours d’expérience de ces dernières années, je vous propose dans la suite de cet article, de donner les grandes annonces de cet événement avec les conférences qui m’ont le plus marqué.
Keynote de démarrage#
La KubeCon a démarré par la traditionnelle Keynote et c’est Chris Aniszczyk (CTO de la Cloud Native Computing Foundation) qui est le premier à entrer sur scène.
Quelques chiffres sont évoqués : cette édition a regroupé au total plus de 12 500 personnes venues du monde entier. Un chiffre impressionnant, reflet d’une communauté open source toujours plus active et diversifiée.
Ce retour à Londres avait également une dimension symbolique, puisque la toute première KubeCon européenne y avait eu lieu en 2016.
Les 10 ans de la CNCF#
La Keynote a démarré par un rappel historique sur la genèse de l’événement : Kubernetes est officiellement devenu le premier projet de la CNCF en mars 2016. Aujourd’hui, près de 9,2 millions de développeurs se revendiquent Cloud Native, montrant à quel point l’adoption de ces technologies s’est accélérée en moins d’une décennie.
À l’occasion du 10ème anniversaire de la CNCF, plusieurs statistiques et visualisations ont été partagées, notamment une carte avec l’activité des projets open source créés et maintenus.
Le message était clair : Maintainers are the key. En effet, les mainteneurs sont le cœur battant de l’écosystème, et leur rôle est plus crucial que jamais dans l’évolution de la CNCF.
Voilà qui donne le ton pour la suite !
Golden Kubestronaut#
Le programme Kubestronaut évolue avec l’arrivée d’un nouveau palier : Golden Kubestronaut.
Pour rappel, ce programme demande d’obtenir les certifications CKAD, CKA, CKS, KCNA et KCSA.
Avec le niveau Golden, il faut obtenir en plus, toutes les autres certifications de la CNCF, par exemple : Prometheus Certified Associate, Certified Argo Project Associate, etc. Sans oublier la LFCS (Linux Foundation Certified System Administrator).
Vous l’aurez compris, cela représente un véritable enjeu pour les mordus de certification !
Souveraineté européenne avec NeoNephos#
NeoNephos, une initiative visant à développer un cloud souverain pour l’Europe avec pour objectif principal de s’appuyer sur les projets CNCF tout en garantissant des standards européens en matière réglementaire.
Il s’agit d’un signal fort sur l’importance croissante de la souveraineté numérique et de l’indépendance technologique dans le cloud distribué.
Prochains événements#
Les lieux des deux prochaines KubeCon Europe ont été dévoilés :
- Pour 2026, ce sera Amsterdam ;
- Et 2027 se déroulera à Barcelone !
Sans oublier que la KubeCon aura lieu en Inde pour la première fois dans les prochains mois.
On passe maintenant aux sujets techniques présents lors de la Keynote !
Scheduling et allocation dynamique de ressources#
Et on peut dire que ça démarre très fort par une présentation de DRA (Dynamic Resource Allocation) avec la possibilité d’allouer des ressources matérielles comme les GPUs par exemple entre un ou plusieurs Pods.
Cette partie se termine par la présentation d’un nouveau projet open source par Google : Orchestrateur multi-clusters dynamique qui permet de gérer différents types de charges de travail entre différents clusters.
Le dépôt de code GitHub accueillera prochainement plus d’informations.
Ce projet a pour but d’optimiser le placement des ressources à travers une flotte de clusters, avec l’envie d’éviter le gaspillage de ressources en fonction de la capacité restante.
Enfin, Argo CD est aussi de la partie à l’aide d’un plugin permettant de tirer parti de cet orchestrateur multi-cluster pour s’occuper du déploiement des applications à travers l’ensemble des clusters.
L’observabilité avec une pointe d’IA chez eBay#
eBay a partagé son retour d’expérience sur la gestion de l’observabilité au sein de son système applicatif composé de 4 600 microservices !
Un volume qui rend le tri manuel des alertes inefficace. C’est pourquoi, ils ont mis en place un système de détection d’anomalie basé sur l’IA qui permet que ce soit pour les traces, métriques et logs d’avoir une analyse, mais aussi un compte rendu des actions à effectuer.
Cela met en avant une véritable démonstration d’un cas d’usage qui utilise l’IA par améliorer la fiabilité d’un système d’information.
Tout cela permet aussi d’introduire OpenTelemetry, une boîte à outils très riche pour améliorer l’observabilité des applications. Peut-être que cette partie viendra s’intégrer à cet outil dans une future version ?
Une UI pour Kubernetes#
Headlamp va devenir l’interface graphique officielle de Kubernetes. Ce dernier permet de connecter et contrôler un ou plusieurs clusters.
Que ce soit via le navigateur ou par le client lourd, il sera possible de gérer l’ensemble des objets Kubernetes mais aussi donner les permissions pour autoriser qui a accès à quoi.
Au-delà des aspects de visualisation, il sera possible d’exécuter des commandes, éditer des ressources voire ajouter des plugins pour contrôler des outils supplémentaires comme Flux.
Rust dans le noyau Linux#
Autre sujet de la keynote : l’introduction progressive de Rust dans le noyau Linux. Après un rappel concis de l’architecture du noyau, certaines limites historiques sont inhérentes au C, notamment en matière de gestion de la mémoire et de concurrence. Ces aspects sont fréquemment à l’origine de bugs critiques.
Avec l’introduction du Rust, la promesse est claire : une sécurité mémoire renforcée sans compromis sur les performances. Grâce à ses mécanismes de vérification au moment de la compilation, son modèle de propriété et ses guards pour gérer les ressources, Rust permet de réduire drastiquement le nombre de verrous et d’allocations explicites, sources classiques d’erreurs.
Rust can fail like C but safer
Actuellement, environ 25 000 lignes de code Rust sont intégrées dans le noyau Linux.
Cependant, l’introduction de Rust ne se fait pas sans friction. Elle oblige à repenser les APIs C existantes pour assurer la compatibilité et les bonnes pratiques, ce qui représente aussi un défi pour changer les habitudes des développeurs historiques.
En résumé, Rust dans le noyau, c’est à la fois une transition culturelle et technique, mais qui semble en bonne voie.
L’Intelligence artificielle au service du langage des signes avec Kubeflow#
La keynote s’est poursuivie avec une démonstration de pipeline IA/ML utilisant Kubeflow, centré sur une application de reconnaissance du langage des signes.
Kubeflow est ici utilisé pour gérer le prétraitement des données issues de caméras placées stratégiquement pour capter les gestes avec la puissance de Kubernetes pour mettre à l’échelle le tout en fonction des besoins et ainsi transcrire ce langage.
Par rapport aux défis techniques, il y en a deux qui ressortent principalement :
- Adapter la transformation des données dans un contexte spécifique, avec des contraintes liées à l’environnement physique ;
- Gérer la localisation et la coordination des caméras pour capturer avec précision les mouvements des mains en fonction de la position du corps.
Kubernetes est donc l’outil qui permet de réaliser cette prouesse technique grâce à ses capacités :
- Optimisation des ressources pour allouer des GPU quand nécessaire ;
- Mise à l’échelle : Ajout de charge de travail au besoin ;
- Orchestration des différentes étapes : de la collecte de la donnée à l’inférence (prédictions ou décisions précises).
OpenTelemetry, le standard de l’observabilité#
La Keynote s’est conclue sur une thématique en pleine émergence : le monitoring as code, au croisement entre observabilité et automatisation.
OpenTelemetry le projet d’observabilité qui a le vent en poupe, en effet, c’est le deuxième projet le plus actif de la CNCF, juste derrière Kubernetes. Il permet de centraliser, structurer et unifier la collecte des métriques, traces et logs à travers différents langages. Une sorte de grosse boîte à outil pour développeur.
L’objectif de cet outil est de rendre ces données accessibles, compréhensibles mais surtout exploitations par toutes les équipes.
OpenTelemetry arrive avec un mécanisme d’auto-instrumentation pour récupérer, par exemple, les traces sans avoir besoin de modifier le code ou le binaire sous-jacent. Une très belle démonstration a été réalisée avec une application en Java et en Go, le résultat est assez magique.
Au final, cela vise à réduire le travail du développeur et augmenter la capacité à rendre visible les applications, une très bonne étape vers plus de visibilité !
Dernier outil présenté : Perses
Un projet sandbox au sein de la CNCF pour réaliser des tableaux de bord totalement configurables via du code embarquant la philosophie GitOps.
Un futur concurrent de Grafana ?
Talks de référence#
Dans la suite, voici quelques talks que j’ai beaucoup apprécié et que je vous encourage à revisionner.
Day-2'000 - Migration From Kubeadm+Ansible To ClusterAPI+Talos: A Swiss Bank’s Journey#
Par Clément Nussbaumer de PostFinance
Une première session avec un retour d’expérience d’une banque suisse pour commencer, avec un sujet important : la modernisation de la création de clusters Kubernetes vers le standard Cluster API.
Le talk a débuté par une présentation de l’infrastructure actuelle :
- 35 clusters Kubernetes en production ;
- 450 nœuds répartis sur deux datacentres on-premise ;
- Des clusters vieillissants avec plus de 2000 jours au compteur (soit plus de 5 ans !).
Tout cela avec le grand combo classique : Terraform pour l’infrastructure, Ansible et Puppet pour la configuration des machines sans oublier Argo CD pour déployer les objets à l’intérieur de Kubernetes.
Mais voilà… l’idée était d’apporter la flexibilité de Cluster API pour gérer les clusters et leur cycle de vie en bénéficiant du côté immuable de Talos Linux pour adhérer aux pratiques du rolling update et éviter des “patcher” l’infrastructure.
Le choix de ce système d’exploitation s’est reposé sur sa grande simplicité :
- OS minimaliste, quelques binaires pour faire fonctionner Kubernetes ;
- Connection sécurisée en mTLS entre l’outil en ligne de commande
talosctlet les nœuds ; - Et comme dit plus haut, système d’exploitation immuable, à vocation à rester éphémère.
Le parcours de migration n’est pas de tout repos et est encore en phase de test aujourd’hui mais Clément en a profité pour donner quelques retours d’expérience de ce changement de technologies :
- Aligner les configurations : les paramètres service-account-issuer et la clé de chiffrement etcd doivent être identiques entre Talos et kubeadm ;
- Importer les certificats existants (PKI), sans oublier la clé spécifique à Talos depuis son endpoint ;
- Créer les Custom Resource Definition (CRD) Cluster API, avec un namespace par cluster ;
- Joindre les anciens nœuds aux nouveaux via Cluster API, pour progressivement remplacer tous les nœuds existants.
Une démonstration haute en couleur est venue clôturer le tout avec un déploiement de nœud via Cluster API. Un talk super intéressant d’une expérience très riche !
More Nodes, More Problems: Solving Multi-Host GPU/TPU Scheduling With Dynamic Resource Allocation#
Par John Belamaric et Morten Torkildsen de Google
Avec l’explosion des workloads IA/ML, les besoins en puissance de calcul ne cessent de croître. Ce talk s’est attaqué à une problématique bien connue des infrastructures Kubernetes : comment scheduler efficacement des jobs lourds en ressources sur des architectures multi-nœuds avec GPU ou TPU, tout en garantissant performance, fiabilité et résilience.
Pour commencer, déployer de l’IA dans Kubernetes met en lumière certaines problématiques :
- Les charges de travail basées sur l’Intelligence Artificielle nécessitent de gros nœuds côté ressources, ce qui augmente fatalement le risque en cas de défaillance ;
- Besoin de placement compact : les Pods doivent être déployés sur des nœuds proches les uns des autres pour tirer parti de la topologie matérielle ;
- Orchestration concurrente de jobs sans race conditions.
C’est pourquoi DRA (Dynamic Resource Allocation), présent depuis peu dans Kubernetes, va pouvoir répondre à ces différents défis avec un cheminement assez nouveau :
- Celui-ci dispose d’une API pour décrire des périphériques (ex : GPU Nvidia) :
- Il propose de nouveaux objets : ResourceClaim, ResourceClaimTemplate, DeviceClass et ResourceSlice dont le premier est abordé dans cette présentation pour exprimer les besoins en matière de ressources ;
- Le Scheduler est capable de prendre une décision suivant les définitions des ResourceClaim liées aux Pods ;
- Le Kubelet applique la décision prise au-dessus.
Aujourd’hui, le scheduler se base sur une logique de type fit first, mais il n’est pas exclu que le système change dans le futur à travers un mécanisme de scoring.
De plus, les speakers mettent en avant ce qui se passe en cas de panne d’un composant au sein d’un nœud : Un taint est appliqué en NoExecute, ce qui aura pour effet d’évincer l’ensemble des Pods pour les replacer ensemble sur un autre appareil TPU ou GPU disponible.
Enfin, la version 1.33 de Kubernetes permettra de partager un GPU en plusieurs petites unités, ce qui est très attendu par la communauté !
J’ai trouvé que c’était très intéressant de comprendre les mécanismes au sein de DRA mais aussi d’avoir un aperçu sur les futures évolutions.
Beyond Security: Leveraging OPA for FinOps in Kubernetes#
Par Sathish Kumar Venkatesan de DevOpsCloudJunction Foundation Inc.
La visibilité et l’optimisation des coûts cloud sont devenues un enjeu central dans les environnements Kubernetes à grande échelle. Dans cette conférence, Sathish a présenté une approche peu commune : détourner l’usage d’OPA (Open Policy Agent), habituellement utilisé pour la sécurité, afin de suivre les coûts.
Quelques chiffres sont rappelés avec en moyenne 32% des ressources cloud qui sont gaspillées !
Plusieurs problèmes peuvent expliquer cela : charges de travail surprovisionnés, nœuds sous-utilisés, quotas absents, ressources inactives. Ce qui donne au final des clusters Kubernetes qui coûtent cher pour une utilisation modérée.
Pour éviter le gaspillage, la solution évoquée est simple : utiliser des contraintes de sécurité au sein d’OPA grâce au langage Rego totalement compatible avec une approche GitOps.
Quelques règles sont évoquées pour mettre cela en place :
- Conformité des tags pour améliorer la visibilité de l’allocation des coûts ;
- Optimisation du compute en fonction du type de charge de travail ;
- Allouer des coûts maximum par namespace ;
- Optimisation du stockage en fonction de la donnée ;
- Obliger l’usage d’instances Spot pour les environnements de développement ;
- Association des dépenses aux budgets fixés.
La démarche se veut itérative avec le besoin de constamment mesurer l’efficacité et les retours des utilisateurs.
Enfin, l’outil OpenCost a été mentionné comme solution de référence pour surveiller l’allocation des coûts.
Cette conférence met en avant que l’approche FinOps peut être embarquée via des outils de Policy as code comme OPA/Gatekeeper ou Kyverno, ce qui permet de définir un cadre standardisé au démarrage d’un cluster.
On termine par un talk sur la sécurité…
Encryption, Identities, and Everything in Between; Building Secure Kubernetes Networks#
Par Lior Lieberman de Google et Igor Velichkovich de Stealth Startup
Dans cette conférence orientée sécurité et réseau, Lior Lieberman et Igor Velichkovich ont dressé un panorama complet des défis liés à la gestion des restrictions côté réseau dans Kubernetes.
Leur message principal est clair : pour aller au-delà des limitations actuelles, l’identité assignée aux Pod doit devenir la clé de voûte des politiques réseau.
Ce sujet commence par un constat lors des phases de troubleshooting : l’utilisation d’un fameux Pod de debug qu’on oublie de supprimer avec des accès réseau étendus: Cette pratique peut engendrer plusieurs failles de sécurité tout en augmentant la surface d’attaque.
Plusieurs incidents dans différents secteurs ont montré que cette pratique peut conduire à des fuites de données ou à des violations de conformité.
C’est donc totalement à proscrire… surtout sans sécurité côté réseau.
En parlant de politiques réseau, un rapide état de l’art est fait sur ce dont Kubernetes dispose aujourd’hui :
La NetworkPolicy en version 1 se présente comme la solution standardisée, compatible avec la majorité des CNI, avec un usage pensé pour les développeurs.
Néanmoins plusieurs limites se font rapidement sentir :
- Le Deny est implicite, ce qui est parfois contraignant ;
- Manque de règles globales au cluster pour les administrateurs ;
- Les règles fonctionnent avec des IP ou labels, mais pas avec des identités.
Une solution permettant de combler quelques limitations se repose sur l’AdminNetworkPolicy ou la BaselineAdminNetworkPolicy.
Ces dernières, disponibles sous forme de CRD permettent la prise en charge des Deny explicites permettant d’isoler les tenants au sein d’un même cluster.
Mais celles-ci ne gèrent toujours pas les identités…
Mais pourquoi vouloir à tout prix mettre des politiques à base d’identités ?
Les deux speakers mettent en avant que les IP sont cruellement éphémères surtout dans un monde où l’on détruit et crée de l’infrastructure sans arrêt ! Quant aux labels, n’importe qui peut venir les modifier sur un Pod au cours de son exécution alors qu’attacher une identité à travers un compte de service rendrait les choses immuables !
Néanmoins, Istio est en avance sur ce terrain avec les AuthorizationPolicy permettant de gérer les comptes de service comme identité mais aussi autoriser ou interdire des actions sur la couche 7 du modèle OSI. C’est aussi le cas de Cilium pour cette dernière partie.
Tout ça pour dire que… cela manque cruellement de standardisation et que la NetworkPolicy comme on la connaît aujourd’hui est sujet à évolution pour compléter sa transition Zero Trust.
Un talk extrêmement intéressant qui permet de se projeter sur les futures aspirations côté sécurité au sein des mécanismes de Kubernetes.
Quelques mots pour conclure ce bel événement#
La KubeCon 2025 à Londres a confirmé ce que beaucoup pressentaient : l’écosystème Kubernetes est entré dans une nouvelle phase de maturité notamment pour accueillir l’Intelligence Artificielle !
Des solutions innovantes à base d’automatisation, de gestion des ressources, d’optimisation des coûts, de sécurité mettent en lumière la volonté de Kubernetes de devenir la plateforme de référence pour tous types de charge de travail !
Mais au-delà de la technique, la KubeCon est un événement passionnant avec une communauté très active et passionnée qui adore échanger et faire avancer le futur du Cloud Native et de Kubernetes.
Hâte d’être à la prochaine édition !