Conteneurisation 2025 : Pourquoi containerd 2.0 et eBPF changent tout

Le paysage de la conteneurisation, perpétuellement dynamique, a connu une multitude d'avancées pratiques et robustes fin 2024 et tout au long de 2025. En tant que développeurs seniors, nous avons dépassé le "cycle de battage médiatique" et sommes dans les tranchées, évaluant les fonctionnalités qui offrent des avantages opérationnels tangibles et répondent à des contraintes réelles. L'année écoulée a consolidé plusieurs tendances : une poussée incessante vers une sécurité accrue tout au long de la chaîne d'approvisionnement, des améliorations fondamentales de l'efficacité de l'exécution, un bond significatif en matière d'ergonomie de construction pour les déploiements multi-architectures, et l'émergence de WebAssembly comme une alternative crédible, bien que naissante, pour des charges de travail spécifiques. Voici une analyse approfondie des développements qui comptent vraiment.

La Nouvelle Fondation : containerd 2.0 et eBPF

containerd 2.0 : La Fondation CRI Renforcée

La fondation de notre monde conteneurisé, l'environnement d'exécution des conteneurs, a connu une évolution significative, notamment avec la sortie de containerd 2.0 fin 2024. Il ne s'agit pas simplement d'une mise à jour incrémentale ; c'est une stabilisation stratégique et une amélioration des capacités de base sept ans après sa version 1.0. Le passage de dockershim dans Kubernetes v1.24 a mis containerd et CRI-O au premier plan, tout comme les outils CLI modernes redéfinissent l'expérience des développeurs en 2025.

containerd 2.0 apporte plusieurs fonctionnalités clés au canal stable qui méritent une attention particulière. L'Interface de Ressources de Nœud (NRI) est désormais activée par défaut, fournissant un mécanisme d'extension puissant pour personnaliser les configurations de conteneurs de bas niveau. Cela permet un contrôle plus précis de l'allocation des ressources et de l'application des politiques, similaire aux webhooks d'admission mutateurs mais fonctionnant directement au niveau de l'exécution. Les développeurs peuvent tirer parti des plugins NRI pour injecter des configurations d'exécution spécifiques ou appliquer des politiques de gestion des ressources personnalisées de manière dynamique, une capacité qui était auparavant plus difficile à mettre en œuvre sans modifications directes de l'environnement d'exécution.

De plus, containerd 2.0 prend désormais en charge les Plugins de Vérification d'Images. C'est véritablement impressionnant car cela permet l'application de politiques concernant les images au moment du tirage de l'image. Réfléchissez-y : au lieu de scanner les images uniquement pendant la CI/CD ou au moment du déploiement, vous pouvez maintenant avoir containerd lui-même invoquer un plugin externe (qui peut être n'importe quel exécutable binaire ou script) pour valider l'intégrité ou la conformité d'une image avant qu'elle ne soit entièrement tirée et exécutée. Cela s'intègre directement au transfer service (stabilisé dans 2.0), bien qu'il soit noté que le plugin CRI n'est pas encore entièrement intégré, de sorte que son impact immédiat sur les déploiements Kubernetes pourrait être limité jusqu'à ce que cela se produise. Néanmoins, pour les utilisateurs directs de containerd, il s'agit d'une avancée robuste pour la sécurité de la chaîne d'approvisionnement à la limite de l'exécution. Sur le front de la sécurité, containerd v2.2.0 inclut également des correctifs pour des vulnérabilités critiques telles que CVE-2024-25621 et CVE-2025-64329, ainsi que runc v1.3.3 corrigeant CVE-2025-31133, CVE-2025-52565 et CVE-2025-52881, démontrant un effort continu pour renforcer les composants de base.

L'Ascension d'eBPF : Contrôle au Niveau du Kernel pour la Mise en Réseau et l'Observabilité

J'attendais qu'eBPF atteigne véritablement son apogée dans l'écosystème des conteneurs, et fin 2024 à 2025 a tenu ses promesses. L'intégration d'eBPF (extended Berkeley Packet Filter) dans les piles de mise en réseau et d'observabilité de Kubernetes est passée d'une curiosité expérimentale à une technologie fondamentale. eBPF permet à des programmes sandboxés de s'exécuter directement dans le kernel Linux, déclenchés par divers événements, offrant des performances et une flexibilité sans précédent sans la surcharge des commutations d'espace kernel-espace utilisateur traditionnelles.

Pour la mise en réseau, les plugins d'interface réseau conteneurisée (CNI) basés sur eBPF tels que Cilium et Calico remplacent activement ou offrent des alternatives supérieures aux approches basées sur iptables. L'avantage principal réside dans un traitement efficace des paquets. Au lieu de parcourir des chaînes iptables complexes pour chaque paquet, les programmes eBPF peuvent prendre des décisions de routage et de politique directement à un stade antérieur de la pile réseau du kernel. Cela réduit considérablement la surcharge du CPU et la latence, en particulier dans les clusters Kubernetes à grande échelle. Des projets comme Cilium ont fait progresser la mise en réseau des conteneurs, remplaçant iptables par des datapaths eBPF efficaces, et son statut diplômé avec la CNCF et son inclusion dans des projets comme OpenTelemetry en font un standard de facto pour la gestion des politiques réseau.

Au-delà des performances, eBPF améliore considérablement l'observabilité. En attachant des programmes eBPF aux appels système, aux événements réseau et aux activités des processus, les développeurs peuvent capturer des données de télémétrie détaillées directement à partir du kernel en temps réel. Cela offre une visibilité granulaire sur le comportement des conteneurs, les flux réseau et les appels système sans nécessiter de proxies sidecar intrusifs ou d'instrumentation des applications. Par exemple, un programme eBPF peut surveiller toutes les connexions réseau initiées par un conteneur spécifique, détecter des modèles d'accès aux fichiers inhabituels ou tracer les appels système, offrant un outil puissant à la fois pour le débogage des performances et la détection des menaces de sécurité en temps réel.

Modernisation du Flux de Travail de Construction et de Développement

BuildKit 2.0 & Docker Build Cloud : Constructions Plus Intelligentes, Plus Rapides, Plus Sécurisées

Si vous traitez encore docker build comme une boîte noire, vous manquez quelque chose. BuildKit est le constructeur par défaut dans Docker Engine depuis la version 23.0, et BuildKit 2.0, ainsi que Docker Build Cloud, représentent un bond significatif en avant dans la façon dont nous construisons les images de conteneurs. BuildKit 2.0 ne se limite pas à la vitesse ; c'est un changement de paradigme vers des pipelines de construction plus sécurisés, portables et intelligemment optimisés.

L'une des fonctionnalités remarquables de BuildKit 2.0 est la Mise en Cache Fédérée. La mise en cache basée sur le registre (--cache-from) a toujours été un peu lente et gourmande en réseau. La mise en cache fédérée introduit cependant un mécanisme de mise en cache peer-to-peer, permettant à vos agents de construction de former un cluster de cache distribué. Lorsqu'un agent construit une couche, elle peut être instantanément disponible pour les autres sur le même réseau sans un aller-retour vers un registre distant. Cela réduit considérablement les temps de construction pour les équipes, en particulier dans les architectures de microservices où les images de base sont fréquemment reconstruites, transformant une pause café en un rafraîchissement rapide.

Tout aussi passionnant est l'introduction des Étapes de Construction WASM Natives. Les commandes RUN complexes impliquant curl, tar et sed sont tristement célèbres pour créer des constructions instables et non sécurisées. BuildKit 2.0 s'attaque à ce problème en permettant d'utiliser des modules WebAssembly (WASM) comme étapes de construction natives. Au lieu d'enchaîner des commandes shell, vous pouvez utiliser un binaire WASM précompilé et sandboxé pour effectuer des tâches telles que la récupération d'actifs, la génération de code ou le linting. Cela offre une exécution sandboxée et une portabilité améliorée, rendant vos constructions plus fiables et plus sécurisées. De plus, BuildKit 2.0 s'intègre profondément aux pratiques de sécurité modernes, générant automatiquement des attestations SLSA et signant les images à l'aide de Sigstore/Cosign dans le cadre natif du processus de construction.

Complétant BuildKit 2.0, Docker Build Cloud, lancé en janvier 2024, vise à accélérer les constructions en les déchargeant dans le cloud. Ce service tire parti de la puissance de calcul du cloud et de la mise en cache pour atteindre des temps de construction jusqu'à 39 fois plus rapides que les constructions locales. Il prend en charge nativement les constructions multi-architectures (AMD64, ARM64) éliminant le besoin d'émulation lente ou de maintenance de plusieurs constructeurs natifs. La commande docker buildx build --platform linux/amd64,linux/arm64 -t myregistry/my-app:latest --push . rend la construction pour plusieurs architectures transparente.

Docker Compose v5 : Amélioration des Flux de Travail de Développement Locaux

Docker Compose a toujours été le cheval de bataille du développement multi-conteneurs local, mais l'évolution récente, culminant avec Compose v5 en décembre 2025, en a fait un outil encore plus puissant et intégré. Le changement structurel le plus important a été l'intégration complète de docker compose (l'implémentation basée sur Go) directement dans la CLI Docker, dépréciant officiellement l'ancien docker-compose basé sur Python (avec un tiret).

L'une des fonctionnalités que j'attendais est docker compose watch. Cette commande suit les fichiers et actualise automatiquement les conteneurs en cours d'exécution dès qu'un fichier est enregistré, éliminant le besoin de cycles manuels docker compose up ou restart. Pour un développeur d'applications web, cela signifie une boucle de rétroaction étroite : écrire-enregistrer-visualiser se produit en quelques secondes, parfait pour itérer sur les points de terminaison d'API ou les aperçus frontaux en direct. Vous pouvez l'activer avec une simple étiquette dans votre compose.yml :

services:
  web:
    build: .
    ports:
      - "80:80"
    labels:
      com.docker.compose.watch: "true" # Active le mode watch pour ce service

D'autres améliorations notables de la CLI incluent docker compose attach pour le débogage, docker compose stats pour la surveillance en direct de l'utilisation des ressources et docker compose cp pour copier facilement des fichiers entre l'hôte et un conteneur de service. Le champ version dans docker-compose.yml est désormais complètement déprécié ; les fichiers Compose modernes doivent l'omettre, en commençant directement par le bloc services:. Compose v5 introduit également un nouveau SDK Go officiel, fournissant une API complète pour intégrer la fonctionnalité Compose directement dans les applications.

L'IA/ML et l'Évolution de Docker Desktop

Le Pivot IA/ML de Docker Desktop : Au-Delà de la Conteneurisation Pure

Docker Desktop continue d'évoluer en tant que poste de travail de développement complet, et ses fonctionnalités en 2025 montrent un pivot distinct vers le support des flux de travail de développement IA/ML. Au-delà de sa fonction principale de fournir un moteur Docker local et un cluster Kubernetes, Docker Desktop intègre désormais des outils qui répondent directement aux points faibles des développeurs IA.

La fonctionnalité Model Runner, par exemple, vise à simplifier l'exécution locale des LLM. L'exécution de modèles IA localement implique souvent de jongler avec des environnements Python, des installations CUDA, des formats de modèles spécifiques et des dépendances complexes. Docker's Model Runner abstrait une grande partie de cette complexité, permettant aux développeurs de tirer et d'exécuter des modèles avec une simple commande docker model pull ai/llama3.2:1B-Q8_0 (à partir de Docker Desktop 4.40+). C'est véritablement impressionnant car cela réduit la barrière à l'entrée pour expérimenter avec les grands modèles linguistiques et d'autres applications d'IA, fournissant un environnement conteneurisé cohérent pour l'exécution des modèles.

Pour les charges de travail qui dépassent les ressources de la machine locale, Docker Offload offre un moyen transparent d'exécuter des modèles et des conteneurs sur des GPU cloud. Cela libère les développeurs des contraintes d'infrastructure en déchargeant les tâches gourmandes en calcul, telles que les grands modèles linguistiques et l'orchestration multi-agents, vers des environnements cloud haute performance. De plus, le MCP Toolkit (pour le développement d'agents IA) et Docker Debug (pour un débogage amélioré avec des conteneurs de débogage légers) complètent les capacités étendues de Docker Desktop, en en faisant un outil plus polyvalent pour le développement moderne et gourmand en ressources.

Renforcement de la Chaîne d'Approvisionnement et de la Confidentialité des Données

Sécurité Avancée des Images et Images Renforcées

La dépendance croissante aux composants open source signifie que les images de conteneurs sont un point de contrôle principal pour la sécurité de la chaîne d'approvisionnement logicielle, et Docker a considérablement intensifié ses efforts en 2024-2025. Plus de 90 % des applications modernes dépendent de l'open source, et les images de conteneurs peuvent inclure des centaines de dépendances, faisant de la couche d'image l'une des surfaces d'attaque les plus importantes et les moins visibles.

Docker Scout (anciennement Docker Scan) est désormais une pièce centrale de cette stratégie, offrant une analyse continue des vulnérabilités pour des dépôts Scout activés illimités dans les plans Docker Team et Business. Il fournit des informations en temps réel sur les risques liés aux images et les corrections recommandées, s'intégrant de manière transparente à la CLI Docker et aux pipelines CI/CD. Cette approche "shift-left" est cruciale, permettant aux développeurs d'identifier et de corriger les vulnérabilités dès le début du cycle de développement, empêchant les images non sécurisées d'atteindre la production.

Un développement particulièrement percutant est la décision de Docker de rendre les Images Docker Renforcées gratuites pour tous. Ces images fournissent une base sécurisée par défaut, réduisant la friction entre la vitesse de développement et la sécurité. Elles sont accompagnées d'un support du cycle de vie étendu, aidant les entreprises à rester conformes et à atténuer les risques de fin de vie. Cette décision signale l'engagement de Docker à établir une nouvelle norme pour l'ensemble de l'écosystème des conteneurs, faisant de la sécurité une attente de base plutôt qu'une fonctionnalité premium.

Conteneurs Confidentiels : Apporter la Confiance aux Environnements Non Fiables

Pour les charges de travail hautement sensibles, le concept de Conteneurs Confidentiels (CoCo) a mûri de manière significative, passant de la recherche de niche aux implémentations pratiques. CoCo est un projet sandbox CNCF qui vise à permettre le calcul confidentiel natif du cloud en tirant parti des Environnements d'Exécution de Confiance (TEE) pour protéger les conteneurs et les données. C'est un changement de jeu pour la confidentialité des données, en particulier dans les secteurs réglementés ou pour le traitement des informations personnellement identifiables (PII).

L'idée centrale est de créer des enclaves sécurisées au sein d'un processeur, qui protègent les données traitées de l'environnement environnant, y compris le CPU, l'hyperviseur et même les administrateurs cloud. Les technologies telles que Intel SGX, Intel TDX et AMD SEV constituent la base matérielle, chiffrant la mémoire des conteneurs et empêchant les données en mémoire d'être en texte clair. Cette approche "boîte noire" garantit que les flux de travail sensibles sont protégés contre tout accès non autorisé.

L'objectif du projet CoCo est de standardiser le calcul confidentiel au niveau du conteneur et de simplifier sa consommation dans Kubernetes. Cela signifie que les utilisateurs de Kubernetes peuvent déployer des charges de travail de conteneurs confidentielles en utilisant des flux de travail et des outils familiers, sans avoir besoin d'une connaissance approfondie des technologies de calcul confidentiel sous-jacentes. Bien qu'encore en prévisualisation pour certains fournisseurs de cloud et entraînant une surcharge de performances inhérente en raison de l'isolation supplémentaire, la capacité d'atteindre un nouveau niveau de confidentialité et d'intégrité des données en empêchant la lisibilité des données en mémoire est une avancée puissante.

La Réalité de Wasm et la Feuille de Route

La Nuance de Wasm : Une Histoire de Deux Implémentations

WebAssembly (Wasm) dans l'écosystème des conteneurs présente une dualité intéressante. D'une part, l'introduction par BuildKit 2.0 des Étapes de Construction WASM Natives est un développement convaincant pour améliorer la sécurité et la portabilité de la construction. Ici, les modules Wasm sont utilisés dans le processus de construction pour exécuter des tâches spécifiques, offrant une alternative sandboxée et efficace aux scripts shell traditionnels. Il s'agit d'une avancée pratique et robuste qui répond aux problèmes réels de fiabilité et de sécurité de la construction.

Cependant, l'histoire de Wasm en tant qu'environnement d'exécution de conteneurs direct dans Docker Desktop semble prendre une tournure différente. Les notes de publication de Docker Desktop 4.55.0 de décembre 2025 indiquent explicitement que les charges de travail Wasm seront dépréciées et supprimées dans une future version de Docker Desktop. C'est une réalité cruciale. Bien que runwasi existe en tant que projet non central de containerd pour un shim WASM, la décision de Docker pour Desktop suggère que l'exécution directe de Wasm pourrait ne pas avoir atteint l'adoption ou la viabilité technique attendue pour les flux de travail de développement généraux dans leur produit Desktop.

Conclusion : La Feuille de Route

Quelle année ! Les avancées apportées à Docker, containerd et Kubernetes fin 2024 et tout au long de 2025 sont tout simplement impressionnantes. Nous avons vu containerd 2.0 consolider son rôle de fondation robuste et extensible pour les environnements d'exécution de conteneurs, offrant de nouveaux hooks puissants tels que NRI et les plugins de vérification d'images. L'ascension d'eBPF a fondamentalement modifié notre façon de penser à la mise en réseau des conteneurs, à l'observabilité et à la sécurité, faisant passer l'efficacité et la visibilité au niveau du kernel dans le courant dominant.

Pour les développeurs, Docker Compose v5 et les nouvelles fonctionnalités axées sur l'IA/ML de Docker Desktop telles que Model Runner et Docker Offload démontrent un engagement à rationaliser les flux de travail au-delà de la simple gestion des conteneurs, en adoptant les tendances émergentes. Et peut-être plus important encore, l'accent inlassable mis sur la sécurité de la chaîne d'approvisionnement, illustré par l'analyse continue de Docker Scout et la disponibilité gratuite des images Docker renforcées, élève le niveau d'exigence de confiance dans nos artefacts logiciels. Bien que certaines fonctionnalités, telles que l'exécution directe de Wasm dans Docker Desktop, fassent l'objet d'une réévaluation, la trajectoire générale est claire : les conteneurs deviennent plus sécurisés, plus performants et plus intégrés aux paradigmes de développement avancés d'aujourd'hui et de demain.