Docker与k8s的恩怨情仇（四）-云原生时代的闭源落幕

转载请注明出处：葡萄城官网，葡萄城为开发者提供专业的开发工具、解决方案和服务，赋能开发者。

第一章：Docker与k8s的恩怨情仇（一）—成为PaaS前浪的Cloud Foundry

第二章：Docker与k8s的恩怨情仇（二）—用最简单的技术实现“容器”

第三章：Docker与k8s的恩怨情仇（三）—后浪Docker来势汹汹

在本系列前几篇文章中，我们介绍了从Cloud Foundry到Docker等PaaS平台的发展迭代过程。今天我们继续来为大家介绍Docker走向落寞的原因以及大航海时代的开启。

Docker的商业化

上篇中，我们讲到了Docker项目利用自己创新的Docker Image瞬间爆红，于是许多商家也从中发现商机，纷纷推出自己的容器产品，也想在市场中分一杯羹。
CoreOS推出了Rocket（rkt）容器，Google也开源了自己的容器项目lmctfy（Let Me Container That For You）等，但是面对Docker项目的强势，就算是Google这种大佬也毫无招架之力。因此Google打算和Docker公司开展合作，关停自己的容器项目，并且和Docker公司一同维护开源的容器运行，但是Docker公司方面很强势的拒绝了这个明显会削弱自己地位的合作。

在这时Docker公司也意识到了，自己仅仅是云计算技术栈中的幕后英雄，只能当做平台最终部署应用的载体。但是，要想成为这个领域的核心，就应该有自己的PaaS生态。在Docker爆火，有了充足的资金之后，Docker公司开始了疯狂的买买买来扩充自己的实力，其中最出名的就署名Fig。Fig是出名的Docker Compose项目的前身。通过这些并购与自身研发迭代，Docker公司最终推出了以自己为核心的PaaS三件套：Docker Compose、Docker Swarm以及Docker Machine。
下面简单为大家介绍一下Docker三件套的内容：

1. Docker Compose：Compose的前身，是一个仅有两个人维护的Docker容器编排的开源项目Fig，它的功能是：假如现在用户需要部署一个应用A和一个数据库B以及负载均衡C，那么Fig就允许用户把ABC三个容器定义在一个配置文件中，并且指定它们的关联关系。最后只需要一条命令fig up即可直接使用。

在Docker大火的时候，Fig项目在Github上的热度堪比Docker，因此在2015年Docker公司将其收购，并且改名为Docker Compose，作为Docker容器的编排工具，并且使用至今。

2. Docker Swarm：Swarm是Docker的集群管理项目，其主要的逻辑就和上一节讲过的Cloud Foundry类似，可以以类似于docker run 我的镜像的命令行方式，以docker run -H 我的Swarm集群API地址 我的镜像这样将Docker运行成一个集群并且进行管理，Swarm的出现将Docker项目从一个普通的容器升级成为PaaS平台。

3. Docker Machine：Machine应该是Docker三件套里最不出名的，它的功能是将虚拟机运行成容器，并且可以以管理Docker容器的方式管理虚拟机。

OCI的“不作为”到CNCF出现

在发展之路上，Docker公司在Docker开源项目的发展上始终保持着绝对的权威和发言权，并且在多个场合用实际行动挑战到了其他玩家的利益；另一方面，Docker公司的商业化路径严重侵害了曾经的合作公司RedHat的切身利益；再加之，Docker在2015年间的高速迭代表中现出了各种不稳定的breaking change开始让社区叫苦不迭。

人红是非多，更何况Docker还抢了大家的蛋糕。于是，容器领域的其他几位玩家开始商讨“切割”Docker项目的话语权。最终，Docker公司迫于压力，于2015年6月22日，牵头了CoreOS、Google、RedHat等公司，共同成立了一个中立的基金会，并将自己的容器运行时LibContainer捐出，改名为RunC，基金会依据RunC共同制定了一套容器和镜像的标准和规范——OCI（Open Container Initiative）。

OCI的成立，意味着容器运行时和镜像的实现与Docker项目完全剥离，让其他玩家不依赖Docker实现自己的Docker运行时成为可能。

但是，由于成立基金会只是Docker公司对这些大公司的妥协，并且其当时确实维护着数量足够庞大的社区，因此Docker公司对基金会的成立有恃无恐，并且对标准的制定并不关心。因为在当时的大环境下，Docker自己的实现，已经就是业界统一的标准了。

由于OCI基金会发展十分缓慢，因此Google、RedHat等基础设施领域的头部玩家打出了手中的王牌，共同牵头成了一个名叫CNCF（Cloud Native Computing Foundation）的基金会（这也是云原生这个概念第一次出现在大众视野内）。CNCF基金会成立的思想基础是，以Kubernetes项目为基础，建立一个由开源基础设施领域厂商主导的按照独立基金会方式运营的平台级社区，来对抗以Docker为核心的容器商业生态。也正是这个基金会的成立，我们第二节的主人公Kubernetes也开始崭露头角。

Kubernetes的出现与发展

Kubernetes是Google公司早在2014年就发布开源的一个容器基础设施编排框架，和其他拍脑袋想出来的技术不同，Kubernetes的技术是有理论依据的，即：Borg。Borg是Google公司整个基础设施体系中的一部分，Borg是Google公司整个基础设施体系中的一部分，Google也发布了多篇关于Borg的论文作为其理论支持。其上承载了比如MapReduce、BigTable等诸多业界的头部技术。因此Borg系统一直以来都被誉为Google公司内部最强大的“秘密武器”，也是Google公司最不可能开源的项目，而Kubernetes就是在这样的理论基础上开发的。下图是Google Omega论文所描述的Google已公开的基础设施栈。

开源vs闭源

面对k8s的出现，一场Docker和k8s之间的容器之战就此打响。

在这场对抗之初，由于Kubernetes开发灵感和设计思想来源于Borg，Kubernetes项目在刚发布时就被称为曲高和寡。太过超前的思想让开发者无法理解，同时由于Kubernetes项目一直由Google的工程师自行维护，所以在发布之初并没有获得太多的关注和成长。

然而，CNCF的成立改变了这一切，RedHat的长处就是有着成熟的社区管理体系，并且也有足够多的工程能力，这使得Kubernetes项目在交由社区维护开始迅速发展，并且逐渐开始和Docker分庭抗礼。并且和Docker的封闭商业模式不同，Kubernetes反其道而行之主打开源和民主化，每一个重要功能都给用户提供了可定制化的接口，并且普通用户也可以无权限拉取修改Kubernetes的代码，社区有专门的reviewer以及approver，只要你写的代码通过PR通过了代码审核和批准，就会成为Kubernetes的主干代码，这也大大的增加了Kubernetes的活力。并且，依托于开放性接口，基于Kubernetes的开源项目和插件比比皆是，并且依托于优秀的架构设计，微服务等新兴的技术理念也迅速落地，最终形成了一个百花齐放的稳定庞大的生态。

而Docker只能通过自己的工程师修改，在这一点上与Kubernetes相比就与远落下风。

总结起来：

面对Kubernetes社区的崛起和壮大，Docker公司不得不承认自己的豪赌以失败告终，从2017年开始，Docker将Docker项目的容器运行时部分Containerd捐赠给了CNCF社区，并且在当年10月宣布将在自己的Docker企业版中内置Kubernetes项目，这也标志着持续了近两年的容器编排之战落下帷幕。2018年1月，RedHat公司宣布斥资2.5亿美元收购CoreOS，2018年3月，这一切纷争的始作俑者Docker公司的CTO Solomon Hykes宣布辞职，至此，纷扰的容器技术圈尘埃落定，天下归一。

总结

本文为大家介绍了Docker是如何在PaaS平台中成为焦点，又如何一步步被Kubernetes替代。下一节我们将继续为大家介绍Kubernetes除了社区之外，在本身的容器编排技术上是如何降维打击Docker公司的，敬请期待。