Containerization 2025: Why containerd 2.0 and eBPF are Changing 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 Evolving Container Runtime Landscape: containerd 2.0 and Beyond

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, solidifying the Container Runtime Interface (CRI) as the standard interaction protocol between the kubelet and the underlying runtime.

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. Consider a scenario where an organization needs to enforce specific CPU pinning or memory page allocation for performance-critical workloads; an NRI plugin can now mediate this at container startup, ensuring consistent application across diverse node types without altering the core containerd daemon.

Another notable advancement is the stabilization of image verifier plugins. While the CRI plugin in containerd 2.0 doesn't yet fully integrate with the new transfer service for image pulling, and thus isn't immediately available for Kubernetes workloads, its presence signals a robust future for image policy enforcement at pull-time. These plugins are executable programs that containerd can invoke to determine if an image is permitted to be pulled, offering a critical control point for supply chain security. Once integrated with the CRI, this will allow Kubernetes administrators to define granular policies – for instance, only allowing images signed by specific keys or those with a verified Software Bill of Materials (SBOM) – directly at the node level, before a container even attempts to start. This shifts policy enforcement left, preventing potentially compromised images from ever landing on a node.

The containerd configuration has also seen an update, moving to v3. Migrating existing configurations is a straightforward process using containerd config migrate. While most settings remain compatible, users leveraging the deprecated aufs snapshotter will need to transition to a modern alternative. This forces a necessary cleanup, promoting more performant and maintained storage backends.

Bolstering the Software Supply Chain: Sigstore's Ascent

The year 2025 marks a definitive pivot in container image signing, with Sigstore firmly establishing itself as the open standard for software supply chain security. Docker, recognizing the evolving landscape and the limited adoption of its legacy Docker Content Trust (DCT), began formally retiring DCT (which was based on Notary v1) in August 2025. This move, while requiring migration for a small subset of users, clears the path for a more unified and robust approach to image provenance.

Sigstore addresses the critical need for verifiable supply chain integrity through a suite of tools: Cosign for signing and verifying OCI artifacts, Fulcio as a free, public root Certificate Authority issuing short-lived certificates, and Rekor as a transparency log for all signing events. This trifecta enables "keyless" signing, a significant paradigm shift. Instead of managing long-lived static keys, developers use OIDC tokens from their identity provider (e.g., GitHub, Google) to obtain ephemeral signing certificates from Fulcio. Cosign then uses this certificate to sign the image, and the signature, along with the certificate, is recorded in the immutable Rekor transparency log.

For instance, signing an image with Cosign is remarkably streamlined:

# Authenticate with your OIDC provider
# cosign will often pick this up automatically from environment variables.

# Sign an image (keyless)
cosign sign --yes <your-registry>/<your-image>:<tag>

# Verify an image
cosign verify <your-registry>/<your-image>:<tag>

The --yes flag in cosign sign bypasses interactive prompts, crucial for CI/CD pipelines. The verification step, cosign verify, queries Rekor to ensure the signature's authenticity and integrity, linking it back to a verifiable identity. This provides strong, auditable provenance without the operational overhead of traditional PKI.

Turbocharging Builds with Buildx and BuildKit

Docker's Buildx, powered by the BuildKit backend, has matured into an indispensable tool for any serious container development workflow, particularly for multi-platform image builds and caching strategies. The traditional docker build command, while functional, often suffers from performance bottlenecks and limited cross-architecture support. BuildKit fundamentally re-architects the build process using a Directed Acyclic Graph (DAG) for build operations, enabling parallel execution of independent steps and superior caching mechanisms.

The standout feature, multi-platform builds, is no longer a niche capability but a practical necessity in a world diversifying rapidly into amd64, arm64, and even arm/v7 architectures. Buildx allows a single docker buildx build command to produce a manifest list containing images for multiple target platforms, eliminating the need for separate build environments.

Consider this 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"]

To build for both linux/amd64 and linux/arm64 and push to a registry:

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 .

Performance-wise, BuildKit's caching is superior. Beyond local layer caching, Buildx supports registry caching, where previous build layers pushed to a registry can be leveraged for subsequent builds, significantly reducing build times for frequently updated projects. This is particularly impactful in CI/CD pipelines where build environments are often ephemeral.

eBPF: Redefining Kubernetes Networking and Observability

The integration of eBPF (extended Berkeley Packet Filter) into Kubernetes networking and observability stacks has moved from experimental curiosity to a foundational technology in late 2024 and 2025. 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.

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. Tools like Cilium Hubble leverage eBPF to monitor network flows in Kubernetes, providing deep insights into service-to-service communication, including latency, bytes transferred, and policy enforcement decisions.

WebAssembly: A New Paradigm for Cloud-Native Workloads

WebAssembly (Wasm), initially conceived for the browser, has undeniably crossed the chasm into server-side and cloud-native environments, presenting a compelling alternative to traditional containers for specific use cases in 2025. Its core advantages—blazing fast startup times, minuscule footprint, and strong sandbox security—make it particularly attractive for serverless functions and edge computing. As we see in the evolution of Node.js, Deno, Bun in 2025, the runtime landscape is diversifying to meet these performance demands.

Wasm modules typically start in milliseconds, a stark contrast to the seconds often required for traditional container cold starts. Integrating Wasm with Kubernetes is primarily achieved through CRI-compatible runtimes and shims. Projects like runwasi provide a containerd shim that enables Kubernetes to schedule Wasm modules alongside traditional Linux containers.

For example, to run a Wasm application with 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"]

Kubernetes API Evolution: Staying Ahead of Deprecations

Kubernetes consistently refines its API surface to introduce new capabilities and remove deprecated features. In late 2024 and 2025, vigilance against API deprecations and removals remains a critical operational task. The Kubernetes project adheres to a well-defined deprecation policy across Alpha, Beta, and GA APIs.

The implications are clear: developers must actively monitor deprecation warnings. Since Kubernetes v1.19, any request to a deprecated REST API returns a warning. Automated tooling and CI/CD pipeline checks are essential for identifying resources using deprecated APIs.

# Example: Find deployments using deprecated extensions/v1beta1 API
kubectl get deployments.v1.apps -A -o custom-columns="NAMESPACE:.metadata.namespace,NAME:.metadata.name,APIVERSION:.apiVersion" | grep "extensions/v1beta1"

Proactive migration planning, well before an upgrade window, is the only sturdy approach to maintaining cluster stability. The Kubernetes v1.34 release (August 2025) and v1.31 (July 2024) both included deprecations and removals that required attention.

Enhanced Container Security Primitives: Beyond Image Scanning

While vulnerability scanning remains a fundamental best practice, recent developments focus on bolstering security primitives at the runtime level. A significant advancement in containerd 2.0 is the improved support for User Namespaces. This feature allows containers to run as root inside the container but map to an unprivileged User ID (UID) on the host system, drastically reducing the blast radius of a container escape.

Beyond user namespaces, the emphasis on immutable infrastructure and runtime monitoring has intensified. Runtime security solutions, often leveraging eBPF, provide crucial visibility into container behavior, detecting anomalies and policy violations in real-time. Furthermore, the push for least privilege extends to the container's capabilities. Developers are encouraged to drop unnecessary Linux capabilities (e.g., CAP_NET_ADMIN) and enforce read-only filesystems where possible.

Developer Experience and Tooling Refinements

The continuous refinement of developer tooling, particularly around Docker Desktop and local Kubernetes environments, has been a persistent theme throughout 2025. These improvements focus on enhancing security and simplifying complex workflows for the millions of developers relying on these platforms.

Docker Desktop has seen a steady stream of security patches addressing critical vulnerabilities (e.g., CVE-2025-9074). For local Kubernetes development, tools like kind and minikube continue to evolve, offering faster cluster provisioning. The integration of BuildKit and Buildx into local environments has significantly improved the efficiency of image building, particularly for those working with multi-architecture targets.

In essence, the developer experience has become more secure by default, with an emphasis on robust build processes and continuous security patching. The tools are making existing workflows more practical, secure, and efficient, which for senior developers, is often the most valuable kind of progress.