containerd just grew up, and honestly it is about time. The graduated CNCF project that quietly runs the containers on your Kubernetes cluster, your Docker host, and probably your company’s entire infrastructure has shipped v2.3.0 — and this one is different. It is the first Long Term Stable release in containerd’s history, meaning enterprises finally have a version they can bet the farm on without wondering if the next minor release will break everything.
containerd is the container runtime that sits between your orchestrator and the actual containers. You have probably heard of Docker — containerd is the engine Docker runs on top of. It handles image management, container lifecycle, storage, and the gritty details of actually getting a process running inside a namespace. If Kubernetes is the conductor, containerd is the entire orchestra.
So why does v2.3.0 matter? Because it is the first LTS release under a new Kubernetes-aligned cadence. New minor releases will now land roughly every four months, and this version will be supported for at least two years. Direct upgrades from 1.7 to 2.3 are tested and supported. That is a massive signal to anyone who has been sitting on the 1.x branch wondering when they could safely move.
But the LTS story is just the headline. The actual release is packed with features that matter for operators, platform engineers, and anyone who has ever debugged a container networking issue at 2 AM.
The Big Story: EROFS Is Now Production-Ready
If you remember only one thing from this release, make it this: containerd v2.3.0 brings EROFS support to production. EROFS (read-only compressed filesystem) is a Linux filesystem designed for immutable data, and it is perfect for container images. Instead of extracting layers to a writable overlay filesystem, containerd can now mount EROFS layers directly, which means faster image pulls, lower memory usage, and stronger integrity guarantees.
This release adds the full stack:
- zstd-wrapped EROFS layers — compressed image layers that mount instantly without extraction. Pull times that used to take minutes now take seconds. PR #13185
- EROFS native container images — the ability to create container images that are EROFS from the ground up, not just mounted as EROFS. PR #13091
- dmverity support — integrity verification for EROFS layers, so you know your image has not been tampered with. PR #12502
- fsmount API — bypasses the PAGE_SIZE limit for EROFS, meaning larger images just work. PR #12783
Think of it this way: every container image you pull today gets extracted to a temporary writable layer before the container starts. That takes time and disk space. With EROFS, containerd mounts the image layer directly, read-only, no extraction needed. It is like going from unpacking a suitcase to opening a door. The clothes are already there.
Observability Gets a Major Upgrade
For anyone who has ever tried to trace a request through a containerized microservices stack, this release is a gift. containerd v2.3.0 brings OpenTelemetry integration directly into the runtime:
- OpenTelemetry trace propagation in outgoing RPCs — trace context now flows from plugin clients through containerd’s internal RPCs. No more blind spots in your distributed tracing. PR #13113
- Trace ID injection into logs — every log line from containerd now carries a trace ID, making it trivially easy to correlate logs with traces. PR #13117
This means when your payment service is slow and you need to figure out whether the bottleneck is in the application, the container runtime, or the network, you can now trace the request all the way down to the container level without any manual instrumentation.
NRI: The Plugin System That Keeps Getting Better
The Node Resource Interface (NRI) is containerd’s plugin framework for node-level resource management. It lets you write plugins that can observe and modify container lifecycle events — think resource quotas, network configuration, GPU allocation, security policies. This release added 18 new NRI features, which is a lot. Let me translate that into plain English:
- Pass container user info (uid, gids) to plugins — plugins now know exactly which user a container runs as. PR #12769
- Pass seccomp policy to plugins — security policies are visible to NRI plugins, enabling coordinated security decisions. PR #12768
- Pass POSIX rlimits to plugins — resource limits are now part of the plugin contract. PR #12765
- Pass CDI devices to plugins — container device interface devices are forwarded to NRI. PR #12767
- Pass Linux sysctl to plugins — kernel parameters are visible to NRI. PR #12766
- Dedicated RPC calls for pod and container lifecycle events — the NRI wire protocol got a complete overhaul with proper RPC calls instead of ad-hoc messaging. containerd/nri#274
- Basic metrics collection for the NRI framework — you can now monitor how your NRI plugins are performing. containerd/nri#277
- Adjust Linux memory policy from NRI plugins — NUMA-aware memory placement is now a plugin concern. containerd/nri#166
- Adjust kernel scheduling policy via NRI — real-time scheduling attributes can be set per-container. containerd/nri#160
- Adjust Linux network devices via NRI — network device configuration is now a plugin concern. containerd/nri#157
That last one is worth repeating: NRI plugins can now adjust network devices. This means you can write a plugin that automatically configures SR-IOV interfaces, sets up VLANs, or applies network policies at container creation time — all without touching the CNI pipeline.
The NRI framework is clearly maturing from an experimental feature into a first-class plugin interface. If you are building custom node-level resource management, this is the place to be.
What Else Is New
Beyond the big stories, here are the changes that matter for day-to-day operations:
- User namespaces with host networking — containers can now use user namespaces even when connected to host network mode. This is a meaningful security improvement for multi-tenant setups where you want process isolation without network isolation. PR #12518
- Hot-reload of pod resources —
UpdatePodSandboxResourcesis now wired to the Sandbox API, meaning you can change CPU/memory limits without restarting the pod. PR #13118 - New shim bootstrap protocol — a new low-level interface for container shims, with a configurable socket directory. PR #12786
- Background stats collector — containerd now calculates
UsageNanoCoresfor containers and pod sandboxes automatically. PR #12629 - Plugin config migration on load — containerd now migrates plugin configurations automatically when it starts, rather than requiring manual intervention. PR #12608
- Filtered cgroups stats API — more efficient resource accounting with the ability to request specific metrics. PR #12901
Here is the thing about containerd: it does not do flashy features. It does not announce itself with press releases. It just quietly makes the infrastructure beneath your applications slightly more reliable, slightly more secure, and slightly faster. And that is exactly why it runs the world.
Bug Fixes
Beneath all the new features, this release also quietly fixed some real pain points:
- Binary logging fix — containerd’s internal binary logging was producing incorrect output in certain edge cases. This has been corrected. PR #13034
- OOMKilled signal handling — containers that were killed by the OOM killer were not consistently reporting the correct exit status to the orchestrator. This is now fixed, so your orchestrator gets accurate termination reasons. PR #12873
Breaking Changes and Deprecations
There are two items operators need to be aware of:
- NRI hook ownership model change — commas are now disallowed in NRI plugin names. If you have plugin names with commas (yes, people actually did this), you will need to rename them. containerd/nri#264
- shim.Command is deprecated — the old shim command interface is being phased out in favor of the new shim bootstrap protocol. PR #13319
What This Means for You
If you are running containerd 1.7 and have been waiting for a signal to upgrade, v2.3.0 is that signal. It is the first LTS release, the upgrade path from 1.7 to 2.3 is tested and supported, and the EROFS feature alone is worth the upgrade for anyone pulling large container images at scale.
If you are already on the 2.x branch, the OpenTelemetry integration and NRI expansion are the features to pay attention to. The observability improvements mean you can finally trace requests through your entire container stack without gaps. The NRI improvements mean your node-level resource management plugins have never been more powerful.
And if you are evaluating containerd for the first time — welcome. The LTS designation means you can use it with confidence in production, knowing there is a two-year support window and a predictable four-month release cadence aligned with Kubernetes.
containerd v2.3.0 is the release that turns a great container runtime into a reliable enterprise platform. And honestly, it is about time.
