Conteneurisation 2025 : Pourquoi containerd 2.0 et eBPF changent la donne

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 du monde réel. 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.

Le paysage en évolution de l'exécution des conteneurs : containerd 2.0 et au-delà

Le fondement de notre monde conteneurisé, l'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 et une amélioration stratégiques des capacités de base sept ans après sa version 1.0. Le passage de dockershim dans Kubernetes v1.24 a propulsé containerd et CRI-O au premier plan, consolidant l'interface d'exécution de conteneurs (CRI) comme le protocole d'interaction standard entre le kubelet et l'exécution sous-jacente.

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 puissant mécanisme d'extension 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'exécution. Considérez un scénario dans lequel une organisation doit appliquer un épinglage de CPU spécifique ou une allocation de pages mémoire pour les charges de travail critiques en termes de performances ; un plugin NRI peut désormais le gérer au démarrage du conteneur, garantissant une application cohérente sur divers types de nœuds sans modifier le démon containerd de base.

Une autre avancée notable est la stabilisation des plugins de vérification d'images. Bien que le plugin CRI dans containerd 2.0 n'intègre pas encore pleinement le nouveau service de transfert pour l'extraction d'images, et ne soit donc pas immédiatement disponible pour les charges de travail Kubernetes, sa présence signale un avenir prometteur pour l'application des politiques d'images au moment de l'extraction. Ces plugins sont des programmes exécutables que containerd peut invoquer pour déterminer si une image est autorisée à être extraite, offrant un point de contrôle essentiel pour la sécurité de la chaîne d'approvisionnement. Une fois intégré à la CRI, cela permettra aux administrateurs Kubernetes de définir des politiques granulaires – par exemple, en autorisant uniquement les images signées par des clés spécifiques ou celles disposant d'une liste de matériaux (SBOM) vérifiée – directement au niveau du nœud, avant même qu'un conteneur ne tente de démarrer. Cela déplace l'application des politiques vers la gauche, empêchant les images potentiellement compromises d'atterrir sur un nœud.

La configuration de containerd a également été mise à jour, passant à v3. La migration des configurations existantes est un processus simple à l'aide de containerd config migrate. Bien que la plupart des paramètres restent compatibles, les utilisateurs exploitant le snapshotter aufs obsolète devront passer à une alternative moderne. Cela force un nettoyage nécessaire, favorisant des backends de stockage plus performants et maintenus.

Renforcer la chaîne d'approvisionnement logicielle : l'ascension de Sigstore

L'année 2025 marque un pivot décisif dans la signature des images de conteneurs, Sigstore s'établissant fermement comme la norme ouverte pour la sécurité de la chaîne d'approvisionnement logicielle. Docker, reconnaissant le paysage en évolution et l'adoption limitée de son Docker Content Trust (DCT) hérité, a commencé à retirer formellement DCT (qui était basé sur Notary v1) en août 2025. Ce mouvement, bien qu'il nécessite une migration pour un petit sous-ensemble d'utilisateurs, ouvre la voie à une approche plus unifiée et robuste de la provenance des images.

Sigstore répond au besoin crucial d'une intégrité vérifiable de la chaîne d'approvisionnement grâce à une suite d'outils : Cosign pour la signature et la vérification des artefacts OCI, Fulcio en tant qu'autorité de certification racine publique gratuite émettant des certificats de courte durée, et Rekor en tant que journal de transparence pour tous les événements de signature. Cette triade permet une signature "sans clé", un changement de paradigme significatif. Au lieu de gérer des clés statiques de longue durée, les développeurs utilisent des jetons OIDC de leur fournisseur d'identité (par exemple, GitHub, Google) pour obtenir des certificats de signature éphémères de Fulcio. Cosign utilise ensuite ce certificat pour signer l'image, et la signature, ainsi que le certificat, sont enregistrés dans le journal de transparence immuable Rekor.

Par exemple, la signature d'une image avec Cosign est remarquablement simplifiée :

# Authentification auprès de votre fournisseur OIDC
# cosign récupérera souvent automatiquement cela à partir des variables d'environnement.

# Signer une image (sans clé)
cosign sign --yes <votre-registre>/<votre-image>:<tag>

# Vérifier une image
cosign verify <votre-registre>/<votre-image>:<tag>

L'indicateur --yes dans cosign sign contourne les invites interactives, ce qui est crucial pour les pipelines CI/CD. L'étape de vérification, cosign verify, interroge Rekor pour garantir l'authenticité et l'intégrité de la signature, en la reliant à une identité vérifiable. Cela fournit une provenance forte et auditable sans la surcharge opérationnelle d'une PKI traditionnelle.

Turbocharger les constructions avec Buildx et BuildKit

Buildx de Docker, alimenté par le backend BuildKit, est devenu un outil indispensable pour tout flux de travail de développement de conteneurs sérieux, en particulier pour les constructions d'images multiplateformes et les stratégies de mise en cache. La commande docker build traditionnelle, bien que fonctionnelle, souffre souvent de goulots d'étranglement en termes de performances et d'un support limité pour les architectures croisées. BuildKit réorganise fondamentalement le processus de construction en utilisant un graphe acyclique dirigé (DAG) pour les opérations de construction, permettant l'exécution parallèle des étapes indépendantes et des mécanismes de mise en cache supérieurs.

La fonctionnalité phare, les constructions multiplateformes, n'est plus une capacité de niche mais une nécessité pratique dans un monde qui se diversifie rapidement en architectures amd64, arm64 et même arm/v7. Buildx permet à une seule commande docker buildx build de produire une liste de manifestes contenant des images pour plusieurs plateformes cibles, éliminant ainsi le besoin d'environnements de construction distincts.

Considérez ce Dockerfile :

# Dockerfile
FROM --platform=$BUILDPLATFORM golang:1.21-alpine AS builder
WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download
COPY . .
ARG TARGETOS TARGETARCH
RUN CGO_ENABLED=0 GOOS=$TARGETOS GOARCH=$TARGETARCH go build -o /app/my-app ./cmd/server

FROM --platform=$BUILDPLATFORM alpine:3.18
COPY --from=builder /app/my-app /usr/local/bin/my-app
CMD ["/usr/local/bin/my-app"]

Pour construire pour linux/amd64 et linux/arm64 et pousser vers un registre :

docker buildx create --name multiarch-builder --use
docker buildx inspect --bootstrap
docker buildx build \
  --platform linux/amd64,linux/arm64 \
  -t myregistry/my-app:latest \
  --push .

En termes de performances, la mise en cache de BuildKit est supérieure. Au-delà de la mise en cache locale des couches, Buildx prend en charge la mise en cache du registre, où les couches de construction précédentes poussées vers un registre peuvent être utilisées pour les constructions ultérieures, réduisant considérablement les temps de construction pour les projets fréquemment mis à jour. Cela a un impact particulièrement important dans les pipelines CI/CD où les environnements de construction sont souvent éphémères.

eBPF : Redéfinir le networking et l'observabilité de Kubernetes

L'intégration de eBPF (Extended Berkeley Packet Filter) dans les stacks de networking et d'observabilité de Kubernetes est passée d'une curiosité expérimentale à une technologie fondamentale fin 2024 et 2025. eBPF permet à des programmes sandboxés de s'exécuter directement dans le noyau 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 noyau-espace utilisateur traditionnelles.

Pour le networking, les plugins CNI (Container Network Interface) basés sur eBPF comme Cilium et Calico remplacent activement ou offrent des alternatives supérieures aux approches basées sur iptables. L'avantage principal réside dans le 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 noyau. Cela réduit considérablement la surcharge du CPU et la latence, en particulier dans les clusters Kubernetes à grande échelle.

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 noyau en temps réel. Des outils comme Cilium Hubble tirent parti de eBPF pour surveiller les flux réseau dans Kubernetes, fournissant des informations approfondies sur la communication entre les services, y compris la latence, les octets transférés et les décisions d'application des politiques.

WebAssembly : Un nouveau paradigme pour les charges de travail cloud-native

WebAssembly (Wasm), initialement conçu pour le navigateur, a indéniablement franchi le fossé pour entrer dans les environnements côté serveur et cloud-native, présentant une alternative intéressante aux conteneurs traditionnels pour des cas d'utilisation spécifiques en 2025. Ses principaux avantages – des temps de démarrage ultra-rapides, une empreinte minimale et une sécurité sandbox robuste – en font une option particulièrement attrayante pour les fonctions serverless et le calcul en périphérie. Comme nous le voyons dans l'évolution de Node.js, Deno, Bun en 2025, le paysage d'exécution se diversifie pour répondre à ces exigences de performance.

Les modules Wasm démarrent généralement en quelques millisecondes, un contraste frappant avec les secondes souvent nécessaires pour les démarrages à froid de conteneurs traditionnels. L'intégration de Wasm avec Kubernetes s'effectue principalement par le biais d'exécutions compatibles CRI et de shims. Des projets comme runwasi fournissent un shim containerd qui permet à Kubernetes de planifier des modules Wasm aux côtés des conteneurs Linux traditionnels.

Par exemple, pour exécuter une application Wasm avec crun :

# runtimeclass.yaml
apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: wasm-crun
handler: crun
---
# wasm-app.yaml
apiVersion: v1
kind: Pod
metadata:
  name: wasm-demo
  annotations:
    module.wasm.image/variant: compat
spec:
  runtimeClassName: wasm-crun
  containers:
  - name: my-wasm-app
    image: docker.io/myuser/my-wasm-app:latest
    command: ["/my-wasm-app"]

L'évolution de l'API Kubernetes : Rester en avance sur les dépréciations

Kubernetes affine constamment sa surface d'API pour introduire de nouvelles fonctionnalités et supprimer les fonctionnalités dépréciées. Fin 2024 et 2025, la vigilance face aux dépréciations et suppressions d'API reste une tâche opérationnelle essentielle. Le projet Kubernetes adhère à une politique de dépréciation bien définie pour les API Alpha, Beta et GA.

Les implications sont claires : les développeurs doivent surveiller activement les avertissements de dépréciation. Depuis Kubernetes v1.19, toute requête à une API REST dépréciée renvoie un avertissement. Les outils automatisés et les vérifications des pipelines CI/CD sont essentiels pour identifier les ressources utilisant des API dépréciées.

# Exemple : Trouver les déploiements utilisant l'API extensions/v1beta1 dépréciée
kubectl get deployments.v1.apps -A -o custom-columns="NAMESPACE:.metadata.namespace,NAME:.metadata.name,APIVERSION:.apiVersion" | grep "extensions/v1beta1"

Une planification proactive de la migration, bien avant une fenêtre de mise à niveau, est la seule approche solide pour maintenir la stabilité du cluster. Les versions Kubernetes v1.34 (août 2025) et v1.31 (juillet 2024) contenaient toutes deux des dépréciations et des suppressions qui nécessitaient une attention particulière.

Primitives de sécurité de conteneur améliorées : Au-delà de l'analyse des vulnérabilités

Bien que l'analyse des vulnérabilités reste une bonne pratique fondamentale, les développements récents se concentrent sur le renforcement des primitives de sécurité au niveau de l'exécution. Une avancée significative dans containerd 2.0 est le support amélioré des Espaces noms utilisateur. Cette fonctionnalité permet aux conteneurs de s'exécuter en tant que root à l'intérieur du conteneur, mais d'être mappés à un ID utilisateur (UID) non privilégié sur le système hôte, réduisant considérablement le rayon d'impact d'une évasion de conteneur.

Au-delà des espaces noms utilisateur, l'accent mis sur l'infrastructure immuable et la surveillance de l'exécution s'est intensifié. Les solutions de sécurité d'exécution, souvent tirant parti de eBPF, offrent une visibilité cruciale sur le comportement des conteneurs, détectant les anomalies et les violations de politique en temps réel. De plus, la poussée vers le privilège minimum s'étend aux capacités du conteneur. Les développeurs sont encouragés à supprimer les capacités Linux inutiles (par exemple, CAP_NET_ADMIN) et à appliquer des systèmes de fichiers en lecture seule dans la mesure du possible.

Expérience développeur et affinements des outils

L'amélioration continue des outils de développement, en particulier autour de Docker Desktop et des environnements Kubernetes locaux, a été un thème constant tout au long de 2025. Ces améliorations visent à améliorer la sécurité et à simplifier les flux de travail complexes pour les millions de développeurs qui s'appuient sur ces plateformes.

Docker Desktop a connu un flux constant de correctifs de sécurité traitant des vulnérabilités critiques (par exemple, CVE-2025-9074). Pour le développement Kubernetes local, des outils comme kind et minikube continuent d'évoluer, offrant un provisionnement de cluster plus rapide. L'intégration de BuildKit et Buildx dans les environnements locaux a considérablement amélioré l'efficacité de la construction d'images, en particulier pour ceux qui travaillent avec des cibles multi-architectures.

En essence, l'expérience développeur est devenue plus sécurisée par défaut, avec un accent sur des processus de construction robustes et des correctifs de sécurité continus. Les outils rendent les flux de travail existants plus pratiques, plus sécurisés et plus efficaces, ce qui, pour les développeurs seniors, est souvent le type de progrès le plus précieux.