Containerization 2025: Why containerd 2.0 and eBPF Change Everything

The containerization landscape, perennially dynamic, has seen a flurry of practical, sturdy advancements over late 2024 and through 2025. As senior developers, we're past the "hype cycle" and into the trenches, evaluating features that deliver tangible operational benefits and address real-world constraints. This past year has solidified several trends: a relentless push for enhanced security across the supply chain, fundamental improvements in runtime efficiency, a significant leap in build ergonomics for multi-architecture deployments, and the emergence of WebAssembly as a credible, albeit nascent, alternative for specific workloads. Here's a deep dive into the developments that genuinely matter.

The New Foundation: containerd 2.0 and eBPF

containerd 2.0: The CRI Foundation Re-Hardened

The foundation of our containerized world, the container runtime, has seen significant evolution, most notably with the release of containerd 2.0 in late 2024. This isn't merely an incremental bump; it's a strategic stabilization and enhancement of core capabilities seven years after its 1.0 release. The shift away from dockershim in Kubernetes v1.24 pushed containerd and CRI-O to the forefront, much like how modern CLI tools are redefining the developer experience in 2025.

containerd 2.0 brings several key features to the stable channel that warrant close attention. The Node Resource Interface (NRI) is now enabled by default, providing a powerful extension mechanism for customizing low-level container configurations. This allows for finer-grained control over resource allocation and policy enforcement, akin to mutating admission webhooks but operating directly at the runtime level. Developers can leverage NRI plugins to inject specific runtime configurations or apply custom resource management policies dynamically, a capability that was previously more cumbersome to implement without direct runtime modifications.

Furthermore, containerd 2.0 now supports Image Verifier Plugins. This is genuinely impressive because it allows for policy enforcement about images at image-pull time. Think about it: instead of scanning images only during CI/CD or at deployment, you can now have containerd itself invoke an external plugin (which can be any executable binary or script) to validate an image's integrity or compliance before it's even fully pulled and run. This integrates directly with the transfer service (stabilized in 2.0), although it's noted that the CRI plugin isn't yet fully integrated, so its immediate impact on Kubernetes deployments might be limited until that lands. Still, for direct containerd users, this is a robust step forward for supply chain security at the runtime boundary. On the security front, containerd v2.2.0 also includes fixes for critical vulnerabilities like CVE-2024-25621 and CVE-2025-64329, alongside runc v1.3.3 addressing CVE-2025-31133, CVE-2025-52565, and CVE-2025-52881, showcasing a continuous effort in hardening the core components.

eBPF's Ascendancy: Kernel-Level Control for Networking & Observability

I've been waiting for eBPF to truly hit its stride in the container ecosystem, and late 2024 through 2025 has delivered. The integration of eBPF (extended Berkeley Packet Filter) into Kubernetes networking and observability stacks has moved from an experimental curiosity to a foundational technology. eBPF allows sandboxed programs to run directly within the Linux kernel, triggered by various events, offering unprecedented performance and flexibility without the overhead of traditional kernel-to-user-space context switches.

For networking, eBPF-based Container Network Interface (CNI) plugins like Cilium and Calico are actively replacing or offering superior alternatives to iptables-based approaches. The core advantage lies in efficient packet processing. Instead of traversing complex iptables chains for every packet, eBPF programs can make routing and policy decisions directly at an earlier point in the kernel's network stack. This drastically reduces CPU overhead and latency, especially in large-scale Kubernetes clusters. Projects like Cilium have advanced container networking, replacing iptables with efficient eBPF datapaths, and its graduated status with CNCF and inclusion in projects like OpenTelemetry make it a de facto standard for handling network policies.

Beyond performance, eBPF profoundly enhances observability. By attaching eBPF programs to system calls, network events, and process activities, developers can capture detailed telemetry data directly from the kernel in real-time. This provides granular visibility into container behavior, network flows, and system calls without requiring intrusive sidecar proxies or application instrumentation. For instance, an eBPF program can monitor all network connections initiated by a specific container, detect unusual file access patterns, or trace system calls, offering a powerful tool for both performance debugging and real-time security threat detection.

Modernizing the Build and Dev Workflow

BuildKit 2.0 & Docker Build Cloud: Smarter, Faster, More Secure Builds

If you're still treating docker build as a black box, you're missing out. BuildKit has been the default builder in Docker Engine since version 23.0, and BuildKit 2.0, along with the Docker Build Cloud, represents a significant leap forward in how we construct container images. BuildKit 2.0 isn't just about speed; it's a paradigm shift towards more secure, portable, and intelligently optimized build pipelines.

One of the standout features in BuildKit 2.0 is Federated Caching. Registry-based caching (--cache-from) has always been a bit slow and network-intensive. Federated Caching, however, introduces a peer-to-peer caching mechanism, allowing your build agents to form a distributed cache cluster. When one agent builds a layer, it can be instantly available to others on the same network without a round-trip to a remote registry. This dramatically reduces build times for teams, especially in microservice architectures where base images are frequently rebuilt, turning a coffee break into a quick refresh.

Equally exciting is the introduction of Native WASM Build Steps. Complex RUN commands involving curl, tar, and sed are notorious for creating flaky and insecure builds. BuildKit 2.0 tackles this by allowing WebAssembly (WASM) modules to be used as native build steps. Instead of chaining shell commands, you can use a pre-compiled, sandboxed WASM binary to perform tasks like fetching assets, code generation, or linting. This offers sandboxed execution and improved portability, making your builds more reliable and secure. Furthermore, BuildKit 2.0 deeply integrates with modern security practices, automatically generating SLSA attestations and signing images using Sigstore/Cosign as a native part of the build process.

Complementing BuildKit 2.0, Docker Build Cloud, launched in January 2024, aims to accelerate builds by offloading them to the cloud. This service leverages cloud compute and cache to achieve build times up to 39x faster than local builds. It features native support for multi-architecture builds (AMD64, ARM64) eliminating the need for slow emulation or maintaining multiple native builders. The docker buildx build --platform linux/amd64,linux/arm64 -t myregistry/my-app:latest --push . command makes building for multiple architectures seamless.

Docker Compose v5: Elevating Local Development Workflows

Docker Compose has always been the workhorse for local multi-container development, but the recent evolution, culminating in Compose v5 in December 2025, has made it an even more powerful and integrated tool. The most significant structural change has been the full integration of docker compose (the Go-based implementation) directly into the Docker CLI, officially deprecating the older Python-based docker-compose (with a hyphen).

One of the features I've been waiting for is docker compose watch. This command tracks files and automatically refreshes running containers the moment a file is saved, eliminating the need for manual docker compose up or restart cycles. For a web application developer, this means a tight feedback loop: write-save-view happens in seconds, perfect for iterating on API endpoints or live front-end previews. You can enable this with a simple label in your compose.yml:

services:
  web:
    build: .
    ports:
      - "80:80"
    labels:
      com.docker.compose.watch: "true" # Enables watch mode for this service

Other notable CLI enhancements include docker compose attach for debugging, docker compose stats for live resource usage monitoring, and docker compose cp for easily copying files between the host and a service container. The version field in docker-compose.yml is now completely deprecated; modern Compose files should omit it, starting directly with the services: block. Compose v5 also introduces a new official Go SDK, providing a comprehensive API to integrate Compose functionality directly into applications.

AI/ML and the Evolution of Docker Desktop

Docker Desktop's AI/ML Pivot: Beyond Pure Containerization

Docker Desktop continues to evolve as a comprehensive developer workstation, and its features in 2025 show a distinct pivot towards supporting AI/ML development workflows. Beyond its core function of providing a local Docker Engine and Kubernetes cluster, Docker Desktop is now integrating tools that directly address the pain points of AI developers.

The Model Runner feature, for instance, aims to simplify local LLM execution. Running AI models locally often involves juggling Python environments, CUDA installations, specific model formats, and complex dependencies. Docker's Model Runner abstracts much of this complexity, allowing developers to pull and run models with a simple docker model pull ai/llama3.2:1B-Q8_0 command (as of Docker Desktop 4.40+). This is genuinely impressive because it lowers the barrier to entry for experimenting with large language models and other AI applications, providing a consistent, containerized environment for model execution.

For workloads that outgrow local machine resources, Docker Offload provides a seamless way to run models and containers on cloud GPUs. This frees developers from infrastructure constraints by offloading compute-intensive tasks, such as large language models and multi-agent orchestration, to high-performance cloud environments. Additionally, the MCP Toolkit (for AI agent development) and Docker Debug (for enhanced troubleshooting with slim debug containers) round out Docker Desktop's expanded capabilities, making it a more versatile tool for modern, resource-intensive development.

Hardening the Supply Chain and Data Privacy

Advanced Image Security & Hardened Images

The increasing reliance on open-source components means container images are a primary control point for software supply chain security, and Docker has significantly stepped up its game in 2024-2025. Over 90% of modern applications depend on open source, and container images can include hundreds of dependencies, making the image layer one of the biggest and least visible attack surfaces.

Docker Scout (formerly Docker Scan) is now a central piece of this strategy, offering continuous vulnerability analysis for unlimited Scout-enabled repositories within Docker Team and Business plans. It provides real-time insights into image risk and recommended remediations, integrating seamlessly into the Docker CLI and CI/CD pipelines. This "shift-left" approach is crucial, allowing developers to identify and address vulnerabilities early in the development cycle, preventing insecure images from reaching production.

A particularly impactful development is Docker's decision to make Docker Hardened Images free for everyone. These images provide a secure-by-default foundation, reducing the friction between development speed and security. They come with extended lifecycle support, helping enterprises stay compliant and mitigate end-of-life risks. This move signals Docker's commitment to setting a new standard for the entire container ecosystem, making security a baseline expectation rather than a premium feature.

Confidential Containers: Bringing Trust to Untrusted Environments

For highly sensitive workloads, the concept of Confidential Containers (CoCo) has matured significantly, moving from niche research to practical implementations. CoCo is a CNCF sandbox project that aims to enable cloud-native confidential computing by leveraging Trusted Execution Environments (TEEs) to protect containers and data. This is a game-changer for data privacy, especially in regulated industries or for processing personally identifiable information (PII).

The core idea is to create secure enclaves within a processor, which shield the data being processed from the surrounding environment, including the CPU, hypervisor, and even cloud administrators. Technologies like Intel SGX, Intel TDX, and AMD SEV form the hardware foundation, encrypting container memory and preventing data in memory from being in clear text. This "black box" approach ensures that sensitive workflows are protected from unauthorized access.

The CoCo project's goal is to standardize confidential computing at the container level and simplify its consumption in Kubernetes. This means Kubernetes users can deploy confidential container workloads using familiar workflows and tools, without needing extensive knowledge of the underlying confidential computing technologies. While still in preview for some cloud providers and carrying an inherent performance overhead due to the additional isolation, the ability to achieve a new level of data confidentiality and integrity by preventing data in memory from being readable is a powerful advancement.

The Reality of Wasm and the Road Ahead

The Nuance of Wasm: A Tale of Two Implementations

WebAssembly (Wasm) in the container ecosystem presents an interesting duality. On one hand, BuildKit 2.0's introduction of Native WASM Build Steps is a compelling development for improving build security and portability. Here, Wasm modules are used within the build process to execute specific tasks, offering a sandboxed and efficient alternative to traditional shell scripts. This is a practical and sturdy advancement that addresses real-world issues of build reliability and security.

However, the story for Wasm as a direct container runtime within Docker Desktop appears to be taking a different turn. The Docker Desktop 4.55.0 release notes from December 2025 explicitly state that Wasm workloads will be deprecated and removed in a future Docker Desktop release. This is a crucial reality check. While runwasi exists as a non-core containerd project for a WASM shim, Docker's decision for Desktop suggests that direct Wasm runtime execution might not have met the expected adoption or technical viability for general developer workflows within their Desktop product.

Conclusion: The Road Ahead

What a year it has been! The advancements across Docker, containerd, and Kubernetes in late 2024 and throughout 2025 are nothing short of impressive. We've seen containerd 2.0 solidify its role as the robust, extensible foundation for container runtimes, offering powerful new hooks like NRI and image verifier plugins. The ascent of eBPF has fundamentally reshaped how we think about container networking, observability, and security, pushing kernel-level efficiency and visibility into the mainstream.

For developers, Docker Compose v5 and Docker Desktop's new AI/ML-focused features like Model Runner and Docker Offload demonstrate a commitment to streamlining workflows beyond just basic container management, embracing emerging trends. And perhaps most critically, the relentless focus on supply chain security, exemplified by Docker Scout's continuous analysis and the availability of free Docker Hardened Images, is setting a higher bar for trust in our software artifacts. While some features, like direct Wasm execution in Docker Desktop, face re-evaluation, the overall trajectory is clear: containers are becoming more secure, more performant, and more integrated into the advanced development paradigms of today and tomorrow.