Mature container executable environment: containerd has become a graduate of the CNCF
We have been following the containerd project since its inception . Therefore, we cannot ignore a significant event: last night, the CNCF organization behind Kubernetes and other outstanding Open Source solutions for the cloud native world, declared containerd its “graduate”. This project has become 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 brief, the readiness of the project to “release” at CNCF is formulated as its “rapidly growing adaptation, distinctiveness, formal management process and strict adherence to a steadily developing and inclusive community”. From now on, containerd , transmitted by Docker to CNCF almost 2 years ago, is now recognized as meeting these criteria.
The containerd project dates back to a time when 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 make its components into separate projects .
It all started with the announcement of the runc container launch tool (2015), then the executable environment for containerd containers (2016) appeared, and a year later this initiative became even more global and brought us Moby .
Docker 1.11 release release (April 2016): Docker Engine and components derived from it
Let's go back to containerd. In short, his functional role was reduced (and this has not changed to this day) to the fact that he, being a daemon on the host system, 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 container, Docker transferred it to CNCF , which happened simultaneously with a similar initiative from CoreOS called rkt (we will return to it later) .
Further developments include the emergence and development (led by Red Hat) of a Kubernetes-oriented competitor called CRI-O * ... and the mirror “answer” Docker Inc. in the form of cri-containerd .
To interact with K8s in cri-containerd, a special (eponymous) daemon was used, and by version 1.1 the solution turned into a plugin for the new interface for executable container environments in Kubernetes - Container Runtime Interface (CRI) - and here the plugin communicated with containerd directly ( calling the necessary functions).
In June 2018, it was announced that the containerd CRI plugin is ready for production. The current project repository is containerd / cri .
* It is interesting to note that the application for incorporation of competitor containerd and rkt - CRI-O - submitted to the CNCF projects submitted in November 2018 has not yet been approved by the organization.
Today, containerd immodestly calls itself "an executable environment for containers, which is an industry standard and focuses on simplicity, reliability and portability":
The actual architecture of container solutions using containerd (in the mass, of course, focused on Kubernetes, but not formally limited to this platform) , is as follows:
The solution itself comes in the form of a daemon for Linux (kernels of 4.x versions are recommended , although variants 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 (February 14, 2019) , where CVE-2019-5736 vulnerability was fixed in runc. The closest milestone is version 1.3 , where innovations such as container groups , performance optimization for image pull operation, various improvements in work with snapshotter and others are expected.
The project has 3500+ stars on GitHub, 14 committers and 166 contributors from such companies (except Docker, of course) like Alibaba , Facebook, Google, Huawei , IBM, Microsoft, NTT, Tesla. More code base statistics can be seen on DevStats .
Among notable containerd users, it’s enough to mention Moby itself 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), and even the recent Firecracker .
Finally, it should be said that the pace of development of rkt, an analogue of containerd included in the CNCF at about the same time, is significantly inferior. It is enough to point out that its last release - v1.30.0 - took place almost a year ago (in April 2018).
This suggests logical conclusions from a business perspective: about a year ago, the original rkt developer, CoreOS, was absorbed by Red Hat. And the latter (or rather, to say that now IBM ...) , as mentioned in the material, has its own offspring - cri-o, - the activity over which is much more active .
However, while the Linux giant has not managed to “get” its project at CNCF, perhaps the words about containerd as an industry standard sound very likely.
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, which (in the future) “add to the values ​​of the CNCF mission”, i.e. will contribute to the development of open source ecosystems and communities formed around the infrastructure for modern cloud-based (cloud native) applications. There are 12 such projects now.
- Incubating (“incubator”) - for projects that have at least three (documented and independent) users in production, within which sufficient (as estimated by the technical committee) levels of quality and scope, as well as having an adequate number of contributors with a commit bit and stable development of the code base. A total of 15.
- Graduation ("graduates") - for projects with committers from at least two organizations, the Core Infrastructure Initiative CII (Core Infrastructure Initiative) compliance badge adopted by the CNCF Code of Conduct , a clearly defined management and acceptance scheme, a public list of users and, of course, positive the outcome of the relevant voting of the CNCF technical committee. Now there are 5 of them.
In brief, the readiness of the project to “release” at CNCF is formulated as its “rapidly growing adaptation, distinctiveness, formal management process and strict adherence to a steadily developing and inclusive community”. From now on, containerd , transmitted 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 a time when Docker
It all started with the announcement of the runc container launch tool (2015), then the executable environment for containerd containers (2016) appeared, and a year later this initiative became even more global and brought us Moby .
Docker 1.11 release release (April 2016): Docker Engine and components derived from it
Let's go back to containerd. In short, his functional role was reduced (and this has not changed to this day) to the fact that he, being a daemon on the host system, 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 container, Docker transferred it to CNCF , which happened simultaneously with a similar initiative from CoreOS called rkt (we will return to it later) .
Further developments include the emergence and development (led by Red Hat) of a Kubernetes-oriented competitor called CRI-O * ... and the mirror “answer” Docker Inc. in the form of cri-containerd .
To interact with K8s in cri-containerd, a special (eponymous) daemon was used, and by version 1.1 the solution turned into a plugin for the new interface for executable container environments in Kubernetes - Container Runtime Interface (CRI) - and here the plugin communicated with containerd directly ( calling the necessary functions).
In June 2018, it was announced that the containerd CRI plugin is ready for production. The current project repository is containerd / cri .
* It is interesting to note that the application for incorporation of competitor containerd and rkt - CRI-O - submitted to the CNCF projects submitted in November 2018 has not yet been approved by the organization.
Today, containerd immodestly calls itself "an executable environment for containers, which is an industry standard and focuses on simplicity, reliability and portability":
The actual architecture of container solutions using containerd (in the mass, of course, focused on Kubernetes, but not formally limited to this platform) , is as follows:
The solution itself comes in the form of a daemon for Linux (kernels of 4.x versions are recommended , although variants 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 (February 14, 2019) , where CVE-2019-5736 vulnerability was fixed in runc. The closest milestone is version 1.3 , where innovations such as container groups , performance optimization for image pull operation, various improvements in work with snapshotter and others are expected.
The project has 3500+ stars on GitHub, 14 committers and 166 contributors from such companies (except Docker, of course) like Alibaba , Facebook, Google, Huawei , IBM, Microsoft, NTT, Tesla. More code base statistics can be seen on DevStats .
Among notable containerd users, it’s enough to mention Moby itself 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), and even the recent Firecracker .
About competitors
Finally, it should be said that the pace of development of rkt, an analogue of containerd included in the CNCF at about the same time, is significantly inferior. It is enough to point out that its last release - v1.30.0 - took place almost a year ago (in April 2018).
This suggests logical conclusions from a business perspective: about a year ago, the original rkt developer, CoreOS, was absorbed by Red Hat. And the latter (or rather, to say that now IBM ...) , as mentioned in the material, has its own offspring - cri-o, - the activity over which is much more active .
However, while the Linux giant has not managed to “get” its project at CNCF, perhaps the words about containerd as an industry standard sound very likely.
PS
Read also in our blog:
- “ Why do you need containerd and why it was separated from Docker ”;
- “ What is the essence of the Moby project and why the main Docker repository suddenly became moby / moby? ";
- “ Containd integration with Kubernetes, replacing Docker, is ready for production ”;
- “The Past, Present, and Future of Docker and Other Container Executables in Kubernetes ”;
- " CRI-O - Docker alternative to launch containers in Kubernetes ."
Source: https://habr.com/ru/post/442036/
All Articles