CNCF Accepts Both Docker’s containerd and CoreOS’ rkt as Incubation Projects
In a unanimous voting process that concluded Wednesday during KubeCon in Berlin, The Cloud Native Computing Foundation’s Technical Oversight Committee approved Docker Inc.’s motion to donate containerd — the current incarnation of its core container runtime — as an official CNCF incubation project. In the same meeting, the TOC also voted unanimously to adopt CoreOS’ rkt container runtime, as well.
“Container orchestrators need community-driven container runtimes,” reads a formal statement from CNCF Executive Director Dan Kohn Wednesday, “and we are excited to have containerd which is used today by everyone running Docker. Becoming a part of CNCF unlocks new opportunities for broader collaboration within the ecosystem.”
As of now, the engine that very likely empowers a majority of the world’s virtual workload containers is no longer owned by Docker, but is instead governed by an independent body whose membership includes Docker.
That Docker Inc. had an interest in donating containerd to an outside organization has not been a secret. During a Docker-hosted gathering of developers around containerd in San Francisco a month ago, the company acknowledged the likelihood of such a transaction taking place. And as recently as two weeks ago, CNCF TOC member and Docker Chief Technology Officer Solomon Hykes told the CNCF it was his company’s intention to effectively divest itself of what exclusive rights it has to the software, but had not decided how.
“The intention is to move to a github org that 1) is not Docker-branded and 2) is controlled by Linux Foundation [sic],” Hykes wrote at that time.
Hykes also announced Docker’s intention to donate “other projects,” without naming names. The only slight resistance Hykes received came momentarily from Kohn, who explained that while his group would be happy to host further projects created by Docker, there may be no direct benefit for it to donate all of them to the same foundation.
Besides that note of advisement, there were no objections to Docker’s move, including from CoreOS developer Jonathan Boulle. Among non-binding voters contributed by the community at large, there was unanimity in Docker’s favor as well.
Although the donation gestures were not joint or combined between Docker and CoreOS — as Docker Inc. informed The New Stack earlier this month — CNCF members did learn about both voting dockets through the same mailing list message.
Documentation posted to GitHub Wednesday takes steps to differentiate rkt from containerd, making it clearer to newcomers to the project that the two components are actually not interchangeable, even though they’ve both been called “container runtimes.” rkt is daemon-less, the documentation noted, and thus relying on systemd for their bootstrap, unlike Docker’s containerd.
“In keeping with the opinionated and scoped nature of the project,” the CNCF documentation goes on, “rkt does not include any native workflows for building container images, but is rather expected to be used in conjunction with build systems such as the Dockerfile, acbuild, or box projects.”
Whither CRI-O
One issue for the CNCF Kubernetes container orchestrator developers among the CNCF — if not now, then very soon — will be how they intend to proceed with their Container Runtime Interface (CRI) project. Its intent, as Google Engineering Manager and Kubernetes lead developer Tim Hockin pointed out during Docker’s in-house summit last month, is to enable a variety of container runtimes to become pluggable into Kubernetes. Now, CNCF is the steward of a majority of that variety.
Hockin expressed his continued reservations about his team’s decision to build CRI on top of Docker Engine. Among them, he said, “the chain of calls to make a container is pretty staggering,” diagramming four hops from a kubelet to the runc component. If something goes wrong along each of those hops, he warned, it would be difficult to trace. And when Docker makes a change to its engine, he added, “it becomes a bigger and bigger task for us to qualify new versions of Docker, which break in new and interesting ways, or just introduce new, very subtle incompatibilities, and those don’t bring us any value.”
This had been the inspiration for the CRI-O project — an effort to build a runc-based, run-only container runtime that would enable Kubernetes to run containers that were already built. But for this conference, Hockin suggested instead a switch to direct support for containerd.
“It seems to be a much better fit, a much lower-level primitive than what Docker’s giving us through the Docker API,” Hockin explained, “which is exactly what we need. Honestly, containerd could not have been designed better for what we want out of Kubernetes.”
So it would appear that Wednesday’s completed transaction presents the gift to Hockin and his colleagues that CRI-O would have presented, had the status quo remained the status quo (which it never does). Just last weekend, a proof-of-concept package for integrating containerd directly with Kubernetes, was posted to GitHub.
Hockin tweeted the existence of the POC project, and then soon afterward followed up with this note: “In a truly open open project, nobody can make you important, except yourself. Only you can make you important.”
⚡️ “CNCF Project Updates” from #Kubecon #CloudNativeCon https://t.co/FwH4Ozo5Xd
— The New Stack (@thenewstack) March 28, 2017
The Cloud Native Computing Foundation and CoreOS are sponsors of The New Stack.
Feature image via Pixabay.
