正文
Mesos的统一容器基本就包含了DockerDaemon、Docker仓库等功能。
当然，由于之前一直支持Docker容器，目前阶段Mesos还继续支持Docker，但是也有自己的Mesos Containerizer容器机制。
3、Cloud Foundry通过Garden取代Docker容器管理引擎
从RunC逐步成熟，Cloud Foundry的容器引擎Garden就采用了RunC作为容器运行时，如下图：
Garden取代DockerDaemon（Docker Daemon有内有Docker Server，Docker Server内有Docker引擎），直接调用RunC来生成容器运行环境，同时CFGarden也支持容器插件，容器插件是独立进程，在网络插件方面优先支持Kubernetes的CMN插件标准。CF Diego有自己的镜像仓库管理，也可以从Docker仓库中获取Docker镜像部署。
不得不对Garden的设计多说几句，Garden包括之前的Warden，从一开始的设计就是容器抽象，使得可以支持不同的容器运行时，而且Garden做了三层抽象，所以Garden从一开始就支持.Net应用，不是通过Windows 2016的容器机制来实现，而是在.Net运行时模拟了一个容器的实现，所以Garden支持Windows的几乎所有版本的.Net应用。
Kubernetes CRI-O和Mesos的UnifiedContainerizer都借鉴了Garden的容器抽象设计思路，所以Garden也是第一个支持RunC的CaaS/PaaS。
从这个架构可以看出，Cloud Foundry的Garden基于RunC和容器插件，就替代了Docker的容器功能，共同的是RunC和容器插件，而Garden取代Docker Daemon的容器管理功能。
当然，Garden也支持直接部署Docker镜像。
容器生态的演进
1、各方以RunC为核心重新构建容器生态圈，Docker容器被弱化
在对开源Docker分支进行了反复斟酌、放风声、试探和讨论之后，各方觉得杀伤力太大的方案。而重新回到了折中方案，以RunC为核心重新构建生态圈，并且通过插件来弱化容器在CaaS生态圈的重要性。
我们来看看生态圈的演进示意：
如上图，标识了容器生态圈或是CaaS的演进变化。
最早只有Docker和Garden两大主流容器，Mesos和Google都专注于CaaS，容器就全部采用Docker，CloudFoundry由于在Docker之前就推出了Warden(后升级到Garden)容器，CF采用自己的容器打造了PaaS平台，形成了一个和谐的生态。
在Docker捞过界了，并且确实有些不符合企业生产系统的因素，包括后向兼容性、商标问题、稳定性问题，于是各CaaS/PaaS生态厂商组建OCI联盟，打造RunC容器引擎，只需要一个简单的容器起停、管理等引擎，把Docker的容器功能一分为二，RunC作为一个简单明了的运行环境，降低复杂度，提升稳定性，适合生产系统。而对于Docker容器的其他功能，则在各自的容器抽象层，依据需要去实现，而且因为Docker本身集成了太多功能，不利于生产环境稳定性要求，各个容器抽象层都采用插件模式，维持容器的简洁性，需要什么功能再插入容器，比如需要网络就可以插入网络插件，需要存储和卷访问，就插入存储和卷的插件。
目前的形势，就形成了Docker和各个CaaS/PaaS厂商在同一层面竞争，在CaaS/PaaS平台，Docker并没有什么优势，但是Docker想把其容器的广泛使用的优势在CaaS中延续，目前看来并不容易。容器的主要用户还是个人用户、开发者用户、运维用户，而CaaS是企业系统，二者目标客户不同、技术要求不同。
随着这个生态的演进，Docker容器会更多的用于开发、测试环境，而RunC在各个CaaS厂商的推动下会在生产环境得到广泛的应用。
Kubernetes目前基本只支持RunC容器，对于Docker超出其容器抽象层之外的功能，一概不支持。同样，Mesos也通过其Unified Containerizer只支持RunC容器，目前还支持Docker，但是未来的规划是只支持Unified Containerizer。CF也通过Garden只支持RunC，不支持Docker超出RunC之外的功能。
2、RunC生态的快速发展
