从一场容器的撕B战开始说起

从2016年7月底开始,GoogleKubernetes布道师 Kelsey Hightower 和Docker的CTO Solomon Hykes在Twitter上发生了一场撕B大战,主题是不是需要用RunC或其他容器来取代Docker引擎以及OCI的意义。

首先是Google的Kelsey挑事,说:

“很多平台都可以跑Docker镜像,已经不再需要Docker Daemon了。哪个会成功呢?”

Docker CTO Solomon马上接招:

“其他平台跑Docker镜像是假的,其中只有90%能正常工作,其余10%则随时可能会出问题。而且Docker还在演进中。”“所以嘛,声称“可以跑Docker镜像”的都是在撒谎。”

Kelsey Hightower反讽:

“好吧,那我们就没必要再提支持Docker了。我们实际支持的只是Docker的容器格式”,

“Docker拥有创建和分发镜像的最佳工作流,而运行时,还是留给它的竞争者们吧。”

所罗门继续强调Docker的不兼容性:

“这些都是不完整的、不兼容的支持”

“他们也并不支持镜像格式,镜像的很多信息都会丢失”

后来,所罗门急眼了,说

“OCI就是个伪标准”

此言一出,惊诧四方,因为OCI有50多家厂商参与,而且Docker还是重要贡献者,

有说“标准不是一个人可以决定对错的”,

有反讽的 “我相信工程师们乐于听到他们创始人说他们做的工作是假货”

K8s的老大Tim Hockin直接就说“不爽你就走,不要假装参与”

所罗门不得不改口说“OCI标准的初衷是好的,只可惜扩展太早,我不认同就得走?”

有人随即反驳“只有你一个人说扩展的太早,这是明显的利益投射”

所罗门还嘴硬“就因为我是唯一的不认同者,那我就必须离开?”

Kelsey随后则直点主题,“有两个问题在台面上,一是容器需不需要标准化,二是需不需要由Docker来领导这个标准化的工作?”。

Kelsey再以嘲讽的口吻自问自答“如果是Docker来回答这些问题,对第一个肯定是说不,那干脆对第二个问题也同样说不吧,这可不是对和错的问题”

因为事关OCI,Docker现在这么鄙视RunC,OCI不得点出Docker你也是参与者就别闹了, “Docker参与在OCI运行时和镜像规范,也参与了每周的开发会议”。

Kelsey乘胜追击,代表业界吐了个槽,“我一直相信Docker会给容器带来很多,但是我真的担心一个人想控制的太多”。Docker公司的控制欲早成为人们的吐槽点,什么都想做,把整个生态圈其他的参与者逼到墙角去了。

看业界大佬撕B,感觉和咋人民群众撕B没太大差别。所罗门的撕B技巧明显略逊一筹,有点像祥林嫂反复说“其他容器就是和Docker不兼容,包括RunC”,但是没说出个哪里不兼容的道道。

1   容器撕B之争反应了容器生态面临的问题

我们来总结这次著名的撕B事件的来龙去脉,这会成为容器界一个关键的历史转折事件。容器之争始实际上是很早之前就起源于Docker生态面临的问题

1.1 Docker商标的注册围剿了容器生态圈

从表面上看,是容器标准之争,其实,反应的是赤裸裸的利益问题。Docker从容器开始,在获得社区的热烈响应之后,就进入了圈地过程,而且第一招圈地就非常凶悍,把公司从dotCloud改名为Docker,然后注册Docker商标,商标意味着当其他公司使用未经Docker社区许可的补丁、代码或软件包的时候时可能面临法律责任。这种情况下,一个公司可能因为补丁尚未经过Docker公司许可,抑或尚未被合并到项目中,而不能为客户提供技术支持。

这不只是法务上的圈地,对于很多采用Docker名字的,Docker公司给予了实际行动---口头警告(谁叫Docker是人家注册的名字呢,就好比weibo.com就是微博),包括你建一个群名不加修饰限定的叫Docker,或是你要写本书,不加修饰的叫DockerXXX,都容易受到Docker的警告。从法务上看这确实也属于侵权,就看Docker要不要告你。

其后果就是第三方Docker生态厂商被迫忍受Docker公司任何对该开源项目作出的决定,在问题出现的时候等待Docker公司的补丁。最好的结果与Docker达成某种协议,由Docker公司来保证提供稳定的发行版本。那Docker的生态公司就沦为Docker公司的代理商了。

1.2 Docker挟容器引擎优势进入容器集群管理,挤压了容器生态圈的其他厂商生存空间

如果只是口头撕B,那吃瓜群众看看热闹就可以了,事实上这涉及到巨大的利益和整体生态环境的分歧,也涉及到Docker用户的后续选择。

在Docker获得广泛关注以后,就利用Docker容器的广泛性优势来挤压生态圈其他伙伴的生存空间。直接把Swarm内置在Docker中。和当年的Microsoft通过Windows捆绑IE来打击NetScape有异曲同工之妙。

Docker公司原来只在容器领域发展,K8s/Mesos等做容器集群管理,属于CaaS(Container as a Service),相互补充,互不竞争。等Docker容器被广泛关注以后,Docker进入容器编排市场,收购了相关的技术以后推出Swarm的容器集群管理,从容器进入CaaS市场。2016年7月发布的Docker 1.12把Swarm内置到Docker中去了,Docker Swarm作为容器集群管理软件,内置在Docker中,几乎就是Windows捆绑浏览器IE的模式,这就是用不平等的市场优势打击了Google的K8s和Mesos等,Google也不是吃素的,所以7月底马上就是和Docker CTO口头开撕。

对于Docker生态圈的集群管理软件K8s和Mesos等来说,不但是不平等的竞争,最关键的是在容器生态圈最能带来商业价值的就是容器集群管理,单单容器本身并没有太多的商业价值,容器没有集群管理是很难进入企业运行环境的。因为容器的直接商业价值并不大,CaaS厂商也没有自己做容器,而是直接做容器集群管理。所以K8s和Mesos已经进入了这个商业领域并且取得了一定的优势。现在Docker进入这个领域,就直接和容器集群管理的公司竞争。而Docker公司又是不得不进入这个领域,如果不进入这个领域,很难取得商业成功,Docker本身又经过多轮风投,风投给Docker带来了巨大的盈利压力,如果久久不能盈利,那风头的脸色不会那么好看了。

如果是公平竞争还好,比如Docker单独发布Swarm的Docker集群管理,但是Docker直接把Swarm内置到Docker中去,安装部署Docker就带了Swarm,而Swarm的很多功能和K8s和Mesos是重叠的,K8s和Mesos再用Docker就显得功能有大量重叠,而且带来了系统的复杂性和不稳定性。

2   Docker的问题—业界对Docker的吐槽

在Google和Docker口水战之后,业界对Docker的吐槽越来越多,主要包括以下几点:

2.1 Docker向后兼容性问题

Docker被业界诟病最多的就是后向兼容性,Docker的新版本更关注的是革新性,而不是兼容性,但是,对于一个生产系统来说,后向兼容性至关重要,没有后向兼容性,意味着每次Docker升级都带来巨大的风险。

这也和Docker的企业文化有关,Docker更倾向于采纳新技术,实现突破性的功能,这是典型的初创公司的企业文化,不断的追加新功能,而不考虑企业级特性,更不考虑后向兼容的束缚。这个好处是能在个人粉丝中取得共鸣,这也是Docker快速流行的一个重要原因。任何特征都可能是双刃剑,这种企业文化并不适合企业级,不考虑生产运行的可用性,对企业级应用来说可能是灾难性的。

我们看看业界人士是怎么说的:

“Docker不断地破坏向后的兼容性”,RackN公司的CEO Rob Hirschfeld说。RackN公司的应用程序生命周期管理平台同时使用和提供了Docker组件,因此对后端的改动将会对其支持的客户的业务造成影响。

“Docker将Docker Engine用作一个产品,而不是一个社区用来构建自有服务的组件”,Hirschfeld指责道。这种基于产品的策略意味着使用者被逼着在Docker发布新的革新特性或者合并新的组件(如Swarm)的时候去修复其破坏的向后兼容的问题。

“尽管我们会使用这些发布的特性,然而这些改动会带来一系列与稳定性、版本、迁移和后端兼容相关的问题”。

Bob Wise,一名三星SDS云工程师,也同样呼吁Docker放慢其容器创新的脚步,该公司同样提供了基于云的容器相关支持服务。

“如果你的团队在深度使用Kubernetes、Mesos或Cloud Foundry,你需要一个稳定、简单、无奇的容器实现方案,仅有最少的基本功能,由社区协商镜像的创建、命名和发布”,Wise的一篇博客中写道。“你需要使用每个都人都在使用的一个相同的、简单的、无奇的容器实现方案。作为一个社区,我们需要放缓对于基本构建组件的变更速度。唯有稳定性才能让构建其上的系统蓬勃发展。”

2.2 Docker容器在企业级方面还有待提高

Docker虽然一直宣称ProductionReady,但是在实际的生产系统中同样受到不少诟病。

看看业界人士的说法:

Apcera技术产品经理 Phillip Tribble在个人博客中,以一种外交辞令的口吻,让Docker不要再把其新推出的特性鼓吹成一个完工的企业级可用的产品。Tribble写道:“让互联网或者大会充斥着营销材料,宣扬各种令人振奋的新特性,但实际上却不如所说那样能用,不是一个明智的做法”,

Apcera的商业模式一部分是基于提供Docker容器的支持。

Tribble的帖子引发了其他人在Hacker News上表达他们的Docker经历,包括一些新版本带来的让人伤心的bug。一位读者谈到一天中启动70,000到90,000个容器,约9%左右的会因为“各种Docker bug”遇到问题,这个比例最近的一次升级后下降到了4%。

但也有一些人在称赞Docker的稳定性,“我们一直在生产中使用Docker约3年了,还没有发现什么大的问题”,另一外读者评论说,“它将一些很炫的Linux内核特性用简洁的方式封装了起来”。

当然也有不少Docker的支持者认为Docker公司的软件是稳定的。同一个产品,在不同的客户有截然相反的反应说明有的用的好,有的用的碰到不少问题,在不同的环境下缺乏一致性,这也是企业生产系统的大忌

2.3 Docker捞过界了,越过了红帽的操作系统界限?

哪些功能应该有Docker来实现,哪些功能应该由底层操作系统或者技术栈中的其他组件来负责处理?

在今年的很多会议上,包括 LinuxConNorth America 2016,红帽工程师 Dan Walsh 说红帽陷入了困境,一方面客户越来越多的使用 systemd 来初始化Linux系统,而另一方面Docker似乎不愿使用systemd,取而代之使用DockerDaemon来提供初始化,服务激活,安全和容器日志的相关功能。

“在过去的三年里,我们一直试图使systemd和Docker更好的整合,而我却发现,两个领导人都非常强烈的坚持己见”,Walsh说,两个领导人指 Hykes和systemd的创造者-Lennart Poettering

“所以,当机器的时候,谁来负责启动系统服务,是systemd还是Docker?”Walsh问到。一个拙劣的系统实现可能会导致systemd和Docker互相冲突。

红帽为自己的客户维护着自己的Docker版本分支,红帽分支中的补丁Docker有一天可能会合并,或者永远不。红帽也冒着巨大的风险,红帽的客户也冒着巨大的风险。所以红帽对Docker的支持其实远不如Ubuntu,因为Docker已经侵入到OS的领域了。

即使是面对以上种种吐槽,Docker也不打算折中一下,甚至也不打算照顾这些意见,而是继续我行我素。

3   容器生态圈集群管理厂商的应对--—不用Docker,把容器引擎拆解自己重组

撕B只是矛盾爆发的阶段总结,后面就开始进入实质性的对抗阶段了。容器生态圈的集群管理厂商如Google/Mesos也不是吓大的,快要被Docker断了财路——— “人为财死鸟为食亡”,其反应也直取Docker命门——在其CaaS中废弃Docker,对容器进行抽象,用谁的容器都可以。容器运行时不再用Docker,而直接采用RunC,容器扩展功能通过插件来实现,基本就是全抛弃Docker了,这对Docker来说几乎是生死之战。

其实,容器技术本身的壁垒不高,Docker 2013年一开始也就是几十人的开发队伍,到现在也只有200多人,各大厂商一直没有重视这一块,因为单单容器的商业价值比较低。真正要投入做容器,也只是分分钟的事情,只不过Docker已经在容器领域形成了气候,所以要走些变通的曲折路线。

各大厂商一起做个RunC,大家再只用RunC还是轻而易举的。

我们再来看容器最主要的两个的技术来源:

1、             Namespace---来源于IBM

2、             cGroup----来源于Google

其他的容器核心技术都是Linux操作系统的功能,容器的核心技术是和Linux操作系统密切相关的,Docker本身在容器核心并没有什么贡献,NameSpace和cGroup都不是Docker的,也和Docker无关。Docker也不是最早用容器技术的,Cloud Foundry比Docker更早把容器用于PaaS, Cloud Foundry早在2012年就开始使用Warden容器。

所以容器生态圈的公司撇开Docker做一个容器标准并不是什么难事。

我们再从时间线来梳理这个撕B事件,让大家更直观的理解:

1

3.1 提前铺垫---先通过RunC把容器运行时分离出Docker

2012年,随着Cloud Foundry的PaaS率先引入了容器技术,容器技术发展的愈发火热,特别是Docker成为流行技术,形成了广泛的生态圈,由于Docker一贯的控制欲,让生态圈的其他大小伙伴难以参与,为破解这种状况。Google先是支持CoreOS打造了Rocket容器,在Rocket和Cloud Foundry容器Garden(Warden容器的下一版本)的竞争压力下,Docker终于同意容器标准化----RunC项目成立,通过RunC对容器运行时进行标准化。

于是容器生态圈终于达到了拆解Docker技术堆栈第一个小目标---通过RunC把容器运行时独立于Docker之外。在 2015年6月成立OCI(Open Container Initiative)组织,挂在Linux基金会旗下。旨在围绕容器格式和运行时制定一个开放的工业化标准。该组织超过50家大小成员,包括谷歌、Pivotal、Docker、CoreOS、微软、亚马逊、华为等一系列云计算厂商,按照该开放容器格式标准(OCF, Open Container Format)制定的一种具体实现,当然Docker是RunC的重要贡献者。

OCI对Docker意味着什么,Docker不是不清楚, 知道RunC是来抢食的,除了会削弱自己的优势,也还会被OCI标准束缚住,限制自己的发挥,所以Docker对OCI是消极抵制,但是无法和整个生态圈抗衡,不是不接受OCI和RunC。

面对Google、RedHat或者Microsoft这样的大公司,不管从技术实力还是财务实力,以及政治关系处理上,Docker应该都很难占到太多便宜。但是技术大势所趋,Docker也无法抗拒。

3.2 RunC容器格式标准是什么?

制定容器格式标准的宗旨概括来说就是不受上层结构的绑定,如特定的客户端、编排栈等,同时也不受特定的供应商或项目的绑定,即不限于某种特定操作系统、硬件、CPU架构、公有云等。

最核心,是通过格式标准化来脱离Docker,有利于CaaS生态圈的公司各自发展,但是在标准层面汇聚。

RunC是三大容器厂商共同支持的标准:CoreOSRocket, Cloud Foundry Garden和Docker容器。

3.3 RunC容器标准化宗旨

标准化容器的宗旨具体分为如下五条。

操作标准化:容器的标准化操作包括使用标准容器感觉创建、启动、停止容器,使用标准文件系统工具复制和创建容器快照,使用标准化网络工具进行下载和上传。 内容无关:内容无关指不管针对的具体容器内容是什么,容器标准操作执行后都能产生同样的效果。如容器可以用同样的方式上传、启动,不管是php应用还是mysql数据库服务。 基础设施无关:无论是个人的笔记本电脑还是AWS S3,亦或是Openstack,或者其他基础设施,都应该对支持容器的各项操作。 为自动化量身定制:制定容器统一标准,是的操作内容无关化、平台无关化的根本目的之一,就是为了可以使容器操作全平台自动化。 工业级交付:制定容器标准一大目标,就是使软件分发可以达到工业级交付成为现实。

RunC标准化是瞄准工业级交付和运行时的,和Docker定位不一样。各个CaaS/PaaS生态厂商需要一个标准的容器运行时,然后围绕着这个标准运行时各自发挥自己的技术优势,做编排的、做集群管理的、做资源调度等等,形成真正的容器生态圈。

3.4 第一步—--虚张声势扬言对Docker容器另起分支,废弃Docker公司对Docker的独一控制权

在和Docker撕B之后,引起了业界的集体吐槽,然后Google进入第一步:虚张声势,先来个大杀招吓唬Docker----尝试分支开源Docker来废除Docker公司对Docker容器的独家控制权。

先是Google方放出风声,要对开源的Docker Engine重起炉灶—分支出一个容器,马上在业界引起巨大的波澜。

“在诸多正在考虑的选项之中,包括可能会将整个开源的Docker Engine一起重起炉灶(fork)。据一些接近讨论的人士透露,相关代表来自Red Hat、Google、CoreOS、华为和两家大量使用Docker的客户。”

随后大家对Docker的代码库稳定性不足表达了各自的忧虑,因为这可能会在生产环境下基于Docker构建附加服务或者向客户提供技术支持的时候招致各种麻烦。在表达各种对Docker公司在Docker Engine上管理的失望之后,没有得到Docker的正面响应,相当多的技术专家和公司是支持分支的。因为Docker也不是吓大的,对种种指责不予理会。

但是,也有很强的声音担心Docker从此支离破碎:

“目前发生的这件事情,如果处理不得当,会让让容器生态系统支零破碎,并导致单个的容器再无可能适配多种目标运行时环境。”一位Hacker News上的观察员指出。

鉴于直接分支对整个生态会产生不可预知的影响,属于杀敌三千自损八百的,虽然Docker CTO所罗门当初说OCI是个伪标准就是“杀敌三千自损八百”的招,但是碰到猪队友不能把自己也变成猪。直接分支停留在口头上。

3.5 第二步—---通过RunC和插件来拆解Docker技术堆栈

在和Docker撕B之后,引起了业界的集体吐槽,然后Google和业界进入第二步:

随着RunC标准化的发展,RunC逐步成了构建容器运行隔离环境的标准,和Libcontainer的功能类似,Libcontainer对RunC也有很大的贡献。那到底RunC和Docker是什么关系,如下图:

2

 

Docker从1.11开始就采用了右边的架构,这其实是Docker公司折中妥协的结果,因为面对Rocket和Garden的竞争,如果不支持RunC,那么在容器马上就会进入分裂竞争状态。

而OCI业界希望能够在容器的运行环境标准化,也就是构建出一个容器运行环境的这部分能标准化,在容器运行环境下不需要Docker庞杂的功能,容器运行时这部分占Docker的整体功能比重很小,所以OCI组织很快就达成的一致,发展RunC容器运行时。

所以,理解Docker和RunC的关系,你可以理解为RunC是Docker一部分,而且是构建容器隔离运行环境的一部分,而这一部分,也恰恰是CaaS的厂商所需要的,他们只需要一个生产环境下的容器环境构建,不需要容器的镜像打包等,这属于开发测试所需。

通过RunC,也基本确定了CaaS/PaaS产品如Cloud Foundry/K8s/Mesos等只需要RunC这个容器生产时的运行环境,而Docker更多的用于开发测试时。

除了RunC,容器插件也是一个关键的公有技术,把容器的功能扩展和外部交互的功能插件化,而插件在开源社区相当活跃,插件主要是四类:安全认证、存储卷管理、网络、IP池。比如各个存储厂商都在开发或是已经开发了自己的存储插件。

而这些插件也可以和RunC交互,通过上面一层的集成,可以让RunC用到这些插件。而插件也基本外化了Docker的功能。

虽然Docker定义和开发了很多插件,但是插件可以各自开发。插件只要提供接口就可以容器运行时交互。不再局限于某个公司的插件。这里不得不提到K8s开发的网络插件CNM和Docker自身提供的CNI就不一样,虽然理论上是可以相互兼容,但是实际上是两套实现机制,而且CNM得到了CaaS/PaaS厂商更广泛的支持。

通过RunC和插件,把Docker容器引擎的功能进行了分拆,而且分拆的部分都有了替代品,只等下一步。

3.6 第三步—-CaaS生态厂商通过容器抽象、RunC和插件来重组自己的容器技术堆栈

如下图是各个业界厂商对Docker容器技术堆栈的进一步分拆,然后进行组合,形成各自自己的容器堆栈。分拆不是目标,是手段,组成成自己的容器才是目标。和我们的国产化替代是不是有点类似??

3

 

首先把Docker的技术堆栈分解为容器运行时RunC、插件、容器管理进程和容器仓库。因为已经有了RunC的基础,而且插件可以公用,各个厂商只要做容器进程管理和容器镜像管理,既然是新的技术架构,各个厂商也考虑到容器的兼容性,大家很一致的做了一个模块,称为容器抽象,无论是Mesos还是K8s。有的把容器镜像也一起做在容器抽象层,有的是单独再做一个镜像管理。

看下图右边的重组后的技术架构,完全没有了Docker,也不需要Docker,但是很自然而然的取代了Docker的容器。这就是很典型的对Docker技术栈分解,先取代最核心的容器运行时RunC,再把功能外化到插件,然后再做一个容器抽象层,彻底肢解并取代了Docker。

4

 

注意红色的框架,通过RunC和插件,CaaS/PaaS业界把他们所需的容器功能从Docker中独立出来了,也就是有了RunC和插件,CaaS/PaaS完全可以不需要Docker就构建出CaaS/PaaS运行环境。

4   CaaS业界通过分解重组Docker技术来替代Docker的方案 4.1 K8s通过CRI-O取代Docker容器管理引擎架构

和Cloud Foundry的架构模式类似,K8s也发展了CRI-O来取代Docker,架构图如下:

CRI-O是Google的Kelsey和Docker CTO所罗门论战之后的结果,论战之后,Google就提出一个设想,要让K8s调度的容器去Docker化,虽然他们一开始说的是要分支出一个Docker的分支来做容器,但是后来考虑到这样做属于刺刀见红,杀伤力太大,所以在2016年6月先弄了一个OCID(OCI守护进程),就是RunC的守护进程,和Docker Daemon有异曲同工之妙,该项目的维护人员此地无银三百两的说“这不是Docker的分支”。

由于OCID过于和Docker Daemon类似,随后Google又把这个项目重新命名为—CRI-O(Container Runtime Interface,容器运行时接口,O表示OCI,也就是RunC的运行时接口),这也反映了Google的心态,一方面通过CRI对容器进行抽象,什么容器我都支持,另外加一个O,我重点支持OCI的RunC,显得不是那么白刀子进红刀子出,大家表面上还是和平共处,而且显得立意更高,通过容器抽象层进一步标准化容器,RunC只是标准化容器运行时,CRI把对容器的调用管理等也标准化,潜台词是Docker Daemon是非标准的,独家的。

同时,Google也在向Mesos推销其CRI-O,希望Mesos也采用其CRI-O的架构。

CRI-O对容器运行时提供基本管理功能,同时Google的K8s提供镜像管理功能(Container/Images),完全可以取代Docker的镜像仓库。K8s一方面支持容器插件技术,另外,也自己制定实现一些容器插件,最典型的就是容器网络插件,自己定义并实现了CNM的容器网络插件。

因为K8s之前一直支持Docker,为了保持一定的兼容性,K8s继续支持Docker容器,但是不再支持Docker超出标准容器之外的特定功能,也就是把Docker的定位和RunC等同化,Docker做的再多功能也不用。

4.2 Mesos通过UnifiedContainer取代Docker容器管理引擎

Mesos一开始就支持Mesos Container和Docker容器,并且支持在MesosContainer中不依赖Docker Daemon使用Docker镜像,就是镜像兼容,也是Docker CTO所罗门说的”其他平台跑Docker镜像是假的,其中只有90%能正常工作,其余10%则随时可能会出问题”的情形。好像也没有反应出现什么大问题。

单Mesos在容器的规划中对容器进行了抽象,项目名字直接就叫”Unified Containerizer”—统一容器。目前还是支持 Docker 和 MesosContainerizer 两种容器机制,未来就统一到”Unified Containerizer”。架构图如下:

Unified Containerizer也支持插件架构,但是和Docker的插件不是完全一样,设计的插件类型更丰富,包括三大类:

第一类是进程管理,支持容器之前的进程,这也是Mesos一贯的调度管理策略

第二类是隔离器: 在容器生命周期的各个阶段提供扩展接口,保护了Docker的几类插件,如网络、磁盘、文件系统、卷插件。

第三类是容器镜像管理,除了容器镜像,还将支持虚机镜像等。

Mesos的统一容器基本就包含了DockerDaemon、Docker仓库等功能。

当然,由于之前一直支持Docker容器,目前阶段Mesos还继续支持Docker,但是也有自己的Mesos Containerizer容器机制。

4.3 Cloud Foundry通过Garden取代Docker容器管理引擎

从RunC逐步成熟,Cloud Foundry的容器引擎Garden就采用了RunC作为容器运行时,如下图:

5

 

Garden取代DockerDaemon(Docker Daemon有内有Docker Server,Docker Server内有Docker引擎),直接调用RunC来生成容器运行环境,同时CFGarden也支持容器插件,容器插件是独立进程,在网络插件方面优先支持K8s的CMN插件标准。CF Diego有自己的镜像仓库管理,也可以从Docker仓库中获取Docker镜像部署。

不得不对Garden的设计多说几句,Garden包括之前的Warden,从一开始的设计就是容器抽象,使得可以支持不同的容器运行时,而且Garden做了三层抽象,所以Garden从一开始就支持.Net应用,不是通过Windows 2016的容器机制来实现,而是在.Net运行时模拟了一个容器的思想,所以Garden支持Windows的几乎所有版本的.Net应用。

K8s CRI-O和Mesos的UnifiedContainerizer都借鉴了Garden的容器抽象设计思路,所以Garden也是第一个支持RunC的CaaS/PaaS。

从这个架构可以看出,Cloud Foundry的Garden基于RunC和容器插件,就替代了Docker的容器功能,共同的是RunC和容器插件,而Garden取代Docker Daemon的容器管理功能。

当然,Garden也支持直接部署Docker镜像。

Cloud Foundry无论是开源的CF还是Pivotal公司的商业发行版PivotalCloud Foundry均在最近的版本中采用了RunC容器运行时。

5   容器生态的演进 5.1 各方以RunC为核心重新构建容器生态圈,Docker容器被弱化

在对开源Docker分支进行了反复斟酌、放风声、试探和讨论之后,各方觉得杀伤力太大的方案。而重新回到了折中方案,以RunC为核心重新构建生态圈,并且通过插件来弱化容器在CaaS生态圈的重要性。

我们来看看生态圈的演进示意:

6

 

如上图,标识了容器生态圈或是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厂商的推动下会在生产环境得到广泛的应用。

K8s目前基本只支持RunC容器,对于Docker超出其容器抽象层之外的功能,一概不支持。同样,Mesos也通过其Unified Containerizer只支持RunC容器,目前还支持Docker,但是未来的规划是只支持Unified Containerizer。CF也通过Garden只支持RunC,不支持Docker超出RunC之前的功能。

5.2 RunC生态的快速发展

由于Docker的消极抵制,RunC的发展好像并不为人所知,但是RunC的发展还是很快的,RunC本身就简单,通过版本的持续的迭代更新,目前已经达到生产可用,而且主流的PaaS/CaaS纷纷采用。Docker也从1.11开始内置RunC容器运行时。

除了RunC本身的发展,RunC的生态圈也在快速发展,这个生态圈就脱离了的Docker。比如最近的Riddler,就是一个把Docker容器转换为RunC镜像。

详见https://github.com/jfrazelle/riddler

6   你还只用Docker吗?

Docker作为目前最热的容器开源项目,受到广泛的追捧。但是也要清醒的看到Docker和容器生态圈的种种争斗,Docker通过注册商标和在Docker中内嵌容器集群管理,挤压生态圈其他公司的生存空间,而受到生态圈联盟以RunC和相应的技术来制约Docker。

如果你是开发测试用Docker,那么基本不受影响,可以继续,这也是很多公司对Docker的定位。如果你是生产系统采用Docker(包括Swarm),你就要注意,如果是你自己定制开发基于Docker/Swarm的CaaS(Container As a Service),那问题也不大,出现漏洞或是定制可以自己打补丁,但是要意识到你的补丁不一定能合并到Docker的主干版本。如果是你采用的是第三方给你定制的基于Docker和Swarm的CaaS,你就一定要当心了,他们针对Docker做的定制要合并到Docker的后续版本有相当的难度,因为对于Docker的补丁定制合并,除了Docker公司其他公司几乎是没有什么控制力度的,还包括后向兼容性问题。

作为用户或是容器生态圈的创业公司,不能一棵树上吊死,如果在容器层面只考虑Docker,而不考虑RunC,可能会和CaaS/PaaS生态圈的标准越来越远,未来和CaaS/PaaS的标准容器差异越来越大,主流的CaaS/PaaS厂商和技术,如K8s/Mesos/Cloud Foundry均不再支持Docker容器超越RunC之外的功能,而只支持插件对RunC功能的扩展。

业界更普遍的定位是Docker用于开发测试环境,而RunC用于生产环境,所以对于要在生产环境采用容器技术的,一定要研究RunC。

作为容器创业公司,很多是在Docker的风口成立的,但是并由于Docker一家独大和Docker注册商标的法务问题,如果现在还没有在风口起飞。应当可以考虑在OCI/RunC的生态圈进行相关技术的发展,OCI/RunC的生态圈受到实力强大的几家公司的强力支持,如Google、CF基金会、Pivotal、Redhat、Mesos、CoreOS等。而且RunC的生态圈还刚刚起步,还有很大的发展空间。而且作为技术创新,对于技术的前瞻性判断非常重要,方向判断正确,一路辛苦是披荆斩棘,方向判断错误,一路辛苦也是前程堪忧。

国内的公司对RunC的贡献度越来越高,特别是华为,可能是国内公司中对RunC贡献最大的。还有EasyStack、南大索芙特等的贡献,反倒是一些著名的Docker创业公司看不到对RunC的贡献。这一方面反应了华为、EasyStack技术眼光和对社区的贡献,另外也反映了为什么华为和EasyStack在商业上也更成功一些。

7   对一些问题的提前答复 7.1 RunC也是Docker的,用Docker和用RunC不是一样的吗?

Docker对RunC有重大的贡献,RunC的早期也是基于DockerLibcontainer,但是RunC在OCI下独立发展,有贡献的厂商远远不止Docker。在RunC项目后,在OCI的推动下,各个厂商积极贡献,Docker的代码贡献并不占主导,更谈不上主要是Docker在维护,更准确的说Docker是RunC的重要维护力量之一。

如下图,是Git上RunC的代码贡献者排名:

7

8

前10个贡献者中,Docker只占2位,不得不提国内的公司华为代码贡献排名是相当的靠前。而且RunC的代码贡献者超过100人。

除了K8s/Mesos/CloudFoundry支持RunC容器运行时,Docker的容器从1.11开始也内置RunC作为容器运行时,说明RunC受到最为广泛的支持。而K8s/Mesos/CloudFoundry明确表示在容器抽象层不再支持Docker超越RunC之外的功能。

RunC属于OCI,不再受Docker注册商标的影响,对RunC的代码贡献不再受限于Docker。

用RunC相当于给你一个干净简单的容器运行时,用Docker相当于不管你要不要,强塞给你一堆可能你不想用的东西。

对于RunC和Docke的技术区别,详细请参考上篇的4.5                 

7.2 在Docker如日中天的时候这么说是哗众取宠

Docker现在是如日中天,但是3年前也是刚起步,也许可以说RunC就是3年前的Docker。Docker由于Docker公司自身的商业特征,对容器生态圈其他公司的生存空间的挤压,已经造成了容器生态圈的裂变。

“风起于青萍之末”,如日中天的时候可能就是走向下坡路的开始。Docker一家和其他CaaS生态圈分裂,这条路注定是不平坦的。

7.3 黑Docker黑出翔来了

黑Docker的资料很多,所有资料都有出处,有参考内容链接,详见后面的引用。

Docker已经被布道师们说成”无所不能”,稍微有几个不能,我觉得大家还是能区别的出来。

7.4  RunC是没人管的孩子

RunC的自身发展远不如Docker那么有名气,因为RunC本身就是一个很小的容器运行时,不是针对开发者的,开发者往往是通过Docker接触到RunC,所以RunC的受众远比Docker要少。

但是对于CaaS项目来说,K8s/Mesos/CloudFoundry往往就是基于RunC容器运行时。

RunC的社区也很活跃,除了RunC本身的更新很快,各大CaaS/PaaS生态圈如Google/Pivotal/Redhat/华为/CoreOS等都有专人在贡献代码。

RunC相应的生态空间也在活跃,也有不同的项目在进行中。

RunC是CaaS/PaaS/OCI等生态圈共同的孩子,不是没人看的孩子。

7.5 容器不需要标准更好

业界也有一些人持这个观点。其实,标准的价值是常识,当然总会有反常识的言论出来。没有标准就没有合力,没有合力哪来的发展。如果Docker公司把闭源,那可以没有标准。既然是开源,又想要生态圈的其他公司和力量做贡献,但是做的贡献全Docker公司说了算,那就是把生态圈的其他公司当作免费打工的。

要让大家有合力,就要让大家在标准的基础做贡献,而且标准不是一家公司的,而是公司联盟。

8   总结和展望

Docker和CaaS生态圈在容器上的分裂已经是现在进行时了,虽然大家都没有明说。这也将是容器和CaaS生态圈重要转折事件。让我们来看看目前正在发生的和在未来一年中很有可能发生的事情:

1、  Cloud Foundry率先采用RunC作为容器运行时,而且刚刚做了一个25万个容器集群的测试,

https://www.cloudfoundry.org/cloud-foundry-approaching-250000-containers/  验证了PaaS+RunC的大规模集群的支持。

K8s的CRI-O也会尽快发布,等CRI-O成熟以后,内置的容器运行时就应当是RunC,而不再是Docker了。

2、  Mesos的Unified Containerizer 也应当会在1年之内成熟,随后内置的容器应当也是RunC,而不再是Docker。

3、  在Docker被科普以后,客户更关注的是CaaS而不是容器,再给客户去科普Docker体现不出容器创业公司的价值。

4、  一些不适合容器的Docker应用场景的案例会被证伪,在Docker和容器鲜为人知的时候,各种各样的Docker案例层出不穷,包括一些明显和常识有违的案例,比如交易系统采用Docker, 交易极严格的延时的要求不适合Docker。有的是故意混淆概念,交易本身不在Docker容器中,交易系统相关的一些模块在Docker中,为了突出宣传效果,说交易系统采用Docker。

5、  Docker创业公司分化,越来越多的容器创业公司给别人介绍自己的时候会说我们是K8s初创公司(或我们是Mesos创业公司),不是Docker创业公司,强调自己是CaaS厂商,突出自己不是Docker厂商。当然,也有纯Docker的创业公司,但优势会变成劣势,毕竟在CaaS领域,Docker没有优势。

6、  Docker在失去了K8s/Mesos/CloudFoundry的支持之后,会更专注于Swarm,和CaaS的其他厂商的竞争将更直接,但是Docker公司一贯的对企业生产环境特性的不在乎,Swarm很难对其他CaaS形成竞争优势。

7、  RunC的生态圈将越来越丰富,第一个就是把Docker镜像转换为RunC标准镜像(这个已经有了),其次就是各种各样的插件和RunC可以交互,中间还可以衍生出各种插件的功能,如即插即用(动态性)、自动发现之内的。

一年以后,我们再来复盘。

9   参考内容

本文部分内容原创,但是大量的引用了下面的参考链接,给这些参考文章作者致敬。

http://www.dockerinfo.net/1959.html

http://dockone.io/article/1672

http://weibo.com/1901150895/DzV6cDEC1?from=page_1005051901150895_profile&wvr=6&mod=weibotime&type=comment

http://www.infoq.com/cn/articles/docker-standard-container-execution-engine-runc

https://segmentfault.com/a/1190000007157374

http://www.echojb.com/dotnet-other/2016/09/25/213618.html

http://www.wtoutiao.com/p/4fdLO2y.html

http://dockone.io/article/1770

http://dockone.io/article/776

http://www.kubernetes.org.cn/300.html

http://dockone.io/article/1327

http://mp.weixin.qq.com/s/NlyJtev6sVTCGSaGSmVtzg

关注中国IDC圈官方微信:idc-quan 我们将定期推送IDC产业最新资讯

查看心情排 行你看到此篇文章的感受是:


  • 支持

  • 高兴

  • 震惊

  • 愤怒

  • 无聊

  • 无奈

  • 谎言

  • 枪稿

  • 不解

  • 标题党