CoreOS Joins Docker in Donating a Container Runtime to the Cloud Native Computing Foundation
The ubiquity of a piece of software, in modern times, depends on how thoroughly its creator can give it away. Late Wednesday night, CoreOS, the maker of its distributed container environment, announced in a blog its intention to donate rkt, its core container runtime package, to the Cloud Native Computing Foundation.
CoreOS’ announcement came just hours after Docker Inc.’s announcement to the world on Wednesday morning of its intent to donate containerd, its open source core container runtime package, to CNCF. Both were presented to the CNCF Technical Oversight Committee during its bi-weekly meeting, for consideration of inclusion into CNCF.
CoreOS characterized its effort as “a combined proposal” along with Docker. In a statement to The New Stack Thursday, a spokesperson for Docker Inc. denied the joint nature of CoreOS’ effort though, calling the other company’s move a separate matter which would be voted upon by members of the CNCF in a separate motion.
With containerization having evolved rapidly in the past few years, the lexicon of container technology has struggled to catch up. Veteran New Stack readers may be confused about both containerd and rkt, given that in 2015, runC was being described as Docker’s container runtime, while libcontainer was described as Docker’s “container format and runtime” and appc was referred to as CoreOS’ counterpart to libcontainer.
It’s a mess, and any explanation of the mess that follows it must make way for a bit of a clean-up job.
In the current Docker environment, containerd is a daemon located inside each container, overseeing the execution of, management of, and communications with the container. It communicates with the outside world using gRPC (which itself was donated to CNCF earlier this month), and it delivers commands to what, in an earlier era, would have been called an “executive,” or executor of commands. That element is runC, which indeed was called the “runtime” before its donation to the Open Container Initiative (OCI). Thus runC is the host process for containers that it launches. Although the format of Docker containers had occasionally been mistakenly called “the runC format,” it’s now proper to refer to the “Docker image format” and the “OCI format” (which, for now, slightly differ from one another).
The containerd daemon is an open source component based on Docker’s original model for its container engine. The libcontainer library is Docker’s set of commands for interacting with the containerd interface.
By comparison, appc is CoreOS’ specification for the image format for its containerization system. Earlier documentation referred to appc as specifying both the image format and the container runtime, but later drafts have backed away from that stance. What had been called CoreOS’ “runtime” is now referred to more officially as its “container engine.”
Architecturally, it’s officially called rkt, but pronounced “rocket,” and is the counterpart to Docker’s runC, not Docker’s containerd. What’s more, appc is considered daemon-less, unlike containerd.
Which may make CoreOS’ move late Wednesday even more confusing.
Choice or Else
In a comment to a Hacker News thread Thursday, CNCF Executive Director Dan Kohn acknowledged that he has been working with both CoreOS and Docker Inc., in separate activities geared toward the eventual donation of their components to the Foundation. CNCF participants declined to comment on these matters to The New Stack for the time being, pending internal discussions.
CoreOS Chief Technology Officer Brandon Philips, however, was willing to share his insights with us. First, we asked him about what benefits he foresaw in CNCF developing two container engines that some may perceive as essentially interchangeable.
“Both projects are building against and validating the industry Open Container Initiative (OCI) standards, and both are designed for running containers,” Philips responded. “As two separate implementations with different architecture, they each have different target use cases.”
Philips noted the benefits in giving implementers a choice for “how they want to run their containers, and ultimately, their applications. The solution for one problem doesn’t necessarily fit for another.”
He went on to say that, under the CNCF’s stewardship, the two project’s separate development paths will not only be maintained but ensured, in the interest of diversity. Both projects’ co-existence would give their respective participants, he said, the opportunity to share code, libraries, and collaborative advice.
But Philips did acknowledge one element of the two components’ interchangeability: namely, the requirements of configuration management systems in spinning up containers using one or the other engine. As for any other architectural risks that may be involved, the CTO stated, “There is no risk as both containerd and rkt are using the standards established by the OCI, which ensures a containerized application can run under both. This means application developers can confidently build OCI images, and then infrastructure engineers can pick and choose which container engine to use based on their needs.”
So how would these engineers be expected to make a choice, especially when config management systems perceive both as equivalent?
“They’re not quite treated as equivalent,” Philips responded. “Whereas they will be interchangeable (once OCI 1.0 is released), each implementation emphasizes different aspects of container infrastructure. Architects should properly weigh what’s important to them before making decisions about which container engine to use for their deployments. Rkt’s architecture is a viable choice because it’s comfortable for sysadmins looking to run applications at scale. They understand and appreciate the architectural decisions of rkt, specifically on the security focus with things like VM containers, the daemon-less nature of the tool, and approach to composition through plugins.”
Finally, we asked Philips this: If Kubernetes had a voice like IBM’s Watson, and it could render an opinion on this matter — having been developed by folks with close ties to CoreOS — what comment would he think it would make?
“What Kubernetes would like to see is a stable, easy to upgrade, and community lead container engine that can fulfill the Kubernetes CRI contract,” Philips responded. “Today, rkt comes close to meeting those goals; and placing it into the CNCF, we hope, makes it an even more attractive choice, given its strong progress to achieving full CRI coverage upstream. However, Kubernetes doesn’t have a voice and instead is made up a large community of folks that are trying to make a great project. At the end of the day, CoreOS just wants to see Kubernetes be successful with a great container runtime to support it.”
Or Not to Donate (That Is the Question)
While a CNCF spokesperson did confirm to The New Stack that separate votes will be taken on the containerd and rkt contributions, moving these submissions to a vote may require a trip through the legal weeds. In his Hacker News message, the CNCF’s Kohn affirmed that both projects’ rights holders must divulge their respective trademarks, and agreed that the transactions may need to be legally referred to as “contributions” rather than “donations.”
“But it all a very open-source-oriented, metaphysical concept,” wrote Kohn, “in that by giving up some control over a project, the company that originated it is hopefully going to bring in many more contributors and ultimately increase both the total value of the project and the value to them.”
Another participant disagreed, saying that because neither Docker nor CoreOS expects reciprocation for their transaction, “donation” is a more fitting term. The issue may be more than semantics: It’s commonly held that a proprietary technology may be dependent upon open source components without becoming non-proprietary (otherwise, everything that uses SSL would suddenly be free). But in the past, Docker contributors have raised the case that evolutions of the OCI format that diverge from Docker’s earlier methodology, may be unfair to Docker, or at least to people using Docker.
OCI contributor Timothy Hobbs brought up this earlier dispute in the Hacker News thread, as evidence that such metaphysical disputes could indeed happen. His opinion prompted Docker Inc. engineer Justin Cormack to state that, technically, Docker did not, despite claims of the time, donate its container image specification to OCI. Rather, he said, “Various people decided to make a spec for roughly what Docker was doing already, to formalize it, with an agreement to do a 1.0 quickly. It was not a standard to create an all new spec, at least initially. There are a lot of existing images out there, so incremental change and backward compatibility are important.”
Title image of Team Great Britain sweeping to knock off Team Sweden’s guard rock in women’s curling, at the 2010 Winter Olympics in Vancouver, by Jonathan Pope, licensed under Creative Commons.
The Cloud Native Computing Foundation and CoreOS are sponsors of The New Stack.
