一文读懂Kubernetes与Docker的那场较量，Kubernetes为什么胜出？

2022年5月，CNCF发布了代号为Stargazer的Kubernetes v1.24。如之前的宣传，在Kubernetes v1.24中dockershim被移除了，这意味着Kubernetes绕过了Docker，直接调用Docker内部的containerd。早在两年前CNCF就已经公布了这一计划，当时还引起了“Kubernetes是否要抛弃Docker”的讨论。不过，两年后的今天真正走到这一步时已经没有太多人关注这个话题了。

虽然今天Docker仍然是容器应用开发的首选平台，但影响力已经和Kubernetes无法相比，Docker早就没了当年与Kubernetes竞争容器“一哥”的气势。相比Docker的落幕，Kubernetes现在可谓如日中天。而Kubernetes从无到有，到战胜Docker（Swarm）、Mesos（Marathon）等一众对手，最后成为容器编排领域的事实标准，这一路走来其实也并不容易。Kubernetes能有今天，不仅仅是因为有一个“好爹（Google）”，其中也有不少偶然。本文带您回顾Kubernetes是如何一步步赢得了这场容器霸主之战。

01 Docker横空出世

2010年，对中国的大多数IT人而言，云计算还是停留在概念认知阶段，中国第一家公有云厂商阿里云的首个云服务刚宣布公测，而此时在大洋彼岸的美国云计算市场已经初具规模。经过4年的发展AWS已经站稳脚跟，云服务已经被很多企业认可，IaaS之外PaaS服务也开始出现在市场。这一年，刚满25岁的Solumon Hykes在美国旧金山创立了一家名为dotCloud的公司，主营业务正是提供公有云PaaS。

PaaS平台需要为应用程序的开发、部署和运行提供一个适当的环境，因而必须解决应用的打包和部署问题。在Docker出现之前，要让应用程序在不同PaaS平台上运行或者支持不同运行平台，用户必须为每种语言、每种框架，甚至每个版本的应用维护一个文件包。这个打包过程没有统一的规定，更麻烦的是，明明在本地运行得好好的应用，放到PaaS平台还需要做很多代码修改和配置调整才能运行起来，换个平台还得再来一遍。

这也是dotCloud当时必须面对的问题，dotCloud的办法是用Linux容器技术LXC来快速部署软件。为了方便创建和管理这些容器，dotCloud开发了一套内部工具，这就是后来的Docker。

虽然dotCloud拥有了创新的容器技术，但受限于公司的知名度和PaaS的整体市场规模，其业务并没有太大起色。2013年3月，dotCloud聘请了新的 CEO，将公司更名为Docker，并开源了其容器技术，将其正式命名为Docker项目。Docker就这样诞生了！

开源后的Docker备受欢迎，迅速在全球得到普及，dotCloud从一家纯粹的PaaS公司转型成为一家名为Docker的容器平台公司。在接下来的两年中，Docker公司筹集了1.9亿美元。一颗IT行业新星正在冉冉升级，Docker俨然就是第二个VMware。

02 Docker的技术创新

Docker是一个开发、交付和运行应用程序的开放平台，开发者可以在此打包他们的应用及依赖到一个可移植的容器中，然而发布到运行平台上。容器技术并非Docker首创，从2008年开始Linux内核已经提供了对LXC的支持，LXC就是一种容器技术。LXC允许进程运行在一块相对独立的空间，并且能够方便地对它们使用的资源（计算、网络、存储）进行调度。

在Docker走红之前LXC已经在一些公司内部得到应用。比如，2008年Google推出的PaaS平台 GAE（Google App Engine）就采用了LXC。在GAE中Google使用了一个能够对LXC进行编排和调度的工具Borg——后来Kubernetes借鉴了它的很多设计。同样，云原生概念的提出者、PaaS平台提供商Cloud Foundry也推出了一个名为Warden的容器技术，它是一个对LXC 的封装。

不过，整体而言LXC的应用范围不广，主要是一些有技术实力的大公司在应用。LXC虽然解决了应用的隔离，但并没有解决可移植性问题，而这个问题被Docker完美地解决了。Docker有三个最重要的概念：镜像、仓库、容器，其中镜像是基石，也是Docker最重要的创新。

Docker的镜像定义了一个将应用打包的规范，它将应用所有依赖都封装到了一个简单对象里，这就是镜像。镜像可以被部署到任意一台能运行Docker的机器，并且在启动Docker的实例之后，它能够确保应用的执行环境与之前所定义的完全一致。因为Docker为这些机器的配置（如网络、存储、日志、Linux发行版本等）定义了一个抽象层，它使得相同的Docker容器能够运行在多个不同的主机上，并且按照指定的配置。

不过，Docker只是满足了应用软件生命周期中的一部分需求，随着越来越多的企业开始采用Docker技术来开发和部署应用，特别是要规模化部署应用，它们发现自己面临一个现实的问题，就是要对多个容器进行编排、管理和调度。而Docker只能解决应用的打包、交付和部署，不能对容器进行调度和管理，特别是保证容器之间的相互依赖关系。就在这个时候，Google带着Kubernetes下场了。

03 Google下场

Google是云计算概念的最早提出者，声名显赫，有强大的技术实力和资金实力，不仅有PaaS平台GAE，还有Google云GCP（Google Cloud Platform），但提到云计算人们首先提到的却是AWS，Google的存在感很弱。如何提升Google在云计算市场的存在感？Google从当时大火的容器市场看到了机会。

Google对容器并不陌生。Google的业务从搜索（Google Search）起步，后来延展到众多业务，如Gmail、YouTube、GCP等，都属于海量规模的在线业务。为了尽可能利用服务器的计算能力，很早就开始尝试容器技术，并为之研发了名为Borg的集群管理系统，该系统管理了成千上万个任务，大大提高了计算效率。

多年运行GCP和Borg的经验，使得Google非常认可容器技术，也深知目前Docker在规模化使用场景下的不足。如果Google率先做好这件事不仅能让自己在云计算市场找回久违了的存在感，而且这里也存在一些商业机会。比如，如果容器得到广泛应用，那些在AWS运行的应用就有可能自由地移植到GAE和Google云上运行，这对于Google的云计算业务无疑是有利的。

2013年夏天，Kubernetes联合创始人Craig McLuckie和Kubernetes联合创始人Joe Beda、Brendan Burns等开始讨论容器编排系统的开发，并决定采用开源的方式来开发这个系统。刚开始，开源的想法并没有被Google高层认可，但几个创始人坚持认为开源是容器编排框架最佳的方式。被拒绝之后，几个创始人并不死心，多次找机会向Google高层游说。最后，这个项目终于被Google批准开源了。

项目最初在Google内部代号为Project Seven（灵感来自电影《星际迷航》），这也是Kubernetes Logo是7条边的原因，而“Kubernetes”这个名字来源于几个创始人讨论项目名时正在驾驶途中（Kubernetes原意为舵手）。

说服Google的管理者很不容易，Google的高层一开始认为没必要开源，担心竞争对手从中受益。从最早提出Kubernetes这个项目到最后Google批准用了差不多6个月时间，而从公司批准项目到开发出产品原型，并首次在2014年6月举行的DockerCon 2014大会上正式发布才不过3个月（当然，在此之前做了一些工作）。

现在看来开源的确是一个非常正确的决定。2021年7月，笔者曾采访过Craig McLuckie和Joe Beda，当时两位都已经到VMware工作。Craig McLuckie任VMware应用现代化业务部门研发副总裁，Joe Beda担任VMware首席工程师的Joe Beda。谈到这一段经历时两人都认为，Kubernetes是在正确的时间做出的正确的创新，而选择开源是Kubernetes后来能成功的最重要原因之一。项目开源之后，Google的工程师可以与众多优秀的工程师一起共事，实时了解Kubernetes在使用中的问题，并迅速做出反馈，这样形成良性循环：才华横溢的工程师所做的工作促使更多人对这个项目有兴趣，进而加快了迭代的速度。

04 容器编排混战

实际上，当时并不是只有Google看到了容器市场的新需求，就在DockerCon 2014大会上，就有多家公司推出了自己的容器编排系统，而Google的进场让原本就竞争激烈的容器编排市场火上浇油。

除了Kubernetes外，当时在容器编排市场有影响力的还有Docker、Mesos。Docker携其在容器引擎市场的巨大成功，进入容器编排领域是顺利成章。Docker并不满足于仅仅只是一个容器引擎平台，虽然 Docker项目备受追捧，但终究还是停留在开发和交付层面，企业最终要部署的还是网站、服务、数据库，是云计算业务。Docker希望提供更多平台层能力，向PaaS进化，这才是Docker的目标。

2014年7月，Docker收购Orchard Labs正式开始涉足容器编排领域，Orchard Labs的容器编排工具fig当时很有名，这个fig就是Docker Compose的前身。Docker Compose虽然能编排多个容器，但是只能对单个服务器上的容器进行操作，而不能实现在多个机器上进行容器的创建和管理。

如果说此时Docker的Compose和Kubernetes还不算正面竞争的话，那么2015年初Docker发布Swarm，则是正式向Kubernetes宣战了。Docker Swarm可以在多个服务器上创建容器集群服务，而且Docker Swarm与Docker平台中的许多安全功能集成，如密钥管理。在容器规模较小的场景下，许多用户更喜欢使用Docker Swarm，因为它平滑地内置于Docker平台中。如果Docker Swarm能成功，那Docker就将通吃容器市场，从应用的开发、交付到应用的编排和管理、监控等，这就和一些公司产生了利益冲突，比如CoreOS、Red Hat等，这为Docker后来的败退埋下了伏笔。

在Kubernetes的成长过程中，CoreOS发挥了重要作用。CoreOS是一家基础设施领域的公司。其主打产品是一个操作系统，用户可以按照分布式集群的方式，管理所有安装了这个操作系统的节点，从而使用户在集群中部署和管理应用就像使用单机一样方便。Docker容器发布以后，CoreOS将这一技术集成到自己的操作系统中，2014年发布了自己容器编排框架fleet，这是最早提供云环境自动部署和调度集群资源的容器软件之一。Kubernetes出现后，CoreOS放弃了fleet而转向了Kubernetes，后来它推出了容器运行时rkt来替换Docker的容器运行时RunC。2018 年1月30日，红帽斥资 2.5 亿美元收购了CoreOS。

在Kubernetes项目中，红帽是仅次于Google的重要角色。红帽的OpenShift是最早一批PaaS平台（2011年发布，和Cloud Foundry同一年）之一。2013年9月，Docker大火的时候，红帽将Docker嵌入到红帽Linux企业版RHEL中，并完全重建了OpenShift。作为一个PaaS平台，也需要容器编排功能，红帽需要选一个。

这个时候Kubernetes项目还在Google内部酝酿，听到这个消息红帽之后非常感兴趣，但Google迟迟无法敲定是否开源。等了太长时间以后，红帽几乎已经对这个合作不抱希望，正准备和Mesos合作。就在这时，Google传来消息说同意开源，红帽得以在最后时刻选择了Kubernetes。红帽的加入为Kubernetes项目的成功奠定了非常坚实的基础。如果当时的红帽选择的是Mesos，今天我们看到的会不会是另一番结果？

2015年6月，OpenShift Enterprise 3在红帽峰会上发布，其中内嵌了Docker和Kubernetes，这给Kubernetes后来的成功打下了非常好的基础。

Mesos是容器编排市场上另一个主要玩家。Mesos最初是加州大学伯克利分校的一个项目，目的是创建下一代集群管理器，一直在努力提高集群的利用效率和性能。作为一个面向资源管理的项目，容器编排其实只是其中的一个功能模块，叫Marathon。

Mesos在2014年成为首批支持Docker容器的容器编排框架之一。实际上，Mesos并不关心谁会在它的基础上运行。Mesos可以为Java应用服务器提供集群服务，也可以为Docker容器提供编排能力。当时，Mesos的最大优势是它在运行关键任务时的成熟度，它比其他许多的容器技术更成熟、更可靠，因而被Twitter、苹果（Siri）、Netflix等公司所采用。2015年Kubernetes 1.0刚出来时也只具有管理100台服务器的能力，而当时的Mesos已经有管理上万台服务器的成功案例。但是，相比Docker与Kubernetes，Mesos侧重在传统的资源管理，不如前两者天生是面向多云和集群的，它在应对多云和集群管理时面临很多挑战。后来的Mesos项目发展也并不好，其标杆客户Twitter最后也放弃了Mesos改用Kubernetes。

05 Kubernetes的后发优势

与Docker Swarm和Mesos等容器编排框架相比，Kubernetes虽然出道晚，但后发优势明显。Kubernetes脱胎于已经在Google内部运行了多年的Borg项目，但并没有直接延用Borg，而是在这些宝贵经验的基础上从零开始设计，使得其能采用最先进的设计理念而没有任何历史包袱。

Kubernetes设计了一套稳定可扩展的API接口、预置服务发现、容器网络、及可扩展等关键特性。其概念抽象非常符合理想的分布式调度系统。实际上，Kubernetes的一个成功之处就是提供了一个规范，可以让你描述集群的架构、定义服务的最终状态，由它来帮助你的系统达到和维持在这个状态。其开放的架构从API到容器运行的每一层，为开发者暴露出可以拓展的插件机制，鼓励用户通过代码的方式接入到Kubernetes项目。这个机制催生出了大量基于Kubernetes API的创新，壮大了生态。

和Docker、Mesos相比，Kubernetes强大的生态为应用程序开发人员提供了丰富强大的工具，用于编排无状态的Docker容器，让开发人员减少了对基础设施和操作团队的依赖。ISV也喜欢Kubernetes，因为它提供了一种简单的方式来支持容器迁移，并为运行自己的Kubernetes提供了一个商业解决方案。

另外，Kubernetes作为CNCF下的开源项目，使得它与Docker相比更容易得到认可和支持，因此，Kubernetes从一发布就引起了广泛关注，迅速在业界推广开来，其势头丝毫不亚于当年Docker的火爆。这一点与Docker形成了对比，Docker后来将Swarm全部内置到Docker项目当中——这也是Swarm项目几乎唯一的优势，和Docker项目的无缝集成可以实现优势最大化的方式，但项目的复杂度和封闭限制了其后来的发展。

06 成立CNCF基金会

2014年6月，Kubernetes在DockerCon 2014公开亮相之后，Kubernetes受到广泛的关注，但也有不少人担心Kubernetes的开源策略。因为虽然Kubernetes是开源，但项目的实际控制权仍然在Google。比如，项目参与者要签版权协议，仍然是谷歌的版权，而一些大公司并不愿意自己的员工签署这样的协议。

为了让Kubernetes项目被更多人接受，Google、红帽等共同发起成立了CNCF（Cloud Native Computing Foundation）的基金会，希望以 Kubernetes 项目为基础，建立一个按照开源基金会方式运营的开源社区，来对抗以Docker公司为核心的容器商业生态。

2015年7月，Kubernetes 1.0发布，CNCF也同时正式成立，Kubernetes被正式移交给基金会管理，这就为Kubernetes的腾飞扫清了最后的障碍。

眼看着Kubernetes做得风生水起，Docker也努力试图挽回败局。2015年6月，由Docker牵头，CoreOS、Google、红帽等公司共同宣布制定一套容器和镜像的标准和规范，这就是OCI（Open Container Initiative），Docker还将自己容器运行时Libcontainer 捐出，并改名为 RunC 项目，交由Linux基金会管理。

OCI的提出意在将容器运行时和镜像的实现从Docker 项目中完全剥离出来，这样做可以改善Docker公司在容器技术上一家独大的现状，为其他玩家不依赖于Docker项目构建各自的平台层能力提供可能。正因为此，Docker没有很积极推进OCI。

显然，这并不是Kubernetes这一方希望看到的，他们更希望把Kubernetes定义为一个容器编排框架，而Docker作为其中的容器引擎，Kubernetes同时还想支持其他的容器引擎。为此，2016年12 月CNCF发布了CRI（Container Runtime Interface，容器运行时接口），直接目的就是要支持CoreOS 的容器运行时项目rkt。当时为了支持rkt要写很多兼容的代码，为了避免后续兼容其他运行时带来的维护工作，所以发布了统一的CRI 接口，这样以后凡是支持 CRI 的运行时，皆可直接作为Kubernetes 的底层运行时。

CRI刚发布时，考虑到Docker的江湖老大地位，Kubernetes这一方做了妥协，自己开发了一个插件Dockershim，由它来对接Docker运行时，而另外两个运行时（CRI-O和CRI-Containerd）完全符合CRI标准，无需额外的代码。显然，Dockershim只是一个折中的方案，是CNCF不得已而为之，随着Kubernetes势力的壮大，就有了2020年12月Kubernetes宣布将在Kubernetes 1.2版中去除掉Dockershim，不再负责维护Dockershim，这被一些媒体解读为Kubernetes将放弃Docker。实际情况不是Kubernetes要放弃Docker，只是不再给予Docker特别待遇。

07 Kubernetes一统天下

几个回合下来，Docker在与Kubernetes的竞争中逐渐落败。虽然Docker仍然拥有庞大的用户群，在开发和交付中Docker仍然得到广泛使用，在小规模的容器部署时也能使用Docker套件来满足所需，但在生产环境特别是大规模的生产环境中，Docker的话语权越来越弱，慢慢沦为Kubernetes生态中的一个组件，而且是一个可以随时被替换的组件。

到2016年CRI推出时，这场容器大战形势已经趋于明朗。到2017年10月的DockerCon 欧洲大会上，Docker官方正式宣布支持Kubernetes，决定将在自己的主打产品 Docker 企业版中内置 Kubernetes，这意味着容器编排领域的争夺正式落幕。

此时，Kubernetes已经得到了广泛认可，各大厂商都开始拥抱Kubernetes，包括AWS、Microsoft Azure、VMware等。其中AWS更是具有标杆意义，此前它对Kubernetes的态度并不明确，AWS有自己的容器服务ECS（Elastic Container Service），支持在EC2实例里运行Docker容器。到2017年年底AWS的Re：Invent大会终于宣布支持Kubernetes，并于2018年6月正式推出了EKS(Elastic Kubernetes Service)。

到2017年年底，CNCF 达到170个成员和14个基金项目。到2018年，CNCF成立三周年时已经有了195个成员，19个基金会项目和11个孵化项目，如此之快的发展速度非常罕见。

随着Kubernetes的节节胜利，Docker做出了最后的努力。2017年3月，Docker公司将Docker项目分为社区版（Moby）和企业版（Docker），以此来探索商业化之路，但是引发社区不少抱怨。

2018年 3 月 28 日，Docker 的灵魂人物、CTO Solomon Hykes 宣布辞职。

2019年11月，Mirantis收购了Docker的企业部门，该业务部门包括 Docker Enterprise 技术平台及所有相关的知识产权、约400名员工中的300人、750家企业客户以及所有企业伙伴关系。至此曾经纷纷扰扰的容器编排大战终于尘埃落定，Kubernetes成为了最后的赢家。继虚拟化之后，云计算的新篇章——云原生技术时代正式开启。

08 写在最后

Docker以一个创业公司之力，以创新性的技术通过开源社区取得了巨大的成功之后，独自对抗Google、红帽乃至整个云计算产业的压力，最后以失败收场，令人唏嘘。

Docker一度被认为是第二个VMware。当年VMware从虚拟化技术起步，从一个创业公司经过20多年的发展成为当今虚拟化的霸主和云计算领域的领导厂商，成为不少创业者的榜样。然而，以和虚拟化技术相似的容器技术起家的Docker，最终没能复制VMware的命运，其发展经历也值得人们复盘、研究。

不过，站在产业的视角，容器技术在短短几年间深入人心，推动云计算产业从虚拟机时代迈向容器云时代，成为云原生技术的基础，这是技术创新者的骄傲。正如Kubernetes几个创始人多次提到的，没有Docker就没有Kubernetes，因此Docker也应该为Kubernetes的成功而骄傲。在IT产业的发展史上，Docker应该有自己浓墨重彩的一笔！

【云数科技圈】 科技自媒体，长期关注行业数字化、ICT基础设施技术，致力于提供有知识的新闻报道和行业洞察。更多文章可以关注同名公众号。