Today CoreOS and Docker made a combined proposal to add rkt and containerd as new projects for inclusion in the Cloud Native Computing Foundation (CNCF). During today's CNCF Technical Oversight Board meeting, Jonathan Boulle, a rkt project lead and co-founder, proposed rkt and Michael Crosby, a containerd project lead and co-founder proposed containerd. These proposals are the first step towards these new projects alongside other critical projects like gRPC, Kubernetes, Prometheus, and many others. By donating these projects to the CNCF we ensure that the container community will continue to thrive in a neutral home for collaboration.
Container execution is a critical pillar of cloud native, and we believe rkt will continue to advance and grow with the stewardship of the CNCF community. With a diverse set of 180 contributors, rkt has helped establish and push forward necessary conversations about container security, composability and interoperability. Today there is a segment of the industry devoted to container security, and organizations such as the CNCF help foster the conversations that will ultimately lead more companies to adopt, contribute and benefit from cloud native infrastructure.
We look forward to working with the rkt and CNCF community on the next steps over the coming days and weeks. If you're interested in staying in touch with the latest updates, you can subscribe to this mailing list.
Why rkt in the CNCF?
A pillar of cloud native computing is packaging applications as container images and distributing those images to servers. On the server, a container engine then downloads the image, verifies the image integrity, and executes the container process. Ideally, the container engine does this in the simplest possible manner while meeting the expectations of the production cloud native user. The rkt tool is laser focused on solving these problems and has excited the market, leading to various integrations in cloud native orchestration systems like Kubernetes, Mesos, Nomad, and many organization's bespoke systems.
Since its introduction by CoreOS in December 2014, the rkt project has greatly matured and is widely used. It is available for most major Linux distributions and every rkt release builds self-contained rpm/deb packages that users can install. These packages are also available as part of the Kubernetes repository to enable testing of the rkt + Kubernetes integration. rkt also plays a central role in how Google Container Image and CoreOS Container Linux.
Further, rkt has contributed indirectly to the creation of several important new APIs, specifications, and discussions in the container ecosystem. The container network plugin system used by Mesos, Kubernetes, rkt, and others called CNI comes directly from the rkt plugin system and has become a multi-organization effort. The team working on rkt also created appc, the App Container Spec, which kicked off an industry discussion on container standards which lead to the OCI, the Open Container Initiative. The ongoing effort to make Kubernetes a multi-container runtime system began with the early "rktnetes" work which has culminated in the creation of a Container Runtime Interface API inside of Kubernetes. In all of these cases the rkt project has been a catalyst for shared ecosystem collaboration.
To sum up, container execution is a core part of cloud-native. By proposing to house rkt under the CNCF, we see these benefits:
- This is a neutral, respected home for the project
- Additional help with community building and engagement
- Fostering interoperability with Kubernetes, OCI, containerd
rkt today and in the future
Thank you to the community for getting rkt to where it is today. Companies like BlaBlaCar, a popular European car sharing service that is using rkt in production and moving to Kubernetes, discussed their use of rkt in production, and others in the community have said:
Continue using rkt and share your feedback and stories about how you are using it. Add your pull requests on our rkt users and integrations doc pages.
FAQ
Q What does this mean today?
Now that rkt and containerd have been proposed, the next step is for a CNCF TOC member to sponsor and propose the project for inclusion. Once that happens, the projects go up for a formal proposal, and up for a vote in the next few weeks.
For the team working on rkt specifically, not much will change. All of the other rkt maintainers will continue working on the project as usual. And, we hope, we can encourage new users, and maintainers, with the help of the CNCF, to contribute to and rely on rkt.
Q: What’s the difference between containerd and rkt?
Rkt is able to download, verify, and set up a container images; and containerd will do this as well. Further, both projects consume OCI Images and Docker Images.
A major difference is that rkt, as a daemonless tool, can be used to integrate and execute specialized containers that are critical for use in production systems. For example, CoreOS Container Linux uses rkt to execute the Kubernetes agent, the kubelet, as a container image. Further examples include the experiments to use rkt as a way of mounting volumes in a containerized way in the Kubernetes ecosystem. It also means that rkt can be integrated and used with Linux init systems as rkt itself is not an init system.
Q: What does this mean for developers building containers?
For developers building containers nothing changes as the goal of both containerd and rkt will be for users to be able to execute their existing OCI Images and Docker Images.
For the community of infrastructure experts deploying containers into production it means that the rkt team and project will continue its mission to create a simple, composable, and production ready containerization system under a neutral foundation as part of the CNCF.
We are also eager to see acceleration in the rkt project's collaboration with other CNCF ecosystem projects like Kubernetes and Prometheus.
Q: Will these container engines all be available via the Kubernetes CRI?
CoreOS helped establish a standard interface, called the Kubernetes Container Runtime Interface (CRI), which enables Kubernetes to use a selection of pluggable container runtime engines. Rkt is already available for use via the CRI (see the minikube usage notes for an example invocation.