March 1, 2019 at 08:46Mature container runtime: containerd becomes CNCF graduate
We have been following the containerd project from the very beginning . Therefore, we can’t ignore a significant event: last night, the CNCF organization behind Kubernetes and other outstanding Open Source solutions for the cloud native world announced containerd its “graduate”. This project was already the fifth with this status, joining the ranks of K8s, Prometheus, Envoy and CoreDNS.
CNCF, which currently supports dozens of Open Source projects, has adopted three categories for their classification:
In short, the readiness of the project for “release” at CNCF is formulated as its “rapidly growing adaptation, originality, formal management process and a strict commitment to a sustainable and inclusive community”. The containerd , which was transferred by Docker to CNCF almost 2 years ago, is now recognized as meeting these criteria .
The containerd project dates back to the time when the Dockertrees were big. In 2015, its developers announced that it was time to make the Docker Engine more compact (fast, reliable, portable ...), and therefore began to take its components into separate projects .
Everything began with the announcement of an instrument to start runc containers (2015), then appeared runtime containerd for container (2016), and a year later, this initiative has become even more global, and brought us Moby .
Illustration for the release of Docker 1.11 (April 2016): Docker Engine and components removed from it
Back to containerd. In short, its functional role was reduced (and this has not changed to this day) to the fact that, as a daemon on the host system, it managed the entire life cycle of the container: from receiving and storing the image to launching the container (through the already mentioned runc) and controlling his work. In March 2017, a year after the separation of the container, Docker transferred it to CNCF , which happened simultaneously with a similar initiative from CoreOS called rkt (we will return to it) .
Further developments include appearance and development.(led by Red Hat) a Kubernetes-oriented competitor called CRI-O * ... and Docker Inc’s mirror "response" in the form of cri-containerd .
A special (self-titled) daemon was used to interact with K8s in cri-containerd, and by version 1.1 the solution turned into a plug-in for Kubernetes' new container runtime environment - Container Runtime Interface (CRI) - and here the plug-in communicated directly with containerd ( calling the necessary functions).
In June 2018, it was announced that the containerd CRI plugin was ready for production. The current project repository is containerd / cri .
* It is interesting to note that the application filed in November 2018CRI-O - a competitor to containerd and rkt - has not yet been approved by the organization for CNCF projects.
Today containerd indiscreetly calls itself “an executable container environment that is an industry standard and focuses on simplicity, reliability and portability”: The
current architecture of container solutions using containerd (for the most part, of course, they are focused on Kubernetes, but formally they are not limited to this platform ) , it appears as follows:
The solution itself is supplied as a daemon for Linux ( kernel versions 4.x are recommended , although options with earlier versions are possible) and Windows. The source code is written in Go ( version 1.9.x + required ).
The latest release of containerd is 1.2.4 (dated February 14, 2019) , where the vulnerability CVE-2019-5736 in runc was fixed. The next milestone is version 1.3 , where innovations such as container groups , performance optimization for pull operation of images, various improvements in working with snapshotter and others are expected .
The project has 3500+ stars on GitHub, 14 commiters and 166 contributors from companies (except Docker, of course) like Alibaba , Facebook, Google, Huawei , IBM, Microsoft, NTT, Tesla. More codebase statistics can be seen on DevStats .
Amongnotable containerd users, it’s enough to mention Moby and related projects (LinuxKit, BuildKit), Google cloud services (GKE), Microsoft (acs-engine in Azure, and in the future AKS), IBM (IKS, ICP) and Alibaba, container solutions / engines (Rio from Rancher, Kata Containers, Balena), as well as even the recent Firecracker .
Finally, it is worth saying that the pace of development of rkt - an analogue of containerd, included in CNCF at about the same time - is significantly lower. It is enough to indicate that its last release - v1.30.0 - took place almost a year ago (in April 2018).
There are logical conclusions from a business perspective: about a year ago, the original rkt developer, CoreOS, was acquired by Red Hat. And the latter (or it’s more correct to say that now IBM already has ...) , as mentioned in the material, has its own brainchild - cri-o - whose activities are much more active .
However, while the Linux giant has not managed to “get” its project into CNCF, perhaps the words about containerd as an industry standard sound very believable.
Read also in our blog:
CNCF criteria
CNCF, which currently supports dozens of Open Source projects, has adopted three categories for their classification:
- Sandbox (“sandbox”) - for the earliest , experimental, but promising developments that (in the future) “add the value of the CNCF mission”, i.e. will contribute to the development of the Open Source ecosystem and community formed around the infrastructure for modern cloud native applications. There are 12 such projects.
- Incubating (“incubator”) - for projects that have at least three (documented and independent) users in production, within which sufficient (according to the technical committee) quality levels and scales are provided, as well as having an adequate number of contributors with commit bit and stable development of the code base. There are 15 of them.
- Graduation - for projects with committers from at least two organizations, a badge of compliance with the best practices of CII (Core Infrastructure Initiative), adopted by the CNCF Code of Conduct , a clearly defined management and acceptance scheme, a public list of users and, of course, a positive the outcome of the corresponding vote by the CNCF technical committee. Now there are 5 of them.
In short, the readiness of the project for “release” at CNCF is formulated as its “rapidly growing adaptation, originality, formal management process and a strict commitment to a sustainable and inclusive community”. The containerd , which was transferred by Docker to CNCF almost 2 years ago, is now recognized as meeting these criteria .
containerd: origins and present
The containerd project dates back to the time when the Docker
Everything began with the announcement of an instrument to start runc containers (2015), then appeared runtime containerd for container (2016), and a year later, this initiative has become even more global, and brought us Moby .
Illustration for the release of Docker 1.11 (April 2016): Docker Engine and components removed from it
Back to containerd. In short, its functional role was reduced (and this has not changed to this day) to the fact that, as a daemon on the host system, it managed the entire life cycle of the container: from receiving and storing the image to launching the container (through the already mentioned runc) and controlling his work. In March 2017, a year after the separation of the container, Docker transferred it to CNCF , which happened simultaneously with a similar initiative from CoreOS called rkt (we will return to it) .
Further developments include appearance and development.(led by Red Hat) a Kubernetes-oriented competitor called CRI-O * ... and Docker Inc’s mirror "response" in the form of cri-containerd .
A special (self-titled) daemon was used to interact with K8s in cri-containerd, and by version 1.1 the solution turned into a plug-in for Kubernetes' new container runtime environment - Container Runtime Interface (CRI) - and here the plug-in communicated directly with containerd ( calling the necessary functions).
In June 2018, it was announced that the containerd CRI plugin was ready for production. The current project repository is containerd / cri .
* It is interesting to note that the application filed in November 2018CRI-O - a competitor to containerd and rkt - has not yet been approved by the organization for CNCF projects.
Today containerd indiscreetly calls itself “an executable container environment that is an industry standard and focuses on simplicity, reliability and portability”: The
current architecture of container solutions using containerd (for the most part, of course, they are focused on Kubernetes, but formally they are not limited to this platform ) , it appears as follows:
The solution itself is supplied as a daemon for Linux ( kernel versions 4.x are recommended , although options with earlier versions are possible) and Windows. The source code is written in Go ( version 1.9.x + required ).
The latest release of containerd is 1.2.4 (dated February 14, 2019) , where the vulnerability CVE-2019-5736 in runc was fixed. The next milestone is version 1.3 , where innovations such as container groups , performance optimization for pull operation of images, various improvements in working with snapshotter and others are expected .
The project has 3500+ stars on GitHub, 14 commiters and 166 contributors from companies (except Docker, of course) like Alibaba , Facebook, Google, Huawei , IBM, Microsoft, NTT, Tesla. More codebase statistics can be seen on DevStats .
Amongnotable containerd users, it’s enough to mention Moby and related projects (LinuxKit, BuildKit), Google cloud services (GKE), Microsoft (acs-engine in Azure, and in the future AKS), IBM (IKS, ICP) and Alibaba, container solutions / engines (Rio from Rancher, Kata Containers, Balena), as well as even the recent Firecracker .
About competitors
Finally, it is worth saying that the pace of development of rkt - an analogue of containerd, included in CNCF at about the same time - is significantly lower. It is enough to indicate that its last release - v1.30.0 - took place almost a year ago (in April 2018).
There are logical conclusions from a business perspective: about a year ago, the original rkt developer, CoreOS, was acquired by Red Hat. And the latter (or it’s more correct to say that now IBM already has ...) , as mentioned in the material, has its own brainchild - cri-o - whose activities are much more active .
However, while the Linux giant has not managed to “get” its project into CNCF, perhaps the words about containerd as an industry standard sound very believable.
PS
Read also in our blog:
- " Why do we need containerd and why it was separated from Docker ";
- “ What is the essence of the Moby project and why did moby / moby suddenly become the main Docker repository? ";
- “The integration of containerd with Kubernetes, replacing Docker, is ready for production ”;
- “The Past, Present, and Future of Docker and Other Executable Container Environments in Kubernetes ”;
- “ CRI-O is an alternative to Docker for running containers on Kubernetes .”
