Docker公司被收购,开源界尴尬不?


Docker公司被谁收了?

Docker公司被谁收了?Mirantis。

Mirantis干啥的?

这个公司在国内可能知名不太高,在之前的OpenStack社区挺有名的,也是风云人物。

我们看一下迄今为止,在OpenStack基金会,各个厂商的整体正式代码提交量:
1.jpg

所以说,在OpenStack社区,Mirantis每次都没干的过红帽。

Kubernetes社区呢?红帽代码贡献占到16.5%,前几名没看到Docker公司和MItantis:
2.jpg

在Docker社区呢?红帽还是排在第三,Docker排在第二。红帽在Docker社区的排名没变,份额确实有所下降。
3.png

那么,既然很多开源的PaaS方案都是基于Docker做的,那么,Docker公司被此前做OpenStack的MItantis收购,开源社区尴尬不?

一点也不。

红帽也一点都不尴尬!

为什么呢?请看下文。

容器运行时的爱恨情仇

对着下图先说故事脉络:
4.png

  1. 业内最早的容器格运行时是LXC
  2. Docker最早让容器火起来,Docker最开始用LXC,觉得隔离性差,开发libcontainer,最终形成runC。所以说,runC是Docker的独生子。
  3. Kubernetes发布时时,发现市面上Docker挺火,因此就用Docker做容器管理工具。
  4. Docker越做越重,CoreOS做了rkt容器格式(CoreOS被红帽收购了)。rkt与Kubernetes协同工作比较好。
  5. 容器运行时格式有点多了,Linux基金会主导的开源项目说:我们要做一个container runtime标准。叫OCI。以后容器运行时要符合这个标准。Docker的独生子runC在第一时间符合了OCI标准。
  6. Kubernetes为了与容器运行时解耦(主要是Docker),提出了CRI(Container Runtime Interface)标准。它是一组与Kubernetes与container runtime进行交互的接口。所以说,CRI和OCI并不冲突:Kubernetes定义的是它调用容器运行时的标准接口,OCI定义的是容器运行时本身的标准。
  7. OCI关于容器运行时的标准提出来以后,红帽想可以专门为Kubernetes做一个轻量级的容器运行时。红帽自然会考虑到它自己全力投入的Kubernetes发布的CRI标准(Kubernetes红帽代码贡献第二),因此决定重用了runC等基本组件来启动容器, 并实现了一个最小的CRI接口。它叫CRI-O。所以说,CRI-O是CRI的一种标准实现。
  8. 当Red Hat正在开发其CRI-O,Docker也在研究CRI标准,这导致创建了另一个名为containerd的运行时(实际上是从Docker Engine剥离出来的)。所以新版本的Docker会多一层containerd。Kubernetes将containerd接入到CRI的标准中。即cri-containerd。


由于容器的和Kubernetes的发展史,最终暂时形成如下局面:
5.png

从概念上,从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

总结

  1. LXC容器运行时基本下课了。runC容器运行时受到大佬们的青睐。
  2. Docker Engine将下课基本也是事实,这事儿谷歌和红帽联手干的。但Docker急中生智,最终containerd也被Kubernetes社区采纳了。
  3. rkt与Kubernetes协同工作不错,但与OCI的认证还没测试完。
  4. 红帽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的标准中。
6.png

与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公司被收购,开源社区和红帽都不感到尴尬!

原文链接:https://mp.weixin.qq.com/s/BPBUi5L2PcBSNdAB7WZ2qQ

0 个评论

要回复文章请先登录注册