Containerd enters the CNCF with its runtime work still underway

A runtime shared by competing container platforms needs a development process those platforms can influence. Docker can publish reusable code while still deciding its priorities as a product vendor. Moving containerd into the Cloud Native Computing Foundation addresses the second question, which is who helps determine the direction of that shared code. The decision changes the institutional relationship around a component that Docker users already depend on.

The CNCF announcement of 29 March says its Technical Oversight Committee has accepted containerd as an incubating project. This follows Docker's December commitment to contribute the runtime to a neutral foundation. Acceptance completes that particular governance step. It does not mean that every part of the expanded runtime has reached its intended implementation or compatibility milestone.

I value Docker's ability to package an environment and make it transferable. A shared execution component is consistent with that strength because the artifact should not depend on a single application platform owning all the code beneath it. The useful question is how much common execution machinery different platforms can reuse while keeping their own deployment policies.

The foundation decision follows an existing separation

Docker's December announcement described containerd as an existing component that would gain additional responsibilities. Containerd had shipped within Docker since Engine 1.11 in April 2016. The proposed expansion included image distribution and local storage alongside execution and supervision. Foundation membership therefore concerns an established dependency whose scope is changing.

That history explains why a governance announcement has immediate relevance even though the expanded implementation remains under development. A component can already carry production responsibility inside one product while its independent interface and integration model continue to evolve. Consumers considering direct integration need both kinds of information. Existing use establishes that there is working code, while the development plan explains what callers should expect to change.

The CNCF announcement calls containerd an essential upstream component of Docker and a base for building other container products. Those roles impose different integration pressures. Docker already has surrounding code that prepares and manages images. Another platform may need containerd to supply more of that work before it can adopt the component without duplicating the same implementation.

Separating these roles also avoids treating the Docker command line as the runtime's defining interface. Application developers can continue using an integrated product. Platform builders need a programmatic interface for the local container operations they embed. The donation makes sense because these consumers can share implementation work without agreeing on every user-facing command or deployment model.

Execution and orchestration have different responsibilities

The announcement describes image transfer, container execution and supervision, and low-level local storage across Linux and Windows. These are responsibilities close to a machine executing a workload. Deciding where a distributed application's workloads should run remains a separate concern for the platform that calls the runtime.

This division matters when interpreting Kubernetes' relationship to the project. CNCF notes that Kubernetes 1.5 runs with Docker versions 1.10.3 through 1.12.3. Containerd is already part of the relevant Docker execution path in versions that contain it. That relationship does not establish that Kubernetes has suddenly replaced its Docker integration with a completed direct containerd integration.

A direct integration needs agreement about the operations and representations that cross the interface. Having the runtime and the orchestrator in the same foundation can help that discussion, but foundation membership does not implement an adapter. The announcement links a summit presentation on containerd and the Container Runtime Interface, which indicates the integration question being discussed.

The distinction is useful beyond Kubernetes. A platform may have its own scheduling policy, application model and operational tooling. Reusing local image and execution management reduces the code it must maintain without requiring it to adopt another platform's scheduling choices. The runtime becomes useful to competing systems because it has a scope below those choices.

Existing interfaces show what callers actually supply

The protocol used by Docker's 1.12.3 containerd dependency provides a concrete view of the earlier execution interface. A create request supplies an identifier and bundle path. Standard input and output use caller-supplied paths, and the protocol includes methods for signals, additional processes and state inspection.

This interface assumes work has already happened before creation. A bundle path identifies local material prepared for execution. Supplying it is different from asking the daemon to obtain an image from a registry and turn that image into the filesystem for a new container. The expanded project is taking on more of that preparation work so that callers can share it as well.

Events are another part of the interface that matters to an orchestrator. The protocol streams events containing container and process identifiers with timestamps. A caller supervising workloads needs to relate its intended state to observed process state. An execution API limited to submitting a create operation would leave that continuing responsibility without the corresponding information.

These details describe the earlier interface, not a promise that the planned 1.0 API will preserve every field. They show why reusable runtime work includes more than invoking a low-level executor. The component has to give its caller a way to identify processes, observe their state and manage their lifecycle after the initial request.

The protocol also distinguishes a container identifier from the identifier of a process within that container. An additional-process request names the existing container and describes the new process, including its arguments and working directory. That distinction gives callers a model for managing activity inside a container after its initial process has started. A reusable supervisor needs to represent those operations as well as initial container creation.

Adjacent projects provide concrete integration points

CNCF identifies gRPC as containerd's API technology and Prometheus format as its metrics interface. Both projects are also part of the foundation. These are specific technical relationships that make cross-project collaboration useful. An application platform can interact with container execution through an RPC interface and observe the component through a metrics format it may already consume elsewhere.

Neither choice supplies the platform's operational policy. Metrics expose information that a monitoring system must interpret. An RPC interface defines callable operations that a scheduler or host agent must use correctly. Sharing those mechanisms lowers integration work while leaving responsibility for application behavior with the consuming system.

The announcement also connects containerd to the Open Container Initiative's runtime and image-format work and the runC implementation. OCI specifications and CNCF project hosting address different needs. Specifications describe compatible representations and behavior. A hosted implementation gives contributors a place to maintain software that uses those specifications.

I find this separation of responsibilities persuasive because it keeps image portability and runtime implementation related without making them identical. A documented format alone does not provide a maintained daemon. A maintained daemon alone does not establish that another implementation can consume the same artifact. Containerd can participate in both relationships while still being one project with a defined scope.

Contributor participation has engineering consequences

The announcement reports a February summit involving more than fifty community participants, including engineers from cloud providers and other container companies. Its development account says the team has been implementing the first two phases of the roadmap. These details matter because neutral hosting needs people doing design and implementation work across company boundaries.

The project also exposes its progress through weekly development reports. For a prospective integrator, that creates a way to assess the work between a public announcement and a release. A roadmap states intended scope, while development reports show which parts contributors are working through. Those are different kinds of evidence about when an integration dependency may be usable.

CNCF gives June as the target for completing the containerd 1.0 roadmap. That date is a plan as of this announcement. The foundation decision should not convert it into a statement that the work has already shipped, or that every consumer will adopt the result on that schedule. Each consuming platform still has its own integration and release decisions.

Today's concrete result is that containerd has an accepted place in CNCF at the incubating stage. Docker remains an important consumer, while the expanded runtime continues to acquire the image and storage responsibilities intended for other platforms too. The immediate engineering opportunity is to participate in those common interfaces while they are under active development, with the foundation providing a shared organizational home for that work.