Docker company was acquired, the open source community is not embarrassing?
https://news.51cto.com/art/201911/606189.htm
Docker company whom received?
Docker company whom received? Mirantis.
Mirantis of doing?
The well-known company in the country may not be too high, before the OpenStack community quite famous, but also the man of the hour.
We look to date at the OpenStack Foundation, all manufacturers of the overall amount formally submit the code:
So, in the OpenStack community, Mirantis each did not do too Red Hat.
? Kubernetes community code contributions it accounted for 16.5% of Red Hat, the top few companies did not see Docker and MItantis:
Docker in the community do? Or Red Hat came in third, Docker came in second. Red Hat community of Docker ranking has not changed, really share declined.
Well, since a lot of open source PaaS solutions are based on Docker do so, the company was previously Docker do MItantis acquisition of OpenStack, the open source community is not embarrassing?
Not at all.
Red Hat also not a little embarrassed!
Why? See below.
Both good and bad container runtime
The following figure against the first to tell a story context:
- The industry's first container format runtime LXC
- Docker first let container fire up, beginning with Docker LXC, feel isolated and poor, developed libcontainer, eventually forming runC. So, runC Docker is the only son.
- Kubernetes issued from time to time, the market found Docker Tinghuo, and therefore do with Docker container management tools.
- Docker is getting heavy, CoreOS do rkt container format (CoreOS acquired by Red Hat). rkt and Kubernetes work better.
- Container format runtime a bit more, Linux Foundation, the leading open-source project, said: We have to do a standard container runtime. Called OCI. After the container is running to meet this standard. Docker's only son runC the first time in line with the OCI standard.
- Kubernetes为了与容器运行时解耦(主要是Docker)，提出了CRI(Container Runtime Interface)标准。它是一组与Kubernetes与container runtime进行交互的接口。所以说，CRI和OCI并不冲突：Kubernetes定义的是它调用容器运行时的标准接口，OCI定义的是容器运行时本身的标准。
- OCI关于容器运行时的标准提出来以后，红帽想可以专门为Kubernetes做一个轻量级的容器运行时。红帽自然会考虑到它自己全力投入的Kubernetes发布的CRI标准(Kubernetes红帽代码贡献第二)，因此决定重用了runC等基本组件来启动容器， 并实现了一个最小的CRI接口。它叫CRI-O。所以说，CRI-O是CRI的一种标准实现。
- 当Red Hat正在开发其CRI-O，Docker也在研究CRI标准，这导致创建了另一个名为containerd的运行时(实际上是从Docker Engine剥离出来的)。所以新版本的Docker会多一层containerd。Kubernetes将containerd接入到CRI的标准中。即cri-containerd。
由于容器的和Kubernetes的发展史，最终暂时形成如下局面：
从概念上，从PaaS顶层到底层的调用关系是：
Orchestration API ->ContainerEngine API ->Kernel API
现有OpenShift3的调用架构：
- KubernetesMaster->Kubelet->DockerEngine-> containerd -> runc -> Linux Kernel
红帽OpenShift4的调度架构：
- KubernetesMaster->Kubelet-> CRI-O -> runc ->Linux kernel
有一些开发者想用如下的模式：
- KubernetesMaster->Kubelet->CRI-containerd->containerd -> runc ->Linux kernel
总结
- LXC容器运行时基本下课了。runC容器运行时受到大佬们的青睐。
- Docker Engine将下课基本也是事实，这事儿谷歌和红帽联手干的。但Docker急中生智，最终containerd也被Kubernetes社区采纳了。
- rkt与Kubernetes协同工作不错，但与OCI的认证还没测试完。
- 红帽OpenShift目前在全球企业容器市场的占有率超过1/3。Containerd能否火起来，后面也得看Kubernetes社区的态度，但红帽作为企业容器的总瓢把子，肯定是不玩Containerd了。
完整故事
Docker是第一个推广容器的厂商。最初，Docker使用LXC，但其隔离层不完整，因此Docker编写了libcontainer，最终成为runC。随后，Docker成为部署容器的事实标准。在它2014年问世时，Kubernetes自然地使用了Docker，因为Docker是当时唯一可用的运行时。但Docker是一家雄心勃勃的公司，一直致力于开发新功能。例如，Docker Compose与Kubernetes同时达到1.0，两个项目之间存在一些重叠。虽然有很多方法可以使用诸如Kompose之类的工具来使两个工具互操作，但Docker通常被视为一个做太多事情的大项目。这种情况导致CoreOS以rkt的形式发布了一个更简单的独立运行时，这是通过这种方式解释的：rkt的一个创新是通过appc规范标准化镜像格式。rkt的Kubernetes兼容层(rktlet)，没有通过所有Kubernetes集成测试，仍在开发中。
CRI-O
看到这些新标准，红帽认为应该创建一个更简单的运行时，只能做Kubernetes所需要的。那个“skunkworks”项目最终被称为CRI-O并实现了一个最小的CRI接口。
Red Hat负责其OpenShift平台的2016年底启动，该项目也得益于英特尔和SUSE的支持，红帽主持CRI-O开发人员Mrunal Patel主持了此次演讲。CRI-O与CRI(运行时)规范以及OCI和Docker镜像格式兼容。
CRI-O重用了runC等基本组件来启动容器，以及为skopeo项目创建的容器/图像和容器/存储等软件库，以提取容器图像和创建容器文件系统。一个名为oci-runtime-tool的独立库准备容器配置。
containerd：Docker的运行时获取API
当Red Hat正在开发其OCI的实现时，Docker也在研究该标准，这导致创建了另一个名为containerd的运行时。新守护进程是对内部Docker组件的重构，以组合OCI特定的位，如执行，存储和网络接口管理。它已经在1.12 Docker版本中有所体现。虽然我们将containerd称为“运行时”，但它并不直接实现CRI接口，该接口由另一个名为cri-containerd的守护进程覆盖。所以容器需要比Kubernetes的CRI-O更多的守护进程(5个，而CRI-O为三个)。Kubernetes将containerd接入到CRI的标准中。
与CRI-O不同，containerd通过Go API支持Kubernetes生态系统之外的工作负载。尽管containerd定义了一个明确的发布过程，用于更改API和命令行工具，但API尚未被认为是稳定的。与CRI-O一样，containerd功能完备并通过所有Kubernetes测试，但它不与systemd的cgroup互操作。
为了进一步与oci进行兼容，kubernetes还孵化了cri-o，成为了架设在cri和oci之间的一座桥梁。通过这种方式，可以方便更多符合oci标准的容器运行时，接入kubernetes进行集成使用。可以预见到，通过cri-o，kubernetes在使用的兼容性和广泛性上将会得到进一步加强。
结论
As early as in more than two years ago, the community and Red Hat had already started to speak Kubernetes with Docker decoupled. Red Hat OpenShift4 in the Docker's decision to give up the use of CRI-O.
So, Docker was acquired, the open source community and Red Hat are not embarrassed!