Docker公司被谁收了?
Docker公司被谁收了?Mirantis。
Mirantis干啥的?
这个公司在国内可能知名不太高，在之前的OpenStack社区挺有名的，也是风云人物。
我们看一下迄今为止，在OpenStack基金会，各个厂商的整体正式代码提交量：
所以说，在OpenStack社区，Mirantis每次都没干的过红帽。
Kubernetes社区呢?红帽代码贡献占到16.5%，前几名没看到Docker公司和MItantis：
在Docker社区呢?红帽还是排在第三，Docker排在第二。红帽在Docker社区的排名没变，份额确实有所下降。
那么，既然很多开源的PaaS方案都是基于Docker做的，那么，Docker公司被此前做OpenStack的MItantis收购，开源社区尴尬不?
一点也不。
红帽也一点都不尴尬!
为什么呢?请看下文。
容器运行时的爱恨情仇
对着下图先说故事脉络：
- 业内最早的容器格运行时是LXC
- Docker最早让容器火起来，Docker最开始用LXC，觉得隔离性差，开发libcontainer，最终形成runC。所以说，runC是Docker的独生子。
- Kubernetes发布时时，发现市面上Docker挺火，因此就用Docker做容器管理工具。
- Docker越做越重，CoreOS做了rkt容器格式(CoreOS被红帽收购了)。rkt与Kubernetes协同工作比较好。
- 容器运行时格式有点多了，Linux基金会主导的开源项目说：我们要做一个container runtime标准。叫OCI。以后容器运行时要符合这个标准。Docker的独生子runC在第一时间符合了OCI标准。
- 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在使用的兼容性和广泛性上将会得到进一步加强。
结论
早在2年多以前，社区和红帽就已经开始讲Kubernetes与Docker解耦了。红帽在OpenShift4中果断放弃的了Docker而使用CRI-O。
所以，Docker公司被收购，开源社区和红帽都不感到尴尬!
