代码英雄之容器德比：一场严肃的国际化比赛

英文音频配上此文一起收听观看效果更佳哦，点击“阅读原文”聆听更多代码英雄故事。

出品 | CSDN（ID：CSDNnews） | 红帽原创音频

这是代码英雄第二期，容器德比。上一期（第一期：代码英雄之操作系统之战）我们见证了开源操作系统的崛起。在本期栏目中，我们会追溯容器技术崛起的历史，通过支持全新的没有束缚的工作，讲述容器技术如何进一步扩展开发者的角色。然后我们会一起见证容器标准化是如何奠定这场比赛的基础，走向容器编排的。这是一场严肃的比赛，也是一场国际化的比赛，吸引了行业里最快，最强大的玩家。他们都准备好了为冲刺终点线而奋力一搏。准备好了吗? 比赛开始了！

您有看过赛马吗? 在刚开始的时候，参赛的马排成一行，用爪子刨着脚下的土壤。这就是你可以想象的画面。不同的是，这里不是赛马场。而是科技世界的角逐。那么这场比赛中有什么看点呢？是怎样的奖励，才会让这些参赛者们咬紧牙关，寸步不让? 这是一场关于掌控容器编排技术的竞赛。重要的是，不同于其他的比赛，获胜的一方，不仅仅会是今天的冠军，更有可能在将来持续领先。

横空出世的容器

和大多数人所认为的不同，Docker并不等同于容器（Container），容器（Container）技术其实早在多年前就出现了。从2005年的Solaris Containers到2008年LXC 0.1版本的推出。再到后来的Google推出开源的容器管理工具lmctfy，也将近经历了10年的发展。直到2013年，一套新的以容器技术为核心的思想和一套标准化体系——Docker的出现，才代表着容器技术一个新的时代的来临。

一个容器实际上就是一个进程，容器是把一切打包到了一个整洁并且可以迁移的包中， 这就像任何其他的进程一样。不同的是，容器有着非常严格的世界观。比如，如果你准备开始用一个容器，进程会授予其本身的根目录，然后你会认为自己在查看整台计算机的整个根目录，但实际上你看到的只是这个文件系统很少的一个子集。通过将其所依赖的执行文件打包，容器可以在任何笔记本或者云中的虚拟机上运行。这是因为，容器是将它本身的执行文件和它本身的函数库和变量都一股脑的打包到了容器中。所以，这是一个很有魔力的部分，一个容器可以在不同的环境中都通过一样的方式来运行。这也就意味着开发者可以轻松地分享协作应用开发，而不用担心典型的计算机之间相互不兼容的问题。

举一个类比的例子也许能够帮助你更好的理解容器。比方说，有一家公司可以给客户上门配送按照菜谱卡片精心搭配好的一切做饭所需要的食材。如果该公司所能带给你的不仅仅只是这些还没有处理过的食材，而是一整个厨房，有煤气灶，还有所需要的全部餐具，一切都会装到一个小盒子并放在你家门口，这就是一个容器。

许多人都认为容器是某种轻量级虚拟化，轻量级的虚拟机，事实上并不是。容器与虚拟机有很大不同，一台虚拟机有一整套操作系统，然而容器是分享一个操作系统的，所有在同一个计算机上的容器可以分享同一个操作系统。

最后一点，容器和虚拟机可以并肩工作。容器不能替代虚拟机。虚拟化技术仍然可以增加系统的效率，并且对于整合服务器非常关键。随着容器技术的兴起给我们创造了前所未有的机会。不妨这样想，如果我们全部依靠虚拟机的话，运行所有这些仿真服务器，这将产生大量额外的工作负担。一台虚拟机的大小至少是以G为单位的，然而一个容器也就只有20M左右。一台虚拟机可能会需要若干分钟来启动。对于基于网页的应用来说这可不是一个好消息。相反，一个轻量级，更快速的类似容器的虚拟机替代方案更加实用。

回顾历史，1979年出现了一种容器原型。开发者们尝试使用 Unix V7 来设计根系统调用，从而可以使环境只包括特定的程序。这方面的突破带来了我们现在看到的容器技术。另一个巨大的进展来源于2008年的 Linux 容器技术。现在，我们有了运行系统级的虚拟化技术。我们终于可以仅仅使用一个单独的Linux内核就可以运行多个容器，而不是一定需要使用完整的虚拟机。这也就意味着基础架构的成本逐渐减少，但不是每一个人都能立马看到容器技术的潜力。

Docker的诞生

作为容器技术目前的代表，Docker公司位于旧金山，由法裔美籍开发者和企业家 Solumon Hykes创立。Docker公司起初是一家名为dotCloud的平台即服务（Platform-as-a-Service, PaaS）提供商。底层技术上，dotCloud平台利用了Linux容器技术。为了方便创建和管理这些容器，dotCloud开发了一套内部工具，之后被命名为“Docker”。Docker就是这样诞生的！

但Docker诞生之初，dotCloud 的PaaS业务并不景气，公司需要寻求新的突破。于是他们聘请了Ben Golub作为新的CEO，将公司重命名为“Docker”，放弃dotCloud PaaS 平台，怀揣着“将 Docker和容器技术推向全世界”的使命，开启了一段新的征程。

这段新旅程的开始，就是Docker伟大的构想，即要实现“Build，Ship and Run Any App，Anywhere”，即通过对应的封装（Packaging）、分发（Distribution）、部署（Deployment）、运行（Runtime）生命周期进行管理，达到应用组件“一次封装，到处运行”的目的。应用组件既可以是一个Web应用、一个编译环境，也可以是一套数据库平台服务，甚至是一个操作系统或集群。Docker提供了高效、敏捷和轻量级的容器方案，并支持部署到本地环境和多种主流云平台，也是首次为应用的开发、运行和部署提供了“一站式”的使用解决方案。

实际上，容器（Container）非常像我们在现实世界中经常看到的“集装箱”，而承载这些“集装箱”的“港口”就可以看做是云的服务商，“集装箱”的“拖船”可以看做是云服务所提供的IaaS服务。Docker公司的Docker Machine之类的可以看做是一种“集装箱”的“吊装设备”。当然，作为一套推动全球经济快速运转的航运体系，不仅仅只有这些，还有无数的基础设施，包括高速公路，集装箱的拖车，将货物装入集装箱的叉车，搬运工人。另外，还有一套软的设施，包括各类的标准，集装箱的交付流程。所有的这些，我们都可以从IT世界里面的看到他们的身影。

2013年Docker的出现是一个标志性的节点。它提出的Build，Ship，Run的概念，将容器技术向IT产业链条的上游和下游进行了延伸。从软件的使用领域，延伸到了软件的生产领域，以及软件的发布领域。同时借助于容器技术，打通了DevOps，极大的提高了软件领域的生产率，从而获得了众多企业的青睐。

如今Docker公司被普遍认为是一家创新型科技公司，据说其市场价值约为10亿美元。Docker公司已经通过多轮融资，吸纳了来自硅谷的几家风投公司的累计超过2.4亿美元的投资。

“容器化真的是一个天才般的想法，而且这个想法是前所未有的”，CloudBees技术总监 Laura Frank说，“只有少部分人了解来龙去脉并且可以运用容器技术。相信随着时间的推移，越来越多的人会接触到容器技术，随着越来越多的人开始使用，并且技术团队和组织通过社区普及容器知识，容器技术会变得愈发实用。”

Dot-com 1.0是一家在线零售商，它们有上千台物理机，“我们用不同的方式在所有这些不同的服务器上一遍又一遍地安装相同的软件。当你从比较原始的操作系统迁移到虚拟机，然后再到Linux 容器、Solaris 容器，同样的问题一再出现，你仍然不得不在不同的虚拟机之间来管理部署环境。本质上来说，是构建仿真的操作系统。” 红帽资深容器策略顾问Scott McCarty描述了容器对于Dot-com 1.0的改变。“比如，有了很多非常标准化的方式可以去处理现在这些打包好的应用，我认为容器技术的出现从根本上改变了一切。非常容易使用而且还不会造成损害，同时相比于虚拟机更加小巧快捷。”

借助Linux容器带来的进步，这些新的开源项目和社区使得开发者们可以更好地携手合作。很多我们之前的担心都一扫而光。突然间，容器和由它促进的微服务变得十分有吸引力。一旦一种共同的容器语言出现了，障碍会消失，与此同时容器技术改变了我们的工作方式。容器技术也加快了我们学习新技术的步伐。

在一个有容器的世界，程序不能随处运行的问题将不复存在。相比于我们之前使用的标准的操作系统，开发者社区见证了容器是如何变得更加快速，容易使用，成本低廉。容器技术目前的采用率十分惊人。但是要记得：容器标准的出现仅仅是容器编排这场竞赛的热身。真正的战争才刚刚开始。

赛马已经整齐排列好，随着信号枪一声令下，会为了这场比赛的冠军而拼尽全力。不只是为了容器本身，更是为了我们会部署和管理所使用的工具。

容器编排之战

在这场标准容器编排竞赛中，哪位会胜出成为管理所有容器的平台呢？

起初有两位竞争者已经处于领先地位。由Apache、Swarm、Docker驱动的Mesos。还有另一位黑马——谷歌的出现改变了格局。Linux设立了云原生计算基金会（CNCF），随后CNCF 推动了谷歌开源的编排引擎Kubernetes。

现在来看，是否Mesos和Swarm已经领先Kubernetes ？它们由Apache和Docker支持，已经具备丰富的参赛经验。但是Kubernetes有其他的“赛马”所不具备的优势。红帽负责Kubernetes和OpenShift的架构师Clayton Coleman将会讲述这里成功的秘密。

“从Kubernetes诞生之初，谷歌就很擅长发起开源项目，并降低项目贡献和参与难度。同时为了让开发者和运营人员更加容易开展工作，谷歌十分专注于创新。我觉得 Kubernetes 和围绕着Kubernetes的社区有助于更好地的发现机会，而且大部分人都可以参与解决难题和极端用户案例。”Clayton说。

刚开始的时候，来自于红帽、CoreOs和谷歌的工程师们都参与到了Kubernetes的开发中。随着Kubernetes开发到1.0，不管是创业公司还是大公司都参与其中，一起构建和完善。关键的是，所有这些增长从来都不是只归功于谷歌或者任何一方。

以Linux为例。Linux并不是始于Linus开始编写内核，然后在用户空间告诉所有人，如何写GCC，如何去建立NGINX或者Apache。相反，内核团队专注于建立一个有效的核心运行系统，和其他诸如GNU项目的开源社区，从而持续带来其他从Unix 到Linux的工具。因此，许多我们如今所使用的工具，很多都不是来自于Linux核心团队交付的。

“但是Linux作为一个整体，相比于内核要宽泛得多，而且我认为这种模式是Kubernetes之所以可以取得现在成就所依赖的优势。随着我们开始建立社区并且聚焦于扩展Kubernetes，我们试着从一个核心Kubernetes的角度来考虑它，一个分布式集群操作系统的内核。”Clayton说。

实际上，在开源世界建立社区的过程中，Kubernetes 已经很好的证明了自己。正如我们在操作系统之战中谈到的Linux崛起一样，现如今这场关于容器的战争中，获胜者往往是懂得如何借助社区力量的。事实上，尽管谷歌可能是最早开发Kubernetes的，但目前属于每一位开发者并由云原生计算基金会（CNCF）管理。在GitHub上，Kubernetes有大约3万的收藏数，相对来说，Swarm和Mesos只有数千。这已经很说明问题了。这就是通过社区、同时也是为了社区而开发的技术。

而在这里，谷歌的态度就显得非常重要：一个如此庞大并且以效益为导向的大公司是怎么做到如此擅长跟其他社区开发者合作的呢？谷歌在分布式系统领域具备丰富的经验，还运行着分布在世界各地的许许多多的服务器，因此似乎在Kubernetes开发方面有着很大的优势，并且有信心一定能在这场容器竞赛中胜出。那么，当谈到Kubernetes和开源之间的关系时，谷歌是如何看待这种关系的？

“我想当谈到基础架构工具，甚至编程语言时，是没有什么选择的。你不可能拥有专有工具，即使它很棒。如果不是开源的，大多数人可能甚至都不会想去了解。而且我认为开源也是大多数人会采用像Kubernetes这样的基础架构工具的原因，你可能会说，好吧，我们就要坚持使用这个版本四五年，或者我们需要根据自己的一些独特需求来进行修改。一旦走到这一步，就很难说服企业走上正轨，‘嘿，每台服务器的价格是200美元，但是你看不到源代码，所以有需要的话也必须等我们来修改。’那样的日子一去不复返了。所以我不确定是否真的可以在没有开源的情况下建立基础架构。开源的另一点是可以加入社区，就这点而言我认为 Kubernetes是个特例。” 谷歌容器技术支持Kelsey Hightower说。

我们回到竞争这个话题。正如你所提到的不仅仅有Kubernetes，还有Docker的Swarm，还有Apache的Mesos ......

Kelsey Hightower表示：“当人们谈论容器竞赛时，我不确定是否只是在Mesos和Docker之间，我认为竞争也可能存在于那些看起来一无所有的人之中。是的，可能你的来源只是Bash的脚本，而且你仍然在尽力去争取想要达到的目标。还没有使用容器编排工具的一方比已有选择的一方，市场要大得多，比方说Mesos或Swarm。”

这就是容器战争存在并将继续的原因，真正的关键点在于如何帮助终端用户。Mesos、Kubernetes或Docker Swarm是否会成为寻求更好解决方案的人们的首选？这一切都还悬而未决，但对于这个领域的工程师来说，如果把营销和供应商先暂时放在一边，应该是“尽管是不同的公司，但是我们都是同一个团队的。”

事实上，Mesos和Kubernetes的支持者们，为彼此开发了许多工具，最终以某种方式出现在其他产品中。我们没有理由说，“哦，这是使用Mesos的人正在做的事情，那就忽略吧。这有点愚蠢。所以从技术和社区的角度来看，我们需要对这些想法进行交流。同时也需要竞争来迫使我们都可以进行独立思考，然后最好的想法就会浮出水面，接着我们再选择采用哪种方式来满足目标用户的需要。”Kelsey Hightower说。

因此，就这场竞赛而言，仍处于初期阶段，而且这个事情本身不会带来利润。Kubernetes更像是一个平台游戏，对所有人开放，然后用户会选择满足他们需求的那个，这就是Kubernetes在社区方面做得很好的地方，真正开放，真正能解决实际问题。

容器和编排的未来

那么，容器和编排的未来，可能就会是Kubernetes吗？

至少Kelsey Hightower是这样认为的，所以当他在KubeCon上发表主题演讲的时候，他说所有这些工具都很棒。就像是乐高积木。除了Kubernetes，开发者还可以选择一种产品用于安全，选择另一种产品用于网络，但最终，作为开发人员而言，所想要的只是测试并希望代码可以某种方式以呈现在客户面前。而认为Kubernetes还有容器都会成为基础设施，或只是用于无服务这种更高层级平台的组成部分。

在容器的支持下，任何代码都可以在容器中打包并为任何开发者所用，并且不需要公开这些代码。因此，在未来，随着Kubernetes变得普遍，容器的战场将不再只是大大小小的供应商，更会出现许许多多希望自己来做的人，直到他们能够提供云服务的竞争者才可以做的事情。

2017年秋天，Docker宣布支持Kubernetes，但这并不是说就Docker就放弃了Swarm，而是Docker决定与容器编排竞赛的获胜方和解。其实，Docker并不孤独，Azure和AWS都宣布了对Kubernetes的支持。与此同时，像OpenShift这样的Kubernetes发行版仍在不断发展。我们得到的是一个核心Kubernetes，可以扩展和支持新的用例，如微服务或持续集成项目。

“这个生态系统按照Linux模式发展，就会以最好的方式运行，我认为我们正朝着这条道路迈进。因此，就像所有优秀的开源项目一样，相对于单打独斗，让每个人都能够参与进来就成功了。”Clayton说。

“所有这一切都在快速发生着。毕竟，这是一场竞赛，而这正是我们期望能从开源中获得的。在我们才刚刚理解什么是容器时，第一轮几乎就结束了，回想一下两年前，容器镜像格式还是一个巨大的战场，然后回到六个月至一年前，容器编排成为了下一个巨大的战场。紧接着，如果你看看2017年的KubeCon及随后几周，几乎每个主要供应商都宣布支持 Kubernetes。因此，很明显Kubernetes在这一点上获胜了。“来自红帽的Scott McCarty说，“因此，Kubernetes已经成为标准，好的是现在的应用定义已经标准化了。因此，任何人都可以在这些YAML文件中使用Kubernetes对象并定义应用，这就是我们共同所追求的，处理大型扩展系统，我已经等了20年。”

这就是关于容器竞赛的故事。就像容器技术的开始一样迅速。Kubernetes的成功看起来实至名归，但即使在竞赛结束后，我们仍然会心存疑问。容器是否会成为未来几年的默认选择？是否会促使更多的云原生开发？而之后的转变将带来的工具和服务又会是什么？我们目前知道的就是上面讲到的这些。通过CNCF，社区将继续改进Kubernetes，并根据它的使命，我们将建立一套全新的容器技术。

容器已经催生了大量新的基础设施，伴随而来的是全新的服务的需求。举个例子让你感受下容器变成什么样，变得有多快，比如 Netflix每周推出超过一百万个容器。毫不夸张得说，容器就是建筑未来的基石。

容器是开源运动中最重要的里程碑之一。具有很好的迁移性，易于扩展。容器技术很好地体现了开源的优势，开源项目也推动了容器技术的发展。这是一个全新世界，我们不用再担心从不同计算机之间或者云间的迁移。

容器的标准化发生得比任何人预测的都要快。接下来的一集，我们将转向另一场战争。云间战争已打响。微软、阿里巴巴、谷歌和亚马逊四家云供应商的摩擦正在升温，随之而来的将是一场暴风骤雨。我们将会和广受欢迎的几位代码英雄一起探讨云间战争。

代码英雄（Command Line Heroes）是红帽的原创音频播客。有关该播客和其他更多信息，请访问RedHat.com/CommandLineHeroes。在那里，您可以关注、免费听取最新内容，也可订阅该节目。

推荐阅读：代码英雄：波澜壮阔的操作系统之战（音频+长文）

 点击“阅读原文”，聆听更多“代码英雄”故事！