Kubecon London 2025: IA, Observabilité et Platform Engineering

By Maxime Ancellin, Romain Boulanger & Yann Albou

Une édition enrichissante, la KubeCon + CloudNativeCon Europe 2025 à Londres a montré un cloud‑native arrivé à maturité : Kubernetes gère encore mieux les GPU, tandis qu’OpenTelemetry, GitOps et le platform engineering s’imposent comme standards de facto.
Ce blog propose de revenir sur ces tendances majeures, décrypter les chiffres clés et tirer les leçons d’une conférence qui montre un écosystème à la fois mature, innovant et résolument tourné vers un futur

Les sujets abordés sont les suivants:

• Introduction
• Chiffres clés de l’édition 2025
• Standards CNCF : où en est‑on ?
• Annonces importantes
  • KubeCon Europe 2026 et 2027
  • Kubestronaut : la certification CNCF évolue
  • OpenInfra s’associe à la Fondation Linux
  • NeoNephos : l’initiative européenne pour la souveraineté numérique
  • Headlamp : l’interface graphique officielle de Kubernetes
  • Du Rust dans le noyau Linux
  • OpenTelemetry, le standard de l’observabilité
  • Perses, un tableau de bord as code
• DRA : Dynamic Ressource Allocator – l’essentiel
• CAPI : Cluster API
• Multi-cluster: quand plusieurs clusters doivent travailler ensemble
• L’avenir de la NetworkPolicy : plus riche, plus fine, plus sûre
• Observabilité : Vers une Surveillance Intelligente et Automatisée
  • L’observabilité avec OpenTelemetry : simple, automatique, multi-langage
  • L’observabilité et l’IA : vers une analyse assistée des incidents
• IA & LLM : « K8s is the new web app »
  • Observability in the Age of LLMs : remettre de la rigueur dans la magie
  • LLM & Kubernetes : faire tourner l’intelligence artificielle en local
  • Pourquoi Kubernetes deviendra la plateforme de choix pour les architectures agentiques ?
• Platform Engineering : vers une adoption de masse
  • LEGO – “Kubernetes as a Platform”
  • Sécurité & Platform Engineering – “Shift Down, Not Left”
• FinOps : le FinOps dans Kubernetes
• Conclusion

Introduction

La KubeCon + CloudNativeCon Europe 2025 s’est tenue à Londres du 17 au 19 avril, rassemblant plus de 12 500 participants passionnés par l’écosystème cloud natif. Cette édition a mis en lumière plusieurs thématiques majeures qui façonnent l’avenir du cloud computing :

• L’Intelligence Artificielle et son intégration croissante dans les infrastructures cloud natives
• L’Observabilité, devenue incontournable pour piloter des systèmes toujours plus complexes
• Le Platform Engineering, qui s’impose comme une approche structurante pour industrialiser les pratiques DevOps
• La maturité de l’écosystème cloud natif, avec des projets qui atteignent leur pleine maturité
• Le passage à l’échelle des architectures cloud natives dans les grandes organisations

Fait notable, bien que Kubernetes reste le socle technologique de référence, les discussions ont largement dépassé les aspects purement techniques pour aborder des problématiques plus larges d’architecture, de gouvernance et d’adoption.

Les replays de la conférence sont disponibles sur la chaîne YouTube officielle de la CNCF

Chiffres clés de l’édition 2025

Des chiffres toujours plus élevés, avec plus de 12 500 participants, 459 session et des centaines d’heures de conférences.

Les maintainers track sur les produits de la CNCF remportent le plus de succès avec 84 Sessions soit 18.3% du total.

Il est toujours intéressant de voir aussi les statistiques des mots clés du programme de cette édition ainsi que les sociétés les plus citées:

Le Programme est bien étudié et représente un clairement les tendances et les acteurs principaux.

Standards CNCF : où en est‑on ?

Nous avons pu constater que certains standards de la Cloud Native Computing Foundation (CNCF) sont devenus incontournables dans le monde du cloud native:

• OpenTelemetry (OTEL) poursuit son adoption massive et s’impose comme le standard unifié pour l’observabilité dans l’écosystème cloud native.
• Le GitOps est maintenant omniprésent dans les organisations :
  • ArgoCD s’est établi comme l’implémentation de référence dans l’industrie
  • Cette approche couvre désormais autant le déploiement applicatif que la gestion de l’infrastructure (voir plus bas l’approche CAPI)
• L’automatisation est devenue systématique et un pilier fondamental :
  • Elle englobe tous les aspects, de l’applicatif jusqu’à l’infrastructure
  • Elle repose principalement sur l’Infrastructure as Code (IaC) et les pratiques GitOps
• La mise à l’échelle montre des résultats impressionnants :
  • Les projets hébergés par la CNCF connaissent une accélération significative

• Des nouveaux cas d’utilisation comme le « Edges computing »

• Les retours d’expérience présentés démontrent des volumétries toujours plus importantes: l’exemple du CERN est très impréssionnant:

Avec ce genre de volumétrie (prêt de 600 Clusters Kubernetes, 60 000 pods, 2 500 persistent volumes, …) on ne peu plus douter que Kubernetes est capable de gérer des charges de travail à l’échelle !!!

Annonces importantes

KubeCon Europe 2026 et 2027

La CNCF a annoncé les prochaines éditions de la KubeCon, avec notamment la confirmation des événements européens pour 2026 et 2027.
Un moment historique approche également avec la toute première KubeCon India qui se tiendra en août, marquant ainsi l’expansion continue et l’internationalisation croissante de la CNCF qui ne cesse de renforcer sa présence mondiale.

Même si cela n’a pas été mentionné par la CNCF, il faut espérer que la KubeCon LATAM (une communauté très active dans le monde Cloud Native) pourra compléter la liste (NA, EMEA, India, China). Merci au Corsair d’avoir porté cette information à notre attention.

Kubestronaut : la certification CNCF évolue

La CNCF a annoncé l’évolution de son programme de certification Kubestronaut, qui récompense les professionnels ayant obtenu les principales certifications Kubernetes. Le titre de Kubestronaut est décerné aux personnes détenant les certifications CKA (Certified Kubernetes Administrator), CKAD (Certified Kubernetes Application Developer), CKS (Certified Kubernetes Security Specialist), KCNA (Kubernetes and Cloud Native Associate) et KCSA (Kubernetes and Cloud Native Security Associate).

Un nouveau niveau, le Golden Kubestronaut, a également été introduit pour reconnaître les experts qui possèdent non seulement toutes les certifications Kubestronaut, mais aussi l’ensemble des autres certifications CNCF ainsi que la certification LFCS (Linux Foundation Certified System Administrator). Ce programme vise à valoriser l’expertise approfondie dans l’écosystème cloud native et à encourager le développement professionnel continu dans ce domaine.
Plus d’informations sur le site de la CNCF : https://www.cncf.io/training/kubestronaut/

OpenInfra s’associe à la Fondation Linux

La Fondation Open Infrastructure (OpenInfra) a annoncé son rapprochement avec la Linux Foundation (LF), l’organisation mère de la CNCF. Cette fusion stratégique va permettre d’enrichir l’écosystème LF et CNCF avec de nouveaux projets majeurs. Parmi les projets notables qui rejoindront cet écosystème, on peut notamment citer OpenStack, la plateforme de cloud computing open source, ainsi que Kata Containers, le projet de conteneurs sécurisés. Cette consolidation renforce la position de la Linux Foundation comme acteur central de l’open source dans le domaine du cloud et des infrastructures.

NeoNephos : l’initiative européenne pour la souveraineté numérique

L’initiative NeoNephos, soutenue par l’Union Européenne, représente une avancée majeure dans la quête de souveraineté numérique européenne. Ce projet ambitieux vise à créer une infrastructure cloud européenne basée sur les technologies open source, en particulier celles issues de la CNCF. L’objectif est de réduire la dépendance aux fournisseurs non-européens tout en garantissant un haut niveau de sécurité et de confidentialité des données. L’Union Européenne a démontré son engagement en investissant massivement dans ce projet stratégique, qui s’inscrit dans le cadre plus large de sa stratégie numérique. Cette initiative illustre parfaitement la volonté européenne de développer ses propres solutions cloud tout en restant alignée avec les standards internationaux de l’industrie.

Headlamp : l’interface graphique officielle de Kubernetes

La CNCF a annoncé que Headlamp deviendra l’interface graphique officielle de Kubernetes. Ce projet, toujours en développement actif au sein de la communauté, offre une interface web moderne et intuitive pour la gestion des clusters Kubernetes. Sa conception modulaire permet l’ajout d’extensions et de plugins pour étendre ses fonctionnalités selon les besoins spécifiques des utilisateurs.
Cette décision marque une étape importante dans la standardisation des outils de gestion visuelle pour Kubernetes.

Une démo est disponible dans ce repo Github : Headlamp Demo

Du Rust dans le noyau Linux

Lors de sa keynote « Rust in the Linux Kernel: A New Era for Cloud-Native Performance and Security », Greg Kroah-Hartman a souligné que le noyau Linux comporte désormais environ 25 000 lignes de Rust — une goutte d’eau face aux 34 millions de lignes C, mais déjà suffisante pour prouver que la mémoire sûre de Rust élimine toute une classe de bogues et permet au noyau de tomber de façon contrôlée plutôt que de corrompre la RAM.
Au-delà du gain technique, l’enjeu majeur est culturel : après trente ans de monoculture C, accepter un second langage bouscule les méthodes de revue, les chaînes d’outillage et même les valeurs des mainteneurs, certains voyant dans Rust une opportunité de moderniser le projet, d’autres redoutant un éclatement des efforts.
Autrement dit, introduire Rust dans le kernel, c’est moins remplacer du code que faire évoluer les mentalités et la gouvernance vers un modèle où sécurité par conception et collaboration multi-langages deviennent la norme.

OpenTelemetry, le standard de l’observabilité

Désormais deuxième projet le plus actif de la CNCF derrière Kubernetes, OpenTelemetry est né de la fusion stratégique d’OpenTracing et OpenCensus, d’abord incubée en Sandbox avant de gravir les échelons de la fondation. Véritable boîte à outils unifiée, il fournit des API et SDK cohérents pour générer métriques, logs et traces au sein d’une même sémantique, puis les exporter vers n’importe quel back-end (Prometheus, Grafana, Jaeger, Tempo, etc.).
Une nouveauté importante est l’auto-instrumentation : quelques bibliothèques suffisent pour que vos applications Java, .NET, Go, Python ou Node capturent automatiquement latence, erreurs et contextes distribués, réduisant à la fois le temps d’intégration et la dette d’observabilité.

En normalisant la collecte et le transport des signaux, OpenTelemetry s’impose comme le standard de facto de l’observabilité cloud-native, catalysant une approche “mesurer d’abord, optimiser ensuite” indispensable aux architectures Kubernetes modernes.

Perses, un tableau de bord as code

Nouveau projet accepté en Sandbox par la CNCF, Perses se présente comme un “dashboard-as-code” natif Kubernetes :

• Ses définitions de tableaux de bord sont stockées dans des CRDs, ce qui permet de versionner et de valider automatiquement les configurations dans un pipeline GitOps.
• Conçu pour agréger métriques, traces et bientôt logs, le projet fournit une API et un CLI (percli) afin de générer ou de mettre à jour les dashboards depuis le code plutôt qu’à la souris, tout en exposant des composants réutilisables via des packages NPM.

Cette approche “as-code” réduit la dérive entre environnements, facilite les revues et fait de Perses un complément GitOps-friendly à l’écosystème observabilité, un concurrent standard et sérieux face à Grafana.

Voici maintenant les thématiques principales de la kubecon 2025:

DRA : Dynamic Ressource Allocator – l’essentiel :

Objectif : permettre à un Pod de réclamer dynamiquement une ressource rare ou critique (GPU, FPGA, licence logicielle, clef USB-HSM, etc.) et de ne démarrer que lorsqu’elle est réellement disponible, en ré-utilisant les mêmes schémas déclaratifs que les Volumes Persistants.

• Exemple 1 : réclamer un GPU pour l’inférence

apiVersion: v1
kind: Pod
metadata:
  name: gpu-inference
spec:
  resourceClaims:
    - name: gpu-needed
  containers:
    - name: infer
      image: nvcr.io/myorg/llm:latest
      resources:
        limits:
          nvidia.com/gpu: 1

---

apiVersion: resource.k8s.io/v1alpha2
kind: ResourceClaimTemplate
metadata:
  name: gpu-needed
spec:
  deviceClass: nvidia-a100  # défini côté cluster

• Exemple 2: verrouiller une licence MATLAB® on-prem

apiVersion: apps/v1
kind: Deployment
metadata:
  name: matlab-workers
spec:
  replicas: 5
  template:
    spec:
      resourceClaims:
        - name: matlab-license
      containers:
        - name: worker
          image: registry.company.com/matlab-job:2025

---

apiVersion: resource.k8s.io/v1alpha2
kind: ResourceClaim
metadata:
  name: matlab-license
spec:
  deviceClass: ml-license
  parameters:
    seats: "1" # seat-based licensing

Le driver met à jour dynamiquement les ResourceSlice pour refléter le nombre de licences encore libres ; le scheduler n’alloue celles-ci qu’aux Pods pouvant vraiment l’utiliser, évitant les échecs « licence unavailable ».

Pourquoi Dynamic Resource Allocation (DRA) quand le scheduler gère déjà CPU/Mémoire ?
Le scheduler natif prend ses décisions en fonction de deux ressources “intégrées” : le CPU (millicores) et la mémoire (MiB/GiB), qu’il voit comme de simples compteurs sur chaque nœud. Cela suffit pour des ressources uniformes, toujours présentes et dont la disponibilité se résume à un nombre libre ou occupé. Mais dès qu’on parle de GPU, FPGA, licences logicielles, HSM USB, ports série, etc., on sort de ce modèle.
En pratique, le scheduler classique ne fait que “compter” des CPU et de la RAM toujours attachés au nœud, alors que DRA ajoute un véritable plan de contrôle pour les ressources rares, hétérogènes ou mutualisées : un Pod déclare un ResourceClaim fondé sur une DeviceClass (GPU A100, licence MATLAB, FPGA…), le pilote publie en temps réel son inventaire via des ResourceSlices, et le Pod ne démarre que lorsque la ressource exacte est confirmée. Ce mécanisme apporte ce qui manque au modèle CPU/Mémoire : des paramètres riches (vendor, seats, modèle), des règles de taint/toleration au niveau du périphérique, une mise à jour dynamique de la disponibilité et surtout la garantie qu’un démarrage n’échouera plus faute de matériel ou de licence à l’exécution. Autrement dit, DRA complète le scheduler en lui offrant la granularité, la validation et la gouvernance nécessaires aux “ressources spéciales” que le simple comptage de millicores et de méga-octets ne pourra jamais représenter de manière fiable.

Du coup on peut se poser la question de l’utilisation de DRA vs Affinity/Anti-Affinity

• Affinity/Anti-Affinity décide où placer un Pod (collocation / séparation sur les nœuds) en se basant sur des labels.
• DRA gère quoi allouer : la ressource elle-même (GPU, licence, carte FPGA) et sa disponibilité temps réel — un complément, pas un substitut

En résumé, DRA étend l’ADN déclaratif de Kubernetes à tout ce qui dépasse le simple CPU-RAM : vous décrivez le besoin, le cluster orchestre l’allocation, retardant le démarrage si nécessaire plutôt que d’échouer à mi-parcours – un pas de plus vers un scheduler réellement « resource-aware ».

Ce repository Github de Kubernetes contient des exemples de configuration DRA et montre via un projet de test le fonctionnement de DRA:

CAPI : Cluster API

Cluster API (CAPI) n’est plus un projet de niche : sous l’égide du SIG cluster-api, il vient de sortir en version v 1.9.6 et s’impose comme la façon la plus propre de déclarer, créer, mettre à jour et démanteler des clusters Kubernetes à l’aide des mêmes manifestes YAML que pour vos déploiements applicatifs

Concrètement, on décrit un cluster cible (control-plane, workers, réseau) puis on laisse une armée de contrôleurs piloter la création sur n’importe quelle infrastructure et typèe de Control Plane — AWS, Azure, vSphere, Proxmox, Talos, RKE2, etc.
Cette approche « cluster-as-code » s’accorde naturellement avec GitOps : Une PR suivi d’un merge dans le repo et votre nouveau cluster apparaît (ou disparaît) sans scripts Ansible.

Un projet vivant et extrêmement actif dans lequel on compte désormais des dizaines de providers officiels et un rythme de publication soutenu, gage de pérennité et de réactivité face aux CVE ou aux différentes évolutions.

Témoignages concrets : Michelin et PostFinance

• Michelin a migré de Kubespray puis VMware Tanzu vers une stack 100 % open source – Cluster API + Crossplane + ArgoCD sur Talos Linux. Résultat : 441 applications métier exploitées sur 62 clusters, soit ≈ 8 000 vCPU sur 850 Workers gérés de façon déclarative:
  Voir la keynote Michelin

• Du côté bancaire Suisse, PostFinance raconte son projet “Day-2’000 – Migration From Kubeadm+Ansible To ClusterAPI+Talos” : abandon de kubeadm + Ansible au profit de la Cluster API + Talos (un OS immutable fait pour kubernetes avec une API) afin d’industrialiser le cycle de vie de clusters.
  Ce parcours de migration est très intéressant avec en particulier des feedbacks sur la gestion des clés et certificats.
  Ces retours prouvent, encore une fois, que CAPI n’est plus réservé aux POC : il tient la charge dans l’industrie et la finance.

Exemple partiel de la description d’un cluster CAPI:

# L’objet Cluster (CAPI) référence l’infrastructure (ProxmoxCluster) et le control plane (RKE2ControlPlane).
apiVersion: cluster.x-k8s.io/v1beta1
kind: Cluster
metadata:
  name: dev-rke2-cluster
  namespace: default
spec:
  clusterNetwork:
    pods:
      cidrBlocks:
        - 172.18.0.0/16
    services:
      cidrBlocks:
        - 172.19.0.0/16
  infrastructureRef:
    apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
    kind: ProxmoxCluster
    name: dev-rke2-cluster
  controlPlaneRef:
    apiVersion: controlplane.cluster.x-k8s.io/v1beta1
    kind: RKE2ControlPlane
    name: dev-master

---

# Le RKE2ControlPlane décrit la configuration RKE2 (version, paramètres, etc.) et référence la ProxmoxMachineTemplate pour les nœuds control-plane.
apiVersion: controlplane.cluster.x-k8s.io/v1beta1
kind: RKE2ControlPlane
metadata:
  name: dev-master
  namespace: default
spec:
  clusterName: dev-rke2-cluster
  replicas: 1
  rolloutStrategy:
    default:
      rollingUpdate:
        maxSurge: 1
      type: RollingUpdate
  version: v1.31.5+rke2r1
  # enableContainerdSelinux: true  # Active le support SELinux pour containerd
  serverConfig:
    # On veut cilium (=> on désactive canal). 
    # keepalived est également désactivé
    disableComponents:
      kubernetesComponents:
        - cloudController
      # - rke2-canal
      # - rke2-keepalived
      # - rke2-kube-proxy
    cni:
      # ou calico, canal, etc. si vous voulez un autre plugin
      - cilium
# ....
machineTemplate:
    infrastructureRef:
      apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
      kind: ProxmoxMachineTemplate
      name: rke2-master-template
    nodeDrainTimeout: 2m

Cet exemple partiel qui décrit comment déployer un cluster kubernetes, combiné avec l’approche GitOps, permet de gérer un cluster en devenant indépendant de l’outil de provisionning et en bénéficiant d’un cycle de vie automatisé avec un workflow de type PR/merge identique à celui utilisé pour les applications.

En conclusion, bien que la Cluster API ne soit pas nouvelle, elle atteint aujourd’hui une réelle maturité avec des retours d’expérience concrets comme celui de Michelin qui gère 62 clusters en production. CAPI apporte enfin la couche « cycle de vie » qui manquait : une API Kubernetes pour gérer… des Kubernetes. Que vous exploitiez 3 clusters de test ou des dizaines en production, CAPI transforme la création et la maintenance de clusters en simples opérations Git, réduisant drastiquement la dette d’automatisation et la dépendance aux outils propriétaires. Cependant, il est important de noter que l’adoption de CAPI nécessite un temps d’apprentissage et une bonne compréhension de son fonctionnement pour en tirer pleinement parti.

Multi-cluster: quand plusieurs clusters doivent travailler ensemble

Dans un monde multi-cluster, il ne s’agit plus seulement d’exploiter plusieurs instances Kubernetes : il faut qu’elles coopèrent pour offrir la fault-tolerance, rapprocher les données des utilisateurs, appliquer des politiques globales, équilibrer la capacité et, parfois, chasser les meilleures performances.

Le SIG Multicluster définit déjà une grammaire commune :

• un ClusterSet regroupe des clusters « de confiance »
• chaque membre porte des ClusterProperty (métadonnées comme la région ou le niveau de conformité)
• via la Work API, on déclare quelles charges de travail doivent être propagées sur l’ensemble ou une partie du ClusterSet.
• À terme, un Cluster Profile permettra même de cibler tel type de cluster (edge, GPU, réglementé) sans lister les noms un par un.

L’objectif rejoint celui d’un cluster mesh : exposer un service unique derrière plusieurs clusters et router les requêtes au plus proche ou au plus disponible, tout en maintenant des contrôles réseau/sécurité cohérents.
Cluster API (CAPI) reste complémentaire : il gère le cycle de vie (création, mise à jour, suppression) des clusters eux-mêmes, alors que SIG Multicluster orchestre leur interconnexion et la distribution du trafic ou des workloads.

En clair, CAPI construit la flotte, le SIG Multicluster lui donne un cerveau collectif — un vaste chantier en cours, mais déjà indispensable pour les organisations qui visent la haute disponibilité planétaire ou la résidence des données par juridiction.

La question qu’on se pose alors est : faut-il bâtir un gigantesque cluster Kubernetes, ou bien diviser la charge entre plusieurs clusters plus petits ?
c’est ce que la conférence A Huge Cluster or Multi-Clusters? Identifying the Bottleneck essaie de répondre.
Il existe dans kubernetes des limites pratiques connues du projet (ex. 110 pods par nœud, 5 000 nœuds max) et les goulots d’étranglement classiques : API server, ETCD, DNS, stockage, ou encore la gestion fine des nœuds…
Mais quelles sont les bonnes pratiques pour choisir entre un gros cluster ou plusieurs petits ?

• Avantages d’un gros cluster kubernetes
  • Moins de coûts d’infrastructure et de maintenance.
  • Politique et gestion centralisées.
  • Meilleure utilisation des ressources (surtout avec VPA).
  • Multi-zones possibles pour éviter les pannes isolées.
• Inconvénients d’un gros cluster kubernetes
  • Mauvaise isolation entre locataires (namespaces seulement).
  • Blast radius important : une panne affecte tout le monde.
  • Moins de flexibilité pour les utilisateurs finaux :
  • Versions Kubernetes figées (ex. n à n–3).
  • Config nœuds moins personnalisable.
  • Difficile à faire cohabiter des CRDs et Operators variés.
• Avantages de plusieurs petits clusters
  • Isolation forte entre équipes ou workloads.
  • Liberté totale dans chaque cluster (versions, CRDs, config).
  • Moindre impact en cas de panne (blast radius réduit).
  • Plus simple d’expérimenter ou d’évoluer indépendamment.
• Inconvénients de plusieurs petits clusters
  • Coût opérationnel plus élevé (outillage, observabilité, upgrades).
  • Nécessite des opérateurs ou des plateformes pour orchestrer les clusters.
  • Charge de supervision fragmentée (schedulers multiples, fragmentation des ressources).
  • Moins de contrôle global sans plateforme dédiée.

Il n’y a pas de solution unique — tout dépend des priorités.
Si la priorité est l’efficacité à grande échelle et la gouvernance centrale, un gros cluster peut suffire (tant que vous maîtrisez les limites techniques).
Mais si vous visez l’autonomie des équipes, la sécurité renforcée ou l’hétérogénéité des usages, la stratégie multi-clusters est plus adaptée… à condition de disposer des bons outils pour l’orchestrer (CAPI, IDP, observabilité distribuée, etc.).

Mais pourquoi pas aller vers des solutions intermédiaire en faisant du Multi-tenancy via du « Kubernetes-in-Kubernetes » ?

L’approche multi-tenancy dans Kubernetes ne se limite pas à créer des namespaces. L’écosystème propose aujourd’hui un éventail d’outils pour virtualiser ou partitionner des environnements Kubernetes — allant du plus léger (shared-namespaces) au plus isolé (clusters dédiés). On parle souvent de Kubernetes-in-Kubernetes, car certains outils permettent de faire tourner des “pseudo-clusters” à l’intérieur d’un cluster principal. Voici les principales approches classées du plus simple au plus complexe :

• Namespaces:
  • Isolation logique uniquement (ressources, RBAC).
  • Tout est partagé : API server, scheduler, etcd, runtime.
  • Bon pour les environnements de dev internes, mais peu sécurisé en multi-tenant.
• Namespaces as a Service
  • Fournit des namespaces “managés” avec politiques, quotas, RBAC isolés.
  • Outils : Capsule (Clastix), HNC (Hierarchical Namespace Controller) mais en mode « retired ».
  • Approche légère mais encadrée, utile en self-service contrôlé.
• Kubernetes API as a Service
  • L’utilisateur interagit avec une API Kubernetes dédiée, mais sans avoir un vrai cluster : pas de scheduler, pas de control-plane séparé.
  • Outil : kcp, un K8s sans scheduler.
  • Bon compromis pour donner une illusion de cluster à des utilisateurs ou systèmes sans overhead complet.
• Control Plane as a Service (internal)
  • Chaque tenant obtient un plan de contrôle complet, hébergé à l’intérieur du cluster principal.
  • Outils : vCluster, Kamaji, k3k.
  • Plus d’isolation (vraie API, CRDs séparées), tout en gardant une infra commune. Très utilisé pour la démo, le test ou la formation et certains usecases de production.
• Control Plane as a Service (external)
  • Le control-plane tourne à l’extérieur du cluster host, typiquement sur du managé.
  • Outils : HyperShift (Red Hat), Kosmotron.
  • Permet de créer des clusters “light” pour les utilisateurs, tout en centralisant leur gestion.
• Dedicated Clusters
• Isolation totale : cluster séparé, réseau, stockage, API, etc.
• Coût et complexité élevés, mais nécessaire pour les environnements réglementés ou très sensibles.

Ce qu’il faut retenir :

• Plus on monte dans la pile (du rouge au vert), plus on gagne en isolation, mais on paie en complexité et coût.
• Le choix dépend de vos besoins : auto-provisionnement léger pour des devs, multi-tenant fort pour production, séparation stricte, …
• Cette grille permet d’industrialiser le multi-tenancy selon différents niveaux de sécurité, de performance et de gestion.

L’avenir de la NetworkPolicy : plus riche, plus fine, plus sûre

La NetworkPolicy v1 (standard Kubernetes) reste encore largement utilisée. Elle permet, comme dans l’exemple ci-dessous, de restreindre les communications entre Pods via des labels et des ports TCP :

# Exemple : autoriser uniquement les pods "frontend" à parler aux "backend" sur le port 6379
kind: NetworkPolicy
metadata:
  name: netpolv1
  namespace: sokube
spec:
  podSelector:
    matchLabels:
      role: backend
  policyTypes:
    - Ingress
    - Egress
  ingress:
    - podSelector:
        matchLabels:
          role: frontend
      ports:
        - protocol: TCP
          port: 6379

Mais ce modèle reste limité :

• Filtrage de base L3/L4 (IP, ports, labels uniquement)
• Pas de “deny” explicite (par défaut, tout est bloqué si une policy existe)
• Peu adapté aux environnements multi-namespace ou multi-tenant

De nouvelles générations apparaissent : Admin & Baseline Policies
Des CRDs avancés, comme BaselineAdminNetworkPolicy, permettent d’exprimer des politiques globales ou par namespace, avec un vrai filtrage en “deny” explicite, utile pour sécuriser les environnements dès le départ :

# Exemple : refuser tout trafic inter-namespace (par défaut)
kind: BaselineAdminNetworkPolicy
metadata:
  name: default-deny
spec:
  subject:
    namespaces: {}
  ingress:
    - name: "default-deny"
      action: "Deny"
      from:
        - namespaces: {}
  egress:
    - name: "default-deny"
      action: "Deny"
      to:
        - namespaces: {}

Et demain : filtrage L7 et identités
Avec Istio et les Service Mesh, on monte encore d’un cran : les AuthorizationPolicy permettent de filtrer non plus sur des IP ou labels, mais sur :

• des identités (ServiceAccount),
• des méthodes HTTP,
• des chemins d’API :

# Exemple : autoriser uniquement GET sur /siliconchalet/events depuis un SA spécifique
kind: AuthorizationPolicy
metadata:
  name: sokube
  namespace: siliconchalet
spec:
  action: ALLOW
  rules:
    - from:
        - source:
            principals: ["cluster.local/ns/default/sa/sokube"]
      to:
        - operation:
            methods: ["GET"]
            paths: ["/siliconchalet/events"]

La sécurité réseau dans Kubernetes évolue de la simple isolation de pods (NetworkPolicy v1) vers des règles globales ou admin via des CRDs (Baseline/ANP), jusqu’au filtrage intelligent basé sur les identités et la couche 7 avec les service mesh comme Istio.

Mais beaucoup de travail reste à faire: standardisation, portabilité entre CNI, et intégration avec des contrôles d’accès plus riches. Certains posent déjà la question : la NetworkPolicy pourrait-elle devenir la future Gateway API de la sécurité réseau ? Un cadre unifié, extensible, intégrant L3 → L7 et s’alignant avec l’évolution vers le Zero Trust.

Une démo est disponible dans ce repo Github : NetworkPolicy Demo

Observabilité : Vers une Surveillance Intelligente et Automatisée

L’observabilité avec OpenTelemetry : simple, automatique, multi-langage

OpenTelemetry est en train de devenir le standard universel de l’observabilité dans l’écosystème cloud-native. Une de ses forces clés : la capacité d’auto-instrumentation, sans avoir à modifier le code de l’application.

Fonctionnement (exemple) : On déclare un objet Instrumentation Kubernetes comme ci-dessous :

apiVersion: opentelemetry.io/v1alpha1
kind: Instrumentation
metadata:
  name: demo-instrumentation
spec:
  exporter:
    endpoint: http://trace-collector:4318
  propagators:
    - tracecontext
    - baggage
  sampler:
    type: parentbased_traceidratio
    argument: "1"

Cela suffit à injecter automatiquement des traceurs dans les applications supportées.

Points clés :

• Multi-langage : support natif pour .NET, Java, Node.js, Python, Go.
• Pas de modification applicative : une simple annotation dans le Pod suffit.
• Export des traces, métriques et logs vers des backends comme Grafana Tempo, Jaeger, Prometheus…

En résumé : on déploie, on annote, on trace !

Une démo est disponible dans ce repo Github : OpenTelemetry Demo

L’observabilité et l’IA : vers une analyse assistée des incidents

Face à la multitude de données observables (traces, logs, métriques) et leur volume croissant, identifier une panne ou un goulet d’étranglement devient un véritable défi.
L’IA entre ici en scène non pas pour remplacer l’humain, mais pour pré-analyser et résumer les signaux clés.

Les défis actuels :

• Trop d’informations, mal reliées entre elles.
• Diversité des formats et des sources (Prometheus, Tempo, Loki, etc.).
• Interprétation manuelle lente, sujette à erreurs.
• Les LLM généralistes peuvent halluciner et sortir du contexte.

La bonne approche : des agents spécialisés plutôt qu’un chatbot générique.

• Traces : détectent automatiquement les spans critiques (ex. ici, une requête lente sur MonstorService/Get avec 100% de la latence concentrée).
• Logs : extraient les erreurs significatives (TimeoutException, ici), corrélées aux traces.
• Métriques : interprètent les sauts ou les anomalies (CPU, latence, erreurs).
• Dashboards : structurent la donnée pour action immédiate.

Résultat observé (exemple réel) :

• exemple avec 1239 spans analysés, goulet identifié sur une requête base de données lente.
• Rapport lisible automatiquement, avec résumé des erreurs, trace ID, durée, etc.
• Le tout sans écrire de requête manuelle dans Grafana ou Elastic.

En résumé, l’observabilité moderne est un travail de data engineering, et donc il y a quand même des points essentiels à maîtriser :

• Nettoyer et structurer la donnée en amont (via OpenTelemetry, par ex.).
• Limiter le contexte inutile pour faciliter l’analyse.
• Déléguer la lecture brute à l’IA, mais garder l’humain pour la décision.

Ce n’est pas “branchement d’un LLM = magie”, mais bien une automatisation ciblée, sur des briques normalisées.

IA & LLM : « K8s is the new web app »

Observability in the Age of LLMs : remettre de la rigueur dans la magie

Les LLMs sont partout, mais une fois la démo passée, beaucoup tombent de haut : lenteur, réponses incohérentes, coûts qui explosent… car construire une application basée sur un modèle de langage ne ressemble en rien au développement logiciel classique.

• Pourquoi les LLMs ne sont pas des APIs comme les autres ?
  • Pas testables unitairement : trop d’entrées possibles, comportement non déterministe.
  • Pas reproductibles facilement : deux appels identiques peuvent donner deux réponses différentes.
  • Pas toujours explicables : pas de spec claire, pas de logique purement fonctionnelle.

La solution : L’observabilité devient la clé.

1. Les LLMs sont des boîtes noires : on ne les teste pas, on les observe en production : prompts, versions de modèle, coûts, temps de réponse…
2. L’observabilité est votre lampe torche : chaque appel devient un “trace” enrichi de contexte. C’est votre boîte noire d’avion pour comprendre un incident.
3. Les tests classiques ne suffisent pas : place aux evals
   • Petits jeux d’entrée + critères de qualité = “évaluations” tournées en boucle pour valider les réponses.
   • Exemples de prompts :
   • 100 prompts de test
   • 100 prompts de production
   • 100 prompts de production avec un nouveau modèle
   • 100 prompts de production avec un nouveau modèle et un nouveau prompt
   • 100 prompts de production avec un nouveau modèle et un nouveau prompt et un nouveau contexte
   • …
   • L’évaluation utilise elle-même un LLM pour décider si le modèle est bon ou pas
   • Les jeux de tests contiennent aussi bien des données correctes que des données incorrectes
4. Feedback loop en continu : on déploie vite (CI/CD, feature flags), on observe, on ajuste. C’est du “test in prod” structuré.
5. Mise en place de SLOs orientés utilisateurs : pas juste “95 % de réponses en < 200 ms”, mais plutôt :
   • ≥ 98 % de réponses correctes selon feedback humain
   • < 0,5 $ les 1 000 prompts
6. Haute cardinalité, haute dimension : chaque prompt est unique. On doit stocker l’entrée, la sortie, le contexte pour expliquer une anomalie.
7. Pas besoin d’être chercheur IA : si vous êtes DevOps ou SRE, vous avez déjà les bons réflexes : traçabilité, SLOs, rollback rapide. Il suffit de les adapter.

“Les LLMs ajoutent de la magie, mais aussi beaucoup d’incertitude.
L’observabilité est ce qui transforme cette magie en produit fiable.”

Comme l’a résumé Christine Yen dans « Observability in the Age of LLMs« , le vrai défi n’est pas d’avoir un modèle, mais de le maintenir en production, en le comprenant vraiment — à travers ce qu’il fait, pas ce qu’on attendait.

LLM & Kubernetes : faire tourner l’intelligence artificielle en local

Voir la conférence complète → Production-Ready LLMs on Kubernetes

Avec la montée en puissance des modèles open source, héberger un LLM sur Kubernetes devient une option viable pour de nombreuses entreprises. Cela répond à plusieurs enjeux :

• Sécurité et conformité : exécution en mode airgap, contrôle total des données et des modèles (via un registry privé).
• Latence et disponibilité : ne plus dépendre d’un service cloud distant.
• Coût à long terme : éviter les frais à l’usage des API SaaS.
• Portabilité : Kubernetes offre une plateforme cohérente pour exécuter ces modèles, où que l’on soit.

Pour démarrer : Ollama + Open WebUI

• Ollama est parfait pour les POCs rapides et les workloads interactifs en local.
• Couplé à Open WebUI, il fournit une interface simple pour tester des prompts, sans effort d’intégration complexe.

Oui, mais… les LLMs sont gourmands !

Problèmes majeurs :

• Context length : limite du nombre de tokens qu’un modèle peut “voir” d’un coup (souvent 4k, 8k, parfois jusqu’à 128k).
• Quadratic memory usage : la mémoire explose avec la longueur du contexte, car l’attention calcule une matrice N×N.
• Quantization : permet de réduire la taille mémoire (ex. 8 bits ou 4 bits), mais au prix d’une perte de précision potentielle.

Résultat : les GPU saturent vite — même un A100 peut suffoquer si le contexte est trop long.

Des solutions émergent : vLLM à la rescousse
Pour faire entrer de grands modèles dans de petites configs, des projets comme vLLM introduisent des optimisations majeures :

• Paged KV cache : garde en mémoire uniquement ce qui est utile (vs. tout charger en RAM).
• FlashAttention v2 : accélère massivement l’attention sur de longs contextes.
• Context pruning : coupe intelligemment les tokens peu pertinents.
• Quantization + GPU sharing : réduit l’empreinte mémoire, permet d’exécuter plusieurs modèles ou requêtes sur un seul GPU.

Résultat : 2 à 4 fois plus de capacité GPU, sans nouveau matériel, avec les bons flags ou un build optimisé vLLM + FlashAttention.

A noter qu’il existe des initiatives comme AISpec.org qui cherchent à formaliser des CRDs pour décrire les workloads AI — à l’image de ce que Helm ou Kustomize font pour les apps traditionnelles.

Pourquoi Kubernetes deviendra la plateforme de choix pour les architectures agentiques ?

Kubernetes s’impose peu à peu comme la plateforme idéale pour exécuter des architectures agentiques, où des agents IA autonomes collaborent, dialoguent avec des APIs et orchestrent des tâches complexes.
Pour cela Solo.io a annoncé plusieurs projets: Kgateway, MCP Gateway qui fait partie du projet Kgateway et Kagent

Kgateway : une Gateway API pour l’IA : Il s’appuie sur le standard Kubernetes Gateway API, adapté au trafic IA :

• Routage vers différents modèles (GPT‑4o, Llama 3, Mistral…) selon coût ou latence.
• Support des appels IA spécifiques : streaming, délais variables, payloads volumineux.
• Observabilité et sécurité intégrées : quotas, suivi des prompts, traces OTel.

MCP (Model Context Protocol) Gateway :

• MCP (Model Context Protocol est un protocole ouvert initié par Anthropic pour standardiser les échanges entre clients et serveurs de modèles IA — qu’il s’agisse de génération de texte, d’embeddings ou de gestion de contexte —, avec le soutien d’OpenAI et d’autres acteurs majeurs, dans le but de favoriser l’interopérabilité et la portabilité des applications IA.
• MCP Gateway permet de gérer de manière centralisée la découverte, la sécurité, l’observabilité, la gestion du trafic et la gouvernance des outils MCP, tout en multiplexant de façon transparente les requêtes des clients MCP vers les serveurs d’outils MCP en amont.

Enfin, Kagent est un framework open-source pour agents IA sur Kubernetes qui permet :

• L’exécution d’agents autonomes avec gestion du cycle de vie et mémoire.
• La standardisation via MCP pour brancher APIs, outils internes, ou prompts.
• La sécurité native (mTLS), la traçabilité (OTel) et un catalogue partagé pour publier et réutiliser des agents.

Voir la vidéo Why Kubernetes Will Become the Platform of Choice for Agentic Architectures

Kubernetes souhaite clairement devenir la plateforme de référence pour exécuter les LLMs, comme l’a résumé Clayton Coleman avec la formule :

“LLMs is the new Web App”

Mais ces modèles ne se gèrent pas comme une simple API REST : ils sont gourmands en ressources, nécessitent des GPU, des optimisations mémoire, et une approche différente du cycle de vie (observabilité, tests par évaluation, déploiement rapide). Que ce soit on-premise (pour la souveraineté et la confidentialité) ou dans le cloud, Kubernetes continue d’évoluer pour intégrer ces nouveaux usages, tout en restant compatible avec les pratiques DevSecOps : sécurité native, CI/CD, observabilité, et gouvernance. Les outils cités ci-dessus montrent que l’écosystème IA se structure à l’image de ce qu’a été le web pour Kubernetes… en beaucoup plus exigeant.

Platform Engineering : vers une adoption de masse

Le Platform Engineering s’impose en 2025 comme une pratique structurée et largement adoptée dans les entreprises pour offrir des environnements self-service centralisés, fiables et sécurisés.
Voir notre article sur le sujet : DevOps et Platform Engineering: efficacité et scalabilité de votre IT

Tendances marquantes sur le Platform Engineering :

• De plus en plus de retours d’expérience : la pratique gagne en maturité avec des modèles adaptables selon les contextes.
• Deux nouvelles certifications Linux Foundation pour valider les compétences en Platform Engineering:
  • Platform Engineering Certification
  • Platform Engineering Associate Certification
• Spotify fête les 5 ans de Backstage avec des chiffres impressionnants :
  • 3 400 adopteurs, 230+ plugins open source, près de 30 000 étoiles GitHub
  • Plus de 400 000 entités gérées dans leurs portails internes
• Annonce de “Spotify Portal for Backstage” (en bêta) :
  • Une version packagée, prête à l’emploi.
  • Objectif : déploiement simple, sans codage requis, pour accélérer l’adoption.
  • Voir aussi The State of Backstage in 2025

Deux témoignages ont particulièrement retenu l’attention, illustrant comment le Platform Engineering peut transformer à la fois l’expérience développeur et la sécurité à l’échelle.

LEGO – “Kubernetes as a Platform”

LEGO a présenté sa nouvelle plateforme Kubernetes, pensée pour offrir une expérience fluide et cohérente, que ce soit on-premise ou dans le cloud. Leur approche est résolument structurée :

• Plateforme fortement opiniated : GitOps obligatoire, politiques d’enforcement, secret management intégré…
• Infrastructure durable et autonome : certificat, self-service, 24/7, support automatisé.

Mais surtout, LEGO met l’accent sur la gestion du changement avec une approche “vendeur” :

• Comprendre les besoins des utilisateurs.
• Organiser des workshops, événements techniques, mises en relation.
• Proposer des services comme “Rent-an-Engineer” ou du support tournant.

Leur mantra :

“Sell your platform”
“Keep your users close”

Voir la conférence complète

Sécurité & Platform Engineering – “Shift Down, Not Left”

Ce second retour, centré sur la sécurité, propose un message clair :
Plutôt que de “shift-left” la sécurité vers les développeurs, intégrez-la dans la plateforme pour la rendre invisible et cohérente.

Les clés d’une plateforme sécurisée :

• Construire une base fiable et standardisée (CI/CD, policy-as-code, etc.)
• Empêcher les erreurs plutôt que les corriger après.
• Alléger le quotidien des équipes Dev via le self-service sécurisé.
• Favoriser l’innovation sans bloquer grâce à des garde-fous bien pensés.

Recommandations :

• Rester dans le “inner loop” des devs.
• Aller vers le “keyless”, l’automatisation, l’observabilité.
• Se rappeler que Kubernetes n’est pas une IDP.

En résumé :

“Shift down to the platform, instead of shifting left to the developer”
Adopter une culture de sécurité par le design, en mode « Platform-as-a-Product »

Voir la conférence complète : Platform Engineering Loves Security: Shift Down To Your Platform, Not Left To Your Developers!

FinOps : le FinOps dans Kubernetes

Dans l’écosystème Kubernetes, un défi majeur concerne le gaspillage des ressources (CPU, mémoire, stockage et nœuds inadaptés), ce qui représente un enjeu FinOps important.

Pour répondre à cette problématique, une approche innovante consiste à détourner l’usage traditionnel d’OPA et Gatekeeper. Habituellement dédiés à la sécurité, ces outils peuvent être utilisés pour implémenter des politiques FinOps en langage Rego, appliquées directement lors de l’admission des objets dans le cluster. D’autres outils existent comme kyverno.

Cette stratégie permet de mettre en place plusieurs types de règles essentielles :

• La limitation des ressources CPU et mémoire
• L’obligation d’utiliser des étiquettes de coûts
• L’utilisation forcée des instances Spot en environnement de développement
• L’établissement de plafonds budgétaires par namespace
• L’utilisation de classes de stockage économiques

L’intégration avec OpenCost offre une visibilité en temps réel sur les métriques, tandis que l’audit continu et le mode « dry-run » permettent de sensibiliser les développeurs avant d’appliquer des restrictions strictes.

Les bénéfices de cette approche sont multiples : une meilleure visibilité budgétaire, une réduction pérenne des dépenses, et une gouvernance unifiée combinant sécurité et maîtrise des coûts dans un même cadre GitOps.

Voir la conférence complète : Beyond Security: Leveraging OPA for FinOps in Kubernetes

Conclusion

La KubeCon + CloudNativeCon Europe 2025 a confirmé que Kubernetes n’est plus un sujet “pionnier”, mais entre dans une nouvelle phase : plus de maturité, plus de cas d’usage, et surtout un passage à l’échelle sans précédent.

L’IA n’est plus une option : workloads LLM, agents et pipelines MLOps deviennent courants, et Kubernetes s’affirme comme la plateforme privilégiée pour les héberger, grâce à sa portabilité et à l’offre croissante d’outils GPU-aware.
Des patterns IA exigeants : gestion du contexte, partage fin des GPU, optimisations mémoire ; ces défis imposent une observabilité de haute précision pour suivre coûts, latence, dérives de qualité et respect des SLO.
Le Platform Engineering se généralise : les retours d’expérience prouvent qu’une plateforme opiniated, centralisée, sécurisée et standardisée est aujourd’hui le moyen le plus sûr de dompter cette complexité tout en servant les équipes produit en self-service.

En résumé, l’écosystème avance vers toujours plus de cas d’usage — IA en tête — à grande échelle. Cette montée en puissance s’accompagne toutefois d’une complexité accrue.

Le message de la KubeCon 2025 est clair : La maturité et l’innovation continue, mais la rigueur devient indispensable pour transformer Kubernetes en levier stratégique plutôt qu’en dette technologique.