Moby(Docker)社区

Docker在17年4月的时候推出了名为Moby项目,Moby着眼于“一个将组件装配成定制化基于容器的系统的框架和一个所有容器发烧友试验与交流想法的场所”,它内部除了Docker 容器引擎外，还孵化了多个项目：Moby,buildkit，Datakit，HyperKit，VpnKit。Docker对Moby的玩法，就是从Moby中抽取Docker版本，然后将其他孵化项目中比较成熟的部分纳入到Docker里。其中BuildKit就是一个成功孵化并进入Docker的例子。

发布Moby之后Docker-ce（docker的开源版本）发布采用两种方式，Stable版本和edge版本。Stable版本顾名思义为稳定版本，而两次Stable版本之间一月发一次Edge版本，一般的商用选择都是Stable版本。

截止到18年上半年之前，Docker版本的发布采用3个月左右为周期进行发布。这样导致了上游社区特别是K8s社区对接上的麻烦，为了减少Docker用户频繁的更新版本，Docker在18年Q4调整了版本发布计划，从Docker 18.09开始，Docker版本保证6个月左右的版本维护期，中间不再发布Edge版本，下一个版本是Docker-CE 19.03

Moby社区在过去的18年发布了如下Docker-ce stable版本：

容器社区2018年度发展历程第2张

Docker（Moby）近期最大的变化实际发生在17年11月的Docker-ce 17.11，对应的Stable版本为18年2月出现的Docker-ce 17.12 在这两个版本中Docker使用的Containerd从Containerd0.2.x一跃升级为Containerd 1.x。Containerd 0.2.x和Containerd1.x之间API级不兼容，且架构发生重大变更。由此引发了Docker-ce架构的巨大变更。这是Docker社区在17年底到18年发生的重大的变更项。

2014 年开始，Docker 和 Microsoft 便积极展开合作，在 2016 年，先让 Windows Server 整合了 Docker 引擎。到 2017 年，整合了 Windows 容器，让 Docker 能一次通吃 Linux、Windows 容器集群。在18年1月份，发布了Docker Desktop 的Deta版本，在其上在可以部署kubernete集群了，在Docker con旧金山大会上，Docker公司正式对外展示了Docker Desktop-Windows部署kubernete集群。

我们可以看到在18年度，Moby社区有大量Microsoft贡献者在活跃，在18年的所有Docker发布版本中可以看到大量Windows容器的特性和Bug修正。

其中最大的突破出现在18年，Docker Desktop和Docker-ce原本就是两个独立的产品。但是在Docker-ce18.09之前Docker Desktop采用Docker-CE的版本号，例如18年8月推出了18.06.1-ce-win73 。但是在Docker-ce 18.09时刻，Docker Desktop正式采用了自己独立的版本为2.0.0.0;其中引擎部分还是采用的Docker-ce 18.09

Containerd社区

Containerd是Docker从16年12月推出的一个子项目，它将Docker引擎中的containerd捐献到社区中，由此出现了一个Containerd社区。Containerd的目标是开发遵循OCI规范的商用环境容器运行时。

containerd并不是直接面向最终用户的，而是设计为被用于集成到更上层的系统里，如Swarm， Kubernetes， Mesos等容器编排系统。它利用已有的runtime，对容器生命期管理、容器镜像和容器存储上做出更多工作；而容器网络和编排交给了Docker引擎、Kubernetes等编排系统。

Containerd社区在18年发生的大事件有：

18年7月发布Containerd1.1.2正式将CRI-containerd以插件形式cri-plugion集成到了Containerd中。理论上来说，从此刻开始Containerd就可以独立支持Kubelete CRI了。
18年9月Containerd1.2.rc0出现，它实现为支持VM类型的容器，提供了shimv2抽象。而Containerd 1.2在19年1月15日才正式发布。Containerd 1.2的出现标志着Containerd对VM容器（Kata容器，runV容器）的支持上了一个新台阶。

Containerd的发布时就定位成容器编排工具的底层运行时，也就意味着Containerd可以被多种编排工具调用，一同提供容器服务。现阶段有Docker，阿里的Pouch这两个容器引擎使用Containerd作为自己的运行时。Kubernete从1.7开始使用cri-containerd的方式支持kubelete使用containerd；而Kubelete 1.10以上的版本就支持了直调containerd（通过containerd的cri-plugin）。在Kubelete直接使用containerd商用尝试上，谷歌走在了前列。在18年11月，它在自家公有云下kubenete服务GKE 1.1上宣布提供beta方式的支持kubelete直调containerd。

rkt社区

rkt（Rocket）是由前coreOS公司在14年底推出的容器引擎，rkt推出的初衷是因为当时Docker引入了Docker swarm编排工具，向着Docker平台化的方向大步前行。coreOS认为Docker的设计理念偏离。所哟coreOS推出了自己的容器引擎Rocket（在15年更名为rkt）。rkt的设计目标就是纯粹的容器引擎，它不提供容器平台，不提供容器的编排。rkt从14年底推出0.0.0到18年4月11日推出最后一个版本1.30一共推出了46个版本。在rkt的github社区上列出了几个商用客户，由于不知所以本文就不再列出。

rtk和kubenete的集成出现在kubenete1.3版本，也就是因为rkt这一类容器的出现才促使kubenete社区在16年底kubenete1.5时刻推出的自己容器运行时标准接口CRI。在17年kubenete社区孵化了rkt的cri接口层rktlet，至今为止它只在17年11月推出了一个版本0.1.0。这个版本只通过了部分kubenete 1.9 e2e测试用例。

rkt和rktlet社区都以coreOS公司为主导。18年发生了一个大事件，导致了rkt实际死亡，那就是18年1月红帽收购了coreOS。由于红帽早已大力主推自己的容器运行时项目CRI-O，所以rkt项目的实际运作在18年4月份中止了，rkt和rktlet的最后更新都停止在了18年4月。可以认为红帽将coreOS rkt资源投入到了CRI-O中。

gvisor社区

在18年5月，谷歌推出了一种全新的沙盒式容器运行时gvisor。gvisor它是一个支持OCI规范的容器运行时。它能够为容器提供更安全的隔离，同时比VM更轻量。gvisor的设计者认为现在的容器使用了用户态隔离而内核却是共用的，虽然使用seccomp，selinux和Appamor在控制了潜在的安全风险。但是传统容器中恶意应用依然存在逃逸的可能性。针对这样的安全风险，VM容器可以实现基于虚拟化层的强隔离；但是VM容器也引入了不小的虚拟化层开销——更多的cpu、内存消耗。而gvisor使用了类似于用户态Linux的方式，在内核和容器之间引入的新的linux系统调用隔离层将所有的容器内部发起的系统调用进行截击并重新实现。

容器社区2018年度发展历程第3张

gvisor架构图

gvisor现在由两种系统调用截击方案：

ptrace方案
kvm方案

ptrace方案可以应用于任何宿主机包括云主机环境上，它采用ptrace方式，在容器内部应用发起系统调用的时刻将应用跳转到自己实现的系统调用代码中。ptrace模式的工作模式类似于使用gdb调试用户态进程的方式。此外gvisor还支持kvm方式，在 KVM 模式下，gVisor 能够截获应用程序的每个系统调用，并将其转交给 gvisor自己实现的系统调用层进行处理。相比较 VM，我们看不到 Qemu 的身影，也看不到 Guest Kernel，gvisor自己实现的系统调用层包揽了所有必要的操作。这种对虚拟化的实现方法，我们称之为“进程级虚拟化”。gvisor只实现了部分的系统调用：实现了 200 个左右的系统调用，而 Linux Kernel 则为 X86_64 提供了 318 个系统调用。所以现在部分软件还不支持gvisor，例如postgel。而且现阶段gvisor实现的部分系统调用依然依赖于宿主机上的内核系统调用。

对于容器网络，gvisor实现了用户态网络协议栈。其整个数据流跟原生容器一样，唯一区别在于 gVisor 需要捕获到安全容器内应用程序关于网络的系统调用。例如, listen/accept/sendmsg 等等。之后再将其转换成 host 的系统调用来进行网络通信。

对于文件访问，gvisor实现了自己的vfs层。其上实现了实现具体的文件系统。有 9p，tmpfs，procfs，sysfs 。真正的文件访问使用9pfs文件系统访问到宿主机上的文件。

gvisor作为容器运行时，它实际上和Docker世界的RunC是同层次的。gvisor目前支持替换runC作为Docker容器的运行时。Kubenete使用gvisor有两种方式，第一种方式是在Minikube里使用gvisor容器；另外一种方式是使用kubelete对接Containerd，配置Containerd使用gvisor-containerd-shim，那么所有带特定标记的容器都会以gvisor方式创建。

截止到18年9月社区上kubenete +docker+gvisor这条路依然没有走通。
目前来看gvisor成熟尚需时日，未见任何商用用例。

CRI-O社区

CRI-O（其O代表OCI），前身是OCID——OCI Daemon，它的诞生源于2016年夏天谷歌的K8s工程师和Docker CTO在社交媒体上的一起大论战。这场大论战背后是Docker在16年7月推出的Docker 1.12将Swarm集成到了Docker引擎内部，这无疑是动了K8s的蛋糕，所以双发终于在16年夏天擦枪走火。这场大论战的详细过程本文不去回顾，感兴趣者可以参考《容器，你还只用Docker吗？》。但是这场大论战的直接后果就是在谷歌的推动下K8s社区推出的了OCID项目，也就是现在的CRI-O项目。CRI-O在社区中有非常强有力的推动力量——谷歌和红帽（红帽因为Systemd和Docker之间也存在罅隙），而IBM，SUSE，Intel，Hyper等公司也是CRI-O的contributor。

CRI-O认为大多数的用户只是使用k8s的容器，而并不关注其容器运行时到底是Docker、rkt还是别的什么。CRI-O 设计目标就是为OCI兼容的容器runtime实现了一个K8s CRI接口层。目前CRI-O支持两种runtime：RunC和Kata。CRI-O是一个非常轻量的工具集，它使用runtime去管理容器的生命期，使用CNI插件创建容器网络，使用container/storage来管理容器的rootfs，使用container/image来管理容器镜像，使用conmon来监控容器的运行。container/storage目前支持overlayfs、devicemapper、AUFS和btrfs，Overlayfs作为缺省的存储驱动。目前计划支持网络文件系统nfs,ceph和Glusterfs。container/image支持从镜像仓库中pull镜像，支持Dokcer V1和V2两个版本的镜像。

原本CRI-O的设计初衷是为了对接Kubenete，并不是直接对接终端客户可以不提供类似于Docker cli一样的命令行。但是为了调试目的，CRI-O推荐使用：crictl调试CRI-O容器引擎，podman工具管理kubenete Pod，buildah构建、推送镜像为镜像签名，skopeo拷贝、删除、查看和签名镜像。

容器社区2018年度发展历程第4张

CRI-O的架构

CRI-O是目前容器社区中除了Docker外，商用进程最快的、最广泛应用的容器引擎。红帽为CRI-O投入了大量的资源，包含了收购CoreOS后获得RKT的资源都投入到CRI-O中。CRI-O在17年推出了1.0版本，它对应的Kubenete版本是1.7.x。CRI-O 1.10与Kubenete 1.10兼容，CRI 1.11与kubenete 1.11兼容，CRI-O 1.12与Kubenete1.12兼容，CRI-O1.13与kubenete1.13兼容。总之CRI-O与kubenete在版本号一致时，保持兼容性。CRI-O在18年度商用进程突然加速，红帽的kubenete发行版本openshift3.9 中将CRI-O标记为GA，在18年8月Redhat宣布在自己的云服务Openshift Online starter 里运行openshift 3.11使用CRI-O作为容器运行时。而在即将推出的openshift4.x中，在RedHat Enterprise Linux和RHCOS(Redhat CoreOS )平台上，将正式将CRI-O作为默认的容器运行时（虽然此版本依然可以使用Docker）。在已经发布的Redhat Enterprise Linux 8 beta中，除了CRI-O外还包含了前文中介绍的Podman，Buildah和Skopeo，通过这些工具在红帽8上，用户可以获得和Docker一样的容器操作用户体验。这无疑是整个容器社区非Docker容器最大的商用进展。