Hot on the heels of Docker’s container runtime becoming a Cloud Native Computing Foundation project, CoreOS has also donated its container runtime to the CNCF.
Rkt, aka Rocket, was conceived as the container runtime for CoreOS and its Linux distribution. It was built to stand apart from Docker with better security and a stronger focus, while maintaining cross-compatibility with Docker images.
Earlier this month, CoreOS and Docker elected to submit both rkt and containerd to the CNCF. Now they are official CNCF projects, overseen by a foundation separate from Docker and CoreOS’s business operations (although both companies have members on the CNCF’s boards) and open to contributors regardless of their affiliations.
Now comes a bigger question: With two container runtimes under the CNCF umbrella, could one of them become redundant? Could they merge into a single project designed to address everyone’s needs?
A tale of two runtimes
There has never been a question that Docker and CoreOS embody different design philosophies with their respective projects.
The largest difference: CoreOS set out to design a stack that was secure by default, where Docker opted for all-in-one convenience. Docker’s containerd uses a daemon running as root to launch containers upon receiving commands from a client. CoreOS’s rkt doesn’t use a daemon; it launches containers directly, outside of the root context, and avoids many of the issues Docker has faced with Linux init systems like systemd.
Docker has since addressed many of the most egregious security problems. It was once possible to substitute a benign Docker container image with a malicious one, but they are now protected by image signing. Linux security features like AppArmor better isolate containers from each other. That said, the underlying design philosophy of containerd hasn’t changed.
One overall runtime?
Now that containerd is a CNCF project, its future development could lead away from Docker’s original design. The differences between the two projects could also potentially be reconciled into one meta project.
For those hoping for a single, overarching container runtime—a “containerkt” made from containerd and rkt—do not hold your breath. To start, synthesising a compatible codebase between two fundamentally disparate projects is challenging at best. It’s easier to merge back in a fork made largely out of variations in project management methodology (see: io.js and Node.js), but not when the two were designed along separate lines to begin with.
Also, a merger between two projects that are different by design will only bring headaches to those who have to migrate to it. The two projects were never drop-in replacements for each other, so any merge would become a third path.
Go your own way
For now, containerd and rkt will remain separate projects. The likely future is that they will stake out distinct functions in the container world. When containerd was spun off, Docker indicated it could become raw material for new container-based projects.
Rkt may in time find its own niche, apart from its origins as a CoreOS component. One possible future is for rkt to become more closely aligned with orchestration frameworks like Kubernetes. They already share some DNA; according to the Linux Foundation’s release, rkt “was … a catalyst for the Kubernetes Container Runtime Interface (CRI),” and the container network plug-in system used by Kubernetes is related to rkt.
Both projects could find unique spaces in this ecosystem and deliver above and beyond their respective origins. For them, it will no longer be about where they are from, but where they are and where they are headed.
IDG News Service
Ltd
