《代码英雄》第一季（5）：容器竞赛
容器 代码英雄

> 
> 代码英雄讲述了开发人员、程序员、黑客、极客和开源反叛者如何彻底改变技术前景的真实史诗。
> 
> 
> 



> 
> **什么是《代码英雄》**
> 
> 
> <ruby> 代码英雄 <rt>  Command Line Heroes </rt></ruby>是世界领先的企业开源软件解决方案供应商红帽（Red Hat）精心制作的原创音频播客，讲述开发人员、程序员、黑客、极客和开源反叛者如何彻底改变技术前景的真实史诗。该音频博客邀请到了谷歌、NASA 等重量级企业的众多技术大牛共同讲述开源、操作系统、容器、DevOps、混合云等发展过程中的动人故事。
> 
> 
> 


![](/data/attachment/album/202008/21/000308a577z40hqta5qhpg.png)


本文是《[代码英雄](https://www.redhat.com/en/command-line-heroes)》系列播客[第一季（5）：容器竞赛](https://www.redhat.com/en/command-line-heroes/season-1/the-containers-derby)的[音频](https://dts.podtrac.com/redirect.mp3/audio.simplecast.com/3aed4d5c.mp3)脚本。



容器的兴起为开发者们打开了一道新的大门，它简化了在机器与机器之间传递项目的成本。随着它变得广受欢迎，一场大战也悄悄拉开帷幕。这场战斗的奖品是容器编排的控制权，参赛者包括这个行业最快最强的玩家。


容器是开源运动中最重要的一项突破之一。在这一集里，特邀嘉宾 Kelsey Hightower、Laura Frank 和 Clayton Coleman 将告诉我们容器如何为未来添砖加瓦，以及编排技术为何如此重要。


**Saron Yitbarek**：


你有看过赛马吗？赛马们排成一行，蹄子刨着脚下的土壤。你可以想象出这么一副画面。比赛即将开始，在这些竞争者中脱颖而出的将是优胜者。


**00:00:30**：


不同的是，比赛的不是马。而是科技世界的诸侯。那么是什么让比赛如此重要？是怎样的珍贵的奖励，才会让这些参赛者们排着队，迫不及待地想要得到它? 这是一场赢家将掌握容器编排技术规则的竞赛，而且胜利者只有一个。重要的是，不同于其他的比赛，赢得这场比赛，你不仅仅会成为今天的冠军，更有可能在来持续领先。


**00:01:30**:


我是 Saron Yitbarek，这里是代码英雄，一款红帽公司原创的博客。


第五集，容器竞赛。[上一集](/article-12529-1.html)我们见证了 DevOps 的崛起，以及一组新工具如何影响了其他人对开发者这一概念的看法。在这一集栏目中，我们会追溯容器技术崛起的历史，讲述容器技术如何通过拥有支持全新工作的可能性，来进一步扩展开发者这一角色的概念。然后我们会一起见证容器标准化是如何为容器编排奠定比赛基础的。


**00:01:30**：


这是一场严肃的比赛，也是一场全球性的比赛，吸引了行业里最快，最强大的选手。他们都准备好了为冲刺终点线而奋力一搏。准备好了吗? 比赛开始了！


现在，随着这些“赛马”离开起点，也许我们应该弄清楚为什么这场比赛如此重要。谁会关心容器呢？好吧，算我一个。但是实际上，一开始我也并不知道容器是什么。以下我将讲述一个小故事 —— 我是如何醒悟容器之美的。


**00:02:00**：


不久之前，我还在为我网站写代码，然后有天我让我的朋友 Nadia 过来实现一些新的功能。我在保持代码干爽和可读性方面做得很好，当然，代码也经过了很好的测试。所以再加入一个新的网站开发者也不是一件难事。对吗？如果你也这样以为，那就错了。这是一个非常繁琐的过程，特别是当我们跑规范化测试时，这个问题尤为明显。


**00:02:30**：


代码运行正常，但我们不能在两台电脑上同时通过所有测试。我们有很奇怪的电脑时区设置问题，而且她的 Ruby on Rails 版本跟我的不同。就是一个很经典的问题：“我的电脑上可以代码运行”，“可是在我的电脑上就是不行”。我只好对代码做一些修改，直到它在我这里正常运行，但当我把它发送给 Nadia 时，程序又会崩溃。


**00:03:00**：


我很清楚，我和 Nadia 所碰到的这些问题，对于所有的开发者来说都或多或少经历过，甚至他们把这种经历当作玩笑来讲。有时候，我只能把这个当做是在我工作时必须要忍受的一部分。我没有意识到的是，这个问题有个最终解决办法。想象有一种方式可以降低人与人之间的隔阂；想象有一种方法可以让我们在开发中使用任意喜欢的工具，并且在传递工作成果时毫无阻碍；想象一下有一种办法，无论有多少人同时进行一个项目的开发，不管这些人散布在世界何地，都可以让项目从开发到测试，再到生产环境，保持连贯性。如果在我浪费好几周，用最笨的方式传递工作成果前就想到了容器该多好。


**00:03:30 - Liz Rice**：


一个容器实际上就是一个进程。


**Saron Yitbarek**：


Liz Rice 是 Aqua Security 的一名技术布道师。她描述了为何容器会如此实用。事实上容器把一切打包到了一个整洁、并且可以迁移的包中。


**00:04:00 - Liz Rice**：


这就像任何其他的进程一样，不同的是容器的世界非常小。比如，如果你启动一个容器，进程会被授予它自己的根目录。然后它认为自己在查看的是整台计算机的根目录，但实际上它只是在查看这个文件系统很小的一个子集。


**00:04:30 - Saron Yitbarek**：


通过打包一个可执行文件及其所有的依赖，容器可以在任何笔记本或者云中的虚拟机上运行。带着它自己的执行文件、库和依赖。所有的一切都包含在了容器中。所以，这就是容器神奇之处，容器在每个环境中的运行都会完全一样。这也就意味着开发者可以轻松地分享并协作应用开发，而不用担心计算机之间相互不兼容这个老问题。


**00:05:00**：


举一个类比的例子希望能够帮助你理解。你有听说过<ruby> 蓝围裙 <rt>  Blue Apron </rt></ruby>这个服务吗？该服务提供你做饭所需的一切，包括精心按照菜谱卡片搭配好的，所有做饭需要的原料。好的，想象一下如果蓝围裙所能带给你的不仅仅只是还没有处理过的食材，而是一整个厨房，有煤气灶，还有你所需要的全部餐具，一切你需要的都会装到小盒子里，放在门阶上。这就是一个容器。在我提到的那种情况下，容器技术就可以很好地解决 Nadia 加入进来时所碰到的问题，简单到像使用蓝围裙服务做一顿晚餐一样。虚拟机同样也可以提供一个预装好的环境。但要解释这个，我们就不得不抛弃蓝围裙这个比喻，让我们来看一看具体的细节。


**00:05:30 - Liz Rice**：


许多人都认为容器是某种轻量级的虚拟化技术、轻量级的虚拟机，事实上并不是。容器与虚拟机有很大不同。虚拟机有独属于自己的一整个操作系统，相比起来容器是共享操作系统的。一个计算机上的所有容器共享同一个操作系统的。


**00:06:00 - Saron Yitbarek**：


最后一点，容器和虚拟机可以并肩工作。容器不能替代虚拟机。虚拟化技术仍然可以提高过时系统的效率，并且对于服务器整合非常关键。但容器技术的兴起也为我们打开了新的大门。不妨这样想，如果我们全部依靠虚拟机的话，运行所有仿真服务器将产生大量的额外负担。


**00:06:30**：


一台虚拟机的大小至少是以 G 为单位的，然而一个容器可能也就只有 20 M 左右。一台虚拟机可能会需要若干分钟来启动，如果我尝试用它部署一个网页应用的话，这可不是一个好消息。很长时间以来，人们都期盼一个轻量级的、更快速的完整机器虚拟化替代方案出现。


**00:00:07**：


回顾一下历史，1979 年就出现了容器的原型。Unix V7 的开发者们设计了一种根系统调用，使环境中只包括特定的程序。该突破为我们现在看到的容器技术指明了道路。另一个巨大的进展来源于 2008 年的 Linux 容器技术。现在，我们有了操作系统级的虚拟化技术。


**00:07:30**：


我们终于可以在一个单独的 Linux 内核上运行多个容器，而无需使用完整的虚拟机。这也就意味着程序对于基础架构的需求逐渐减少，但不是每一个人都能立马看到容器技术的潜力。


**Laura Frank**：


容器化真的是前所未有的、崭新的一个天才般的想法。


**Saron Yitbarek**：


Laura Frank 是 CloudBees 的技术总监。


**00:08:00 - Laura Frank**：


只有少部分人了解容器技术的来龙去脉，并可以运用它。不过相信随着时间的推移越来越多的人会接触到容器化的概念，随着越来越多的人开始使用这项技术，并且这些知识通过工程团队和工程组织，通过社区进行传播，就会变得更容易获得。


**Saron Yitbarek**：


因为和我们之前提到的与虚拟机的相似性，Laura 认为，因为我们之前提到的容器技术与虚拟机的相似性，容器的潜力被低估了。


**00:08:30 - Laura Frank**：


我在回想我的职业生涯，那是我还只是个普通的日常技术人员。如果你不是一个系统管理员或者 Linux 资深用户的话，容器还是一个你刚刚了解到的全新概念。我把它理解为使用一台虚拟机模式类似的东西，我可以去建立一个可以用完即弃的环境，而且这个环境完全独立，清理之后不留痕迹。


**Saron Yitbarek**：


容器除了能保持系统整洁之外，其实还大有可为。容器将会革新整个行业，并且随着开源项目和社区的兴起，在不久之后，容器标准化的充分实施将变为可能。


**00:09:00 - Scott McCarty**：


整个界面已经变得非常简单。


**Saron Yitbarek**：


Scott McCarty 是红帽的一名资深的容器策略顾问。他称得上是这个行业的资深人士，他在容器出现前，甚至是虚拟机出现前，就在做这方面的工作了。


**00:09:30 - Scott McCarty**：


在互联网 1.0 时代，我在一家线上零售商工作，我们有上千台实体机，我们用不同的方式，在所有这些不同的服务器上一遍又一遍地安装相同的软件。我们尝试了所有的方法。当你从原始的操作系统迁移到虚拟机，然后再到 Linux 容器、Solaris 容器，同样的问题一再出现，你仍然不得不在不同的虚拟机，或者类似操作系统实例的结构体之间管理配置。


**Saron Yitbarek**：


一旦容器变的规范化，一切都将改变。


**00:10:00 - Scott McCarty**：


比如，有了很多非常标准化的方式可以去处理现在这些打包好的应用，我认为容器技术的出现，从根本上改变了一切。它使得那些应用非常容易使用，而且容器还不会对系统本身造成损害，同时相比虚拟机更加小巧快捷。


**00:10:30 - Saron Yitbarek**：


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


**00:11:00**：


还记得之前我和同事 Nadia 遇到的反复出现的问题吗？“在我这代码能跑”的场景？在容器的世界，这个问题将不复存在。相比于我们之前使用的标准的操作系统，开发者社区见证了容器是如何变得更加快速，成本低廉，并且容易使用的 —— 比传统操作系统更加容易。容器技术被采纳的速度十分惊人。但是要记得：容器标准的出现仅仅是容器编排这场竞赛的热身。


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


**00:11:30**：


我是 Saron Yitbarek，这里是代码英雄。在这场标准容器编排竞赛中，哪位会胜出成为管理所有容器的平台呢？起初有两位竞争者处于领先地位。


**00:12:00**：


由 Apache 驾驭的 Swarm，和 Docker 驾驭的 Mesos。但是等等，怎么？现在出现了一匹黑马改变了这个格局，那就是谷歌。Linux 设立了云原生计算基金会（CNCF），随后 CNCF 推动了谷歌开源的编排引擎 Kubernetes。


**00:12:30**：


现在，相比 Kubernetes，Mesos 和 Swarm 已经抢占了先机，对吗？它们得到了 Apache 和 Docker 的支持，已经入场了一段时间了。但是 Kubernetes 有其他的“赛马”所不具备的优势。Clayton Coleman 会告诉我们这个秘密是什么。Clayton 是红帽负责 Kubernetes 和 OpenShift 的一名架构师。


**00:13:00 - Clayton Coleman**：


在 Kubernetes 诞生之初，谷歌就在项目的开放上做的很好，它降低了项目的贡献和参与的难度。谷歌极其关注让开发者和运维人员能更加容易地开展工作。有这样一个强烈的关注点，就是要做一个能让大多数开发者和运维的生活更轻松的东西。我觉得 Kubernetes 和围绕着Kubernetes 的社区找到了一个足够好的方式，让大部分人参与进来，他们让 Kubernetes 具有足够的可扩展性，还可以解决一些极端的用例。


**Saron Yitbarek**：


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


**00:13:30 - Clayton Coleman**：


在这个例子中，我喜欢以 Linux 打比方。Linux 并不是始于 Linus 开始编写内核，然后告诉所有人，在用户空间如何写 GCC，如何去建立 NGINX 或者 Apache。相反，内核团队专注于建立一个高效的操作系统内核，并与其他诸如 GNU 项目的开源社区合作，并且将可以在其他 Unix 系统上工作的工具引入 Linux。


**00:14:00**：


因此，我们如今所使用的许多工具，都不是 Linux 核心团队交付的。


但是 Linux 作为一个整体，相比于其内核涵盖的范围要宽泛得多，而且我认为这种模式的优势是 Kubernetes 取得现在成就所不可或缺的。当我们建立社区并且专注于 Kubernetes 范围时，我们可以试图从“Kubernetes 内核”的角度来考虑它，这是分布式集群操作系统的内核。


**00:14:30 - Saron Yitbarek**：


Kubernetes 证明了自己在开源世界中建立社区的能力，令人难以置信。正如我们在操作系统之战中谈到的 Linux 崛起一样，现如今这场关于容器的战争中，获胜者往往懂得如何借助社区力量。事实上，尽管谷歌可能开创了 Kubernetes，但目前它属于每一位开发者，并由云原生计算基金会（CNCF）管理。


**00:15:00**：


在 GitHub 上，Kubernetes 有大约 3 万的星标数，而 Swarm 和 Mesos 只有数千，这已经很能说明问题了。这就是由社区所生，为社区所用的技术。


我想了解谷歌的态度，一个如此庞大并且以效益为导向的大公司，是怎么做到如此擅长跟其他开发者合作的呢？我找到了很适合回答这个问题的人 —— Kelsey Hightower，他是谷歌负责容器技术支持的技术专家。


**00:15:30**：


想想谷歌的地位：它在分布式系统领域具备丰富的经验，还运行着分布在世界各地的许许多多的服务器，因此它开发的 Kubernetes 似乎有着很大的优势，并且有信心一定能在这场容器竞赛中胜出。那么，当你想到 Kubernetes 和开源时，你是如何看待这种关系的？


**00:16:00 - Kelsey Hightower**：


我想当谈到基础架构工具，甚至编程语言时，大家没有什么选择 —— 你不可能用个专有工具，即使它很棒。如果它不是开源的，大多数人可能甚至都不会想去了解。而且我认为这也是大多数人会采用像 Kubernetes 这样的基础架构工具的原因，你可能会对自己说：“好吧，我们就要坚持使用这个版本四、五年，也可能我们需要根据自己的一些独特需求来对其进行修改。”


**00:16:30**：


一旦走到这一步，就很难说服企业接受，“嘿，每台服务器使用程序的价格是 200 美元，而且你看不到源代码，所以有需要的话也必须等我们来修改”。


那样的日子一去不复返了，所以我不确定是否真的可以在没有开源的情况下建立基础架构。开源的另一个意味是拥有一个与项目紧密联合的社区，所以我认为 Kubernetes 一开始就锁定了胜利。


**Saron Yitbarek**：


让我们回到这场容器竞赛。在这里不仅仅有你提到的 Kubernetes，还有 Docker 的 Swarm Apache 的 Mesos……


**00:17:00 - Kelsey Hightower**：


所以，我想当人们谈论容器竞赛时，我不确定竞争是否发生在我们和 Mesos、Docker 使用者之间。我认为，真正的竞争发生在争取目前没有使用容器的潜在用户身上。是的，你还在使用原生 Bash 脚本，你迷茫着，不知道自己该归属何方。这些尚未选择编排工具和平台之人的市场，比起已选择了 Mesos 或 Swarm 的一方，要多得多。


**00:17:30**：


这就是容器战争存在并将继续的原因，真正的关键点在于如何帮助最终用户。Mesos、Kubernetes 或 Docker Swarm 是否会成为寻求更好解决方案的人们的首选？这一切都还悬而未决（SIG 译注：现在已经尘埃落定，Kubernetes 取得了全胜），但我会告诉你，像我一样，在这个领域工作的工程师来说，如果你不考虑市场营销和供应商，我会使用这个短语“不同的公司，相同的团队。”


**00:18:00**：


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


**00:18:30**：


因此，就这场竞赛而言，仍处于初期阶段，而且这个事情本身不会带来利润。明白我的意思吗？我们不是直接向任何人销售这个产品，这更像是一个平台之间的游戏，对所有人开放，然后用户会选择满足他们需求的那个，这就是我认为 Kubernetes 在社区方面做得很好的地方，真正开放，真正能解决实际问题。


**Saron Yitbarek**：


听起来很棒啊。我喜欢这个想法：在同一个球队踢球，而不要管球队是在什么地方。你对于容器和编排工具，还有 Kbubernetes 的未来有什么展望吗？


**00:19:00 - Kelsey Hightower**：


是的，我在 KubeCon 上做了一次主题演讲。所有这些工具都很棒，它们就像是乐高积木，我们有 Kubernetes，你可以选择一种产品用于安全，选择另一种产品用于网络，但最终，作为开发人员而言，你所想要的只是检查你的代码，并希望你的代码可以某种方式以呈现在客户面前。而我认为 Kubernetes 还有容器都会作为底层技术或者成为类似 Serverless 这种技术的基础平台。


**00:19:30**：


这是我的代码片段，已经打包完毕了。所有的平台都会把你的代码片段，用容器包装起来，然后帮你运行，但是不需要向你公开所有这些过程。因此，在未来，我认为随着 Kubernetes 变得普及，容器的应用场景将从大大小小的供应商或个人，提升到云供应商，因为这些事情往往需要专业知识和软件投资。容器将会遍布各个角落，但同时也就此隐藏起来。它会随着应用场景的扩展而渐渐隐形。


**00:20:00 - Saron Yitbarek**：


Kelsey Hightower 是 Google 的员工开发人员。在 2017 年秋天，Docker 宣布支持 Kubernetes。他们并不是说就放弃 Swarm 了，只是决定与容器编排竞赛的明显赢家和解。


**00:20:30**：


并不只有它一方，Azure 和 AWS 都宣布了对 Kubernetes 的支持。与此同时，像 OpenShift 这样的 Kubernetes 发行版仍在不断发展。我们得到的是一个可以扩展，支持新的用例的 Kubernetes 内核，这些用例包括微服务或持续集成项目。


**00:21:00 - Clayton Coleman**：


这个生态系统在类似 Linux 的模式下能得到最好的发展，而且我认为我们正朝着这条道路迈进。因此，就像所有优秀的开源项目一样，相对于单打独斗，让每个人都能够参与进来构建更好的东西，那就算是成功了。


**00:21:30 - Saron Yitbarek**:


所有这一切都在快速发生着，毕竟，这是一场竞赛，而这正是我们期望能从开源中获得的东西。在我们才刚刚理解什么是容器时，第一轮几乎就结束了，


这是来自 Red Hat 的 Scott McCarty。


**Scott McCarty**：


回想一下两年前，容器镜像格式还是一个巨大的战场，然后回到六个月至一年前，容器编排就成为了下一个巨大的战场。紧接着，如果你看看 2017 年的 KubeCon 及前几周，几乎每个主要供应商都宣布支持 Kubernetes。因此，很明显 Kubernetes 在这一方面上获胜了。


**00:22:00 - Saron Yitbarek**：


这章关于容器战争的故事即将结束。就像容器技术的开始一样迅速。


**Scott McCarty**：


因此，Kubernetes 已经成为标准，其美妙之处是，现在的应用定义已经变得标准化了。因此，任何人都可以在这些 YAML 文件中使用 Kubernetes 对象并定义应用，这就是我们共同所追求的事情。事实上，对于容器技术足够处理处理大型扩展系统这件事，我已经期待了 20 年。


**00:22:30 - Saron Yitbarek**：


Kubernetes 的成功看起来板上钉钉，但即使竞赛尘埃落定，我们仍然面临更大的一些问题。容器是否会成为未来几年的默认选择？是否会促使更多的云原生开发？这些转变将促生哪些工具和服务上？以下是我们目前所知道的。


**00:23:00**：


社区将通过 CNCF 继续改进 Kubernetes，并作为它最重要的使命之一，我们将建立一套全新的容器技术。


容器已经催生了大量新的基础设施，伴随而来的是全新的服务的需求。举个例子让你感受下容器的整合程度和发展速度，仅 Netflix 每周就运行超过一百万个容器。毫不夸张得说，容器是未来的构件。


**00:23:30**：


这一整季的栏目中，我们一直在追踪开源运动的演变。首先看到 Linux 如何主导战场，以及开源理念是如何改变商业、工作流程和每日使用的工具。容器真的是开源运动中最重要的里程碑之一。它们具有很好的迁移性、轻量、易于扩展。


**00:24:00**：


容器技术很好地体现了开源的优势，开源项目自然而然也推动了容器技术的发展。这是一个全新的世界，我们不用再担心从不同计算机或者云间的迁移产生的隔阂。


**00:24:30**：


容器的标准化比任何人预测的都要快。接下来的一集，我们将转向另一场悬而未决的战争。这场云间战争史无前例地催生者行业重量级人物。微软、阿里巴巴、谷歌和亚马逊四家云供应商的摩擦正在升温，随之而来的将是一场暴风骤雨。我们将会追随它们激发的闪电，和广受欢迎的几位代码英雄一起探讨云间战争。


**00:25:00**：


《代码英雄》是红帽公司推出的原创播客栏目。想要了解更多关于本期节目和以往节目的信息，请访问 [redhat.com/commandlineheroes](http://redhat.com/commandlineheroes) 。在那里，你还可以注册我们的新闻资讯。想免费获得新剧集的自动推送，请务必订阅该节目。


只要在苹果播客、Spotify、Google Play、CastBox 中搜索 “Command Line Heroes”，或者通过其他方式收听，并点击订阅，这样你就能在第一时间知道最新剧集。我是 Saron Yitbarek。感谢您的收听，编程不止。



> 
> **什么是 LCTT SIG 和 LCTT LCRH SIG**
> 
> 
> LCTT SIG 是 LCTT <ruby> 特别兴趣小组 <rt>  Special Interest Group </rt></ruby>，LCTT SIG 是针对特定领域、特定内容的翻译小组，翻译组成员将遵循 LCTT 流程和规范，参与翻译，并获得相应的奖励。LCRH SIG 是 LCTT 联合红帽（Red Hat）发起的 SIG，当前专注任务是《代码英雄》系列播客的脚本汉化，已有数十位贡献者加入。敬请每周三、周五期待经过我们精心翻译、校对和发布的译文。
> 
> 
> 欢迎[加入 LCRH SIG](/article-12436-1.html) 一同参与贡献，并领取红帽（Red Hat）和我们联合颁发的专属贡献者证书。
> 
> 
> 




---


via: <https://www.redhat.com/en/command-line-heroes/season-1/the-containers-derby>


作者：[Red Hat](https://www.redhat.com/en/command-line-heroes) 选题：[bestony](https://github.com/bestony) 译者：[lujun9972](https://github.com/lujun9972) 校对：[acyanbird](https://github.com/acyanbird)


本文由 [LCRH](https://github.com/LCTT/LCRH) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出


OK
The rise of containers opens a new frontier for developers, simplifying the movement of work from machine to machine. As they become more popular, though, a new battle emerges. The race is on for the control of container orchestration and it involves the industry’s fastest, strongest players.

Containers are one of the most important evolutions in the open source movement. In this episode, featured guests—including [ Kelsey Hightower](https://twitter.com/kelseyhightower),

[, and](https://twitter.com/rhein_wein)

__Laura Frank__[—explain how this new technology is the building block of the future and why orchestration is so crucial.](https://twitter.com/smarterclayton)

__Clayton Coleman__*Saron Yitbarek*

So. Have you ever been to a horse race, seen the stallions lined up and pawing the dirt? That's what you need to picture. A race is about to begin, and the outcome is going to turn one of these contenders into a champion.

**00:30** - *Saron Yitbarek*

Only, they're not horses. They're powerhouses of the tech world. What's so important about their race? What prize could be so valuable that they're all lining up and chomping at the bit? This is an all out race to control the orchestration of container technology. And, oh yeah, this isn't like other races. Win this race and you're not just today's champion, you're securing your place as a champion of the future.

**01:00** - *Saron Yitbarek*

I'm Saron Yitbarek, and this is Command Line Heroes, an original podcast from Red Hat. Episode Five: The Containers Derby. Last time we looked at the rise of DevOps and how a new set of tools is tied to new attitudes about the role of developers. In this episode, we track the rise of containers and how they expand the role of developers even further by supporting new kinds of unbounded work. And we'll see how the standardization of containers laid the track for that race toward container orchestration.

**01:30** - *Saron Yitbarek*

This is a serious race, and a global one, attracting some of the industry's fastest, strongest players. They're all ready to bolt for the finish line. Ready? And they're off.

Now, as those horses leave the gate, maybe we should clarify why this race really matters. Who cares about containers anyway? Well, I do for one, but I didn't know that at first. Here's the quick story on how I woke up to the beauty of container technology.

**02:00** - *Saron Yitbarek*

So, a little while back, I was working on the code base for my website and I brought in my friend Nadia to work on some features. I had been doing a pretty good job on my own keeping my code dry and readable and, of course, well tested. Onboarding a new developer would be easy. Right? Nope, wrong. It was pretty bumpy, especially when we were running specs.

**02:30** - *Saron Yitbarek*

The code worked, but we couldn't get all the tests to pass on both of our machines. We had weird time zone issues. Her version of Ruby on Rails was different from mine. It was the classic case of, "It works on my machine." "Well, it doesn't work on mine." I'd make changes until it worked for me, then it would all break when I sent it to Nadia.

**03:00** - *Saron Yitbarek*

I knew the struggle Nadia and I were going through was something all developers went through, even joked about. I just assumed it was part of the job, something you just gotta put up with. What I didn't realize is that there was finally a solution. Imagine there was a way to lower the barrier between people, a new approach where we can use whatever set of tools we prefer and still pass that work around with ease. Imagine there was a way to keep the work consistent as it moves from development to testing and into production, no matter how many people are working on it, or where those people are. Imagine that I had thought about containers before I wasted weeks doing it the hard way.

**03:30** - *Liz Rice*

A container is really, it's a process.

*Saron Yitbarek*

Liz Rice is a technology evangelist with Aqua Security. She's describing the thing that makes containers so useful, the fact that they wrap everything up in a neat transportable bundle.

**04:00** - *Liz Rice*

It's just like any other process, except it has a very restricted view of the world. So for example, you start a container. The process is given its own root directory, and it thinks that it's looking at the whole root directory of the whole computer, but it's actually only looking at a tiny subset of the file system.

**04:30** - *Saron Yitbarek*

By wrapping up an executable with all its dependencies, containers can run on any laptop or in any virtual machine in the cloud. It comes with its own executables, its own libraries and dependencies. Everything's contained in a container. So, and this is the magic part, a container is going to run exactly the same in every environment. That means developers can share applications without worrying about the old, "Works on my machine," issue.

**05:00** - *Saron Yitbarek*

Here's an analogy that might be helpful. You know Blue Apron? That service that delivers everything you need to make a meal? All nicely divided and portioned, recipe card and everything? Well, imagine if Blue Apron also brought you not just the pre-chopped ingredients, but a kitchen stove, and all your cutlery too. Everything you needed in a nice little box on your doorstep. That's a container. In my case, container technology would have made onboarding my friend Nadia a dream, easy as a Blue Apron dinner. VMs also give you a prepackaged deal, but that's where we have to leave the Blue Apron analogy behind and get to specifics.

**05:30** - *Liz Rice*

A lot of people are under the impression that containers are some sort of lightweight virtualization, lightweight virtual machines, and they're really not. It's very different from virtual machines. So a virtual machine has an entire operating system all to itself, whereas a container is sharing the operating system, you know, all the containers on one machine are sharing the same operating system.

**06:00** - *Saron Yitbarek*

Ultimately, containers and virtual machines are going to work side by side. Containers don't replace VMs. Virtualization is still going to increase efficiency in a date system and it's still crucial for server consolidation. But the rise of containers is opening a new door that was closed to us before. Think of it this way, if we relied on VMs entirely, running all those emulated servers, we'd be creating enormous overhead.

**06:30** - *Saron Yitbarek*

A VM might be gigabytes in size, whereas a container could be 20 megabytes. A VM could take several minutes to boot up. That's not a great pace if I'm trying to deploy web-based APPs. A lightweight, faster alternative to full machine virtualization has been a long time coming.

**07:00** -*Saron Yitbarek*

So a little history. There was a move toward a type of proto-container back in 1979. Developers working on the U nix V7 designed the root system call, which allowed for environments that contained only certain programs. That breakthrough pointed the way to the containers we have today. Another big step forward came with Linux containers in 2008. Now, we had Operation System-level virtualization.

**07:30** - *Saron Yitbarek*

We could finally run several containers using a single Linux kernel and that bypassed the need for full-fledged VMs. That means infrastructure costs start to drop. Not everybody saw the potential for containers right away.

*Laura Frank*

Containerization was really a genesis idea. It was something that was brand new.

*Saron Yitbarek*

Laura Frank is the director of engineering at CloudBees.

**08:00** - *Laura Frank*

Only a very small set of people understood the ins and outs and could operate the technology. And slowly over time, as more people are introduced to the idea and as more people begin to work on it and that knowledge is disseminated through engineering teams and engineering organizations and through communities, it becomes more available.

*Saron Yitbarek*

Because of that similarity to VMs we described earlier, Laura thinks the potential of containers got a bit lost.

**08:30** - *Laura Frank*

I think for where I was in my career and the general everyday technologist, containerization, if you weren't a Sys Admin or someone who had been deep in the guts of Linux, it was still kind of a new concept that I've had just passing familiarity with. So I kind of came to understand it as like, "Oh, this is kind of like how the pattern that I would use a virtual machine for, I can make a disposable environment that's totally isolated and then clean up really well after myself."

*Saron Yitbarek*

Containers were gonna do a lot more than keep things clean, though. They were going to revolutionize an industry. And with the rise of open-sourced projects and communities, soon enough container standardization became possible.

**09:00** - *Scott McCarty*

The interface became very simple.

*Saron Yitbarek*

Scott McCarty works at Red Hat as a senior strategist for containers. He's enough of a veteran that he remembers working at a time not just before containers, but pre-Virtual Machines too.

**09:30** - *Scott McCarty*

I worked at an online retailer in Dot-com 1.0 and we had thousands of physical machines, and we would deploy the same software stack over and over on all these different servers and we tried all different kinds of methodologies. It was really the same problem when you went from raw operating systems to virtual machines and then on to Linux containers, Solaris containers, you still had to manage the configuration across all these different virtual machines, essentially, or constructs that looked like operating system instances.

*Saron Yitbarek*

Once containers became standardized though, all that began to change.

**10:00** -*Scott McCarty*

Like, there were all these very standard ways to deal with this now packed application, and I think that's fundamentally what really changed it all. It just made it really easy to use and then it didn't hurt that they were smaller and faster than virtual machines as well.

**10:30** - *Saron Yitbarek*

Building on the advances made by Linux containers, these new open-source projects and communities took developers by the hand. Some of our anxieties about the back end were swept away. Suddenly containers, and the microservices they facilitated were looking very attractive. Once a common container language emerged barriers fell away and container technology changed the way we worked. It also changed the speed that we could learn about new tech.

**11:00** - *Saron Yitbarek*

Remember all that back and forth with my coworker Nadia? With the whole, "It works on my machine," shtick? That problem doesn't exist in a container world. The developer community saw how fast and cheap and easy containers had become, so much easier than the standard operating systems we'd used before. The rate of adoption has been pretty stunning. But remember: the emergence of a container standard was really just a warm up lap for the real race—orchestration.

The horses line up, the starting pistol fires and they're sprinting at last for the championship. Not for containers themselves, but for the tools that would deploy and manage them.

**11:30** - *Saron Yitbarek*

I'm Saron Yitbarek, and this is Command Line Heroes. In the race to become the standard container orchestration engine, who would deliver the platform that manages all those containers? At first, there were two contestants who pulled into the lead.

**12:00** - *Saron Yitbarek*

Mesos, driven by Apache, and Swarm, driven by Docker. But then, what's this? A newcomer came tearing down the track. It was Google. Linux had set up the Cloud Native Computing Foundation and CNCF was pushing Google's new open-sourced orchestration engine, Kubernetes.

**12:30** - *Saron Yitbarek*

Now, Mesos and Swarm had headstarts on Kubernetes, right? They were backed by Apache and Docker, which had both been in this race for a while. But Kubernetes had something that the other horses were missing. And Clayton Coleman can tell us what that secret ingredient was. Clayton's an architect for Kubernetes and OpenShift, over at Red Hat.

**13:00** - *Clayton Coleman*

From the very beginning in Kubernetes, Google was very good at opening the project up and making it easy to contribute and participate. There was such a strong focus on making something that would make the majority of developers and operators lives easier. I think Kubernetes and the community around Kubernetes was able to find a sweet spot good enough for the majority of people and extensible enough to solve some of the more extreme use cases.

*Saron Yitbarek*

In the early days, Kubernetes involved engineers from Red Hat and CoreOS and Google. Then, as Kubernetes reached 1.0, people in startups and big companies began adopting it, building off it. And here's the thing. That growth was never dictated by Google, or anybody else.

**13:30** - *Clayton Coleman*

So, the analogy I love to use in this case is Linux. Linux didn't start by Linus writing the kernel and telling everybody in user space how to write GCC or how to go build NGINX or Apache. Instead, the kernel team focused on building a very effective core operating system and working with other open-sourced communities like the GNU project to bring the tools that worked on other Unix's into Linux.

**14:00** - *Clayton Coleman*

And so, many of the tools we run today, no one from the core Linux team has ever contributed to.

But Linux as a whole is much broader than just the kernel, and I think that that pattern is something that we believe Kubernetes is well positioned to take advantage of. And so as we've built community and focused on scoping Kubernetes, we've tried to think of it in terms of a core Kubernetes, which is about the kernel of a distributed cluster operating system.

**14:30** - *Saron Yitbarek*

Kubernetes proved itself incredibly good at building community in an open-sourced world. Just like we saw in Episode Two with the rise of Linux, the winner in today's races is often the one who knows how to rally the community. In fact, while Google may have started Kubernetes, now it really belongs to every developer, and it's managed by the Cloud Native Computing Foundation.

**15:00** - *Saron Yitbarek*

On GitHub, Kubernetes has about 30,000 stars, while Swarm and Mesos have just a few thousand each. That's pretty telling right there. This is technology made by our community, and for our community.

I wanted to understand their attitude. How does a massive for-profit company end up playing so well with others? And I found exactly the right person to answer that question. Kelsey Hightower is a technologist working at Google supporting all things container.

**15:30** - *Saron Yitbarek*

When you think about Google's position, they have a lot of experience doing distributive systems and running things on many, many servers all over the world, so they seem like they were in a really good position to do Kubernetes and to win, and to do this very well. So, when you think about the relationship between Kubernetes and open source, how do you see that relationship?

**16:00** - *Kelsey Hightower*

I think when it comes to infrastructure tools, and even programming languages, right, there's no choice. You can't really have a proprietary tool, even if it's great. Most people probably won't even look at it if it's not open source. And I think the reason there is that most people will adopt technologies like infrastructure tools like Kubernetes, and you may checkpoint yourself and say, "Well, we're gonna stick with this version for four or five years, or we need to modify it for maybe some of our own unique needs."

**16:30** - *Kelsey Hightower*

Once you get to that point, it's gonna be really hard to convince an enterprise to go down the road of, "Hey, it's gonna be $200 per server, and you can't see the source code, so wait for us to modify it."

That road is gone. So I don't know if you can actually do infrastructuring anymore without it being open source. And then the second part of open source would be the community that can be attached to it, which I think Kubernetes nailed out of the gate.

*Saron Yitbarek*

So I wanna go back to the competition. Because it wasn't just Kubernetes as you mentioned yourself, there was Swarm by Docker, there was Mesos by Apache ...

**17:00** - *Kelsey Hightower*

So, I think when people talk about the battle, I don't know if the battle was really between Mesos and Docker, I think the battle was between people that have nothing. Right, you're coming from homegrown Bash scripts, you're still floundering around trying to get to where you need to be, and the market of people not using orchestration tools is much bigger than the people that have already chosen, let's say, Mesos or Swarm.

**17:30** - *Kelsey Hightower*

So that's what the battle is and will remain. So it's really about helping the end users now. Does Mesos or Kubernetes or Docker Swarm become the preferred choice for people looking to get into a better solution? That's all up for debate, but I'll tell you, people like me, the engineers working on this thing, if you put some of the marketing aside, some of the vendors aside, the people that work on this, I use this phrase “different companies, same teams.”

**18:00** - *Kelsey Hightower*

A lot of the tools that we build for each other, they end up in the other products some way or other. Right? A good idea is a good idea. So there's no reason to say, "Oh, that's what the Mesos people are doing, let's ignore it. That's kind of silly. So from an engineering standpoint, and a community standpoint, we cross-pollinate these ideas. You almost need that kind of competition so we can all think independently, the best ideas surface to the top and we pick and choose which ones to adopt that target the users in the right way.

**18:30** - *Kelsey Hightower*

So it's still early in terms of this whole competition thing, and again, this thing is zero dollars. You know what I mean? We're not selling this to anyone directly, so it's really more of a platform play, open for everyone, and then users will choose the ones that meet their needs and that's where I think Kubernetes has done a great job in terms of community, being open, and actually solving problems.

*Saron Yitbarek*

That was very beautiful. I really like this idea of playing on the same team regardless where that team exists. I like it. What do you see is the future of containers and orchestration and maybe even Kubernetes?

**19:00** - *Kelsey Hightower*

Yeah, so I gave a keynote at KubeCon about, like, all of these tools are great. They're all Lego bricks, you know, we got Kubernetes, you may pick another product for security, pick another product for networking, but at the end of the day, as a developer, you really just want to kinda check your coding and expect that code to land in front of your customer somehow, some way. And I think what Kubernetes will become, and containers will become, they will just become the substrate or just the platform pieces for higher level things like serverless.

**19:30** - *Kelsey Hightower*

Right? Here's my code snippet, under the covers, all the platforms will take your code snippet, wrap it up in a container and run it for you, but they don't need to expose all that to you. So in the future, I think as Kubernetes becomes common, and it's going to level the playing field from big or small providers or people that want to do it themselves, to actually be able to offer these things that only cloud providers could have done, because of the expertise required or the investment in software that was required.

This thing will probably end up everywhere, but it'll also be hidden. So it will disappear as it expands.

**20:00** - *Saron Yitbarek*

Kelsey Hightower is staff developer advocate at Google. In the fall of 2017, Docker announced they'd be supporting Kubernetes. They hadn't given up on Swarm, but they have decided to make peace with the obvious winner of the orchestration race.

**20:30** - *Saron Yitbarek*

They weren't alone, either, Azure and AWS both announced native support for Kubernetes. Meanwhile, Kubernetes distros, like OpenShift, are still evolving. What we're getting is a core Kubernetes that can extend and support new use cases, like microservices or continuous integration projects. Clayton Coleman. .

**21:00** - *Clayton Coleman*

That ecosystem will work best with a model that resembles Linux and I think we're well on our way towards that outcome. So this, like all good open source projects, succeeds when everybody is able to participate together to build something that's better than what we could all build individually.

**21:30** - *Saron Yitbarek*

All this is happening fast. It is a race, after all, and that's something we've come to expect from open source. The first lap is almost over before we even had a grip on what containers are. Scott McCarty, from Red Hat.

*Scott McCarty*

So if you think back two years, you know, the container image format was a huge battleground and then I'd say if you go back six months to a year ago, orchestration was a huge battleground. And then if you look at KubeCon 2017 and the weeks leading up to it, pretty much every major vendor has now announced support for Kubernetes. And so, it's pretty obvious Kubernetes has won at this point.

**22:00** - *Saron Yitbarek*

One chapter in the story of containers is coming to a close. Almost as quickly as it began.

*Scott McCarty*

And so Kubernetes has become the standard, and the beauty there is that now application definitions have standardized. So, anybody can use Kubernetes objects in these YAML files and define applications, it's what we wanted for, literally, I've wanted this for like 20 years in dealing with large scale systems.

**22:30** - *Saron Yitbarek*

Kubernetes' success seems pretty concrete, but even after that big race is finished, we're still left with some bigger questions. Are containers going to become the default choice in the next couple years? Are they going to encourage more cloud native development? And what are all the tools and services that these shifts are going to inspire? Here's what we do know.

**23:00** - *Saron Yitbarek*

Through the CNCF, the community will continue to improve Kubernetes and as per the foundation's mission, we're also going to be building a whole new set of container technologies.

Containers are already producing massive new levels of infrastructure and demanding whole new kinds of service. Just to give you a sense of how integral they've become, and how quickly, Netflix alone is launching more than a million containers every week. It's not a stretch to say that containers are the building blocks of the future.

**23:30** - *Saron Yitbarek*

This whole season, we've been tracking the evolution of the open source movement. We've seen how Linux rose to dominance in the first place and how open source attitudes have changed business, workflow, and the tools we use everyday. But containers really are one of the most important evolutions in that open source d movement. They're mobile, they're lightweight, they're easily scalable.

**24:00** - *Saron Yitbarek*

Containers embody the best of open source and it's no wonder open source projects have driven the development of container technology. It's a new world. And we're not gonna be worried anymore about moving from machine to machine, or, in and out of clouds.

**24:30** - *Saron Yitbarek*

The standardization of containers is happening faster than anybody would have predicted. The next episode, we turn to a battle still very much up in the air. The cloud wars are bringing out industry heavyweights like nothing else. Microsoft, Alibaba, Google and Amazon are facing off and the friction from those four cloud vendors is heating up into one serious storm. We're chasing that lightning along with some of our favorite Command Line Heroes, next time in Episode Six.

**25:00** - *Saron Yitbarek*

Command Line Heroes is an original podcast from Red Hat. For more information about this and past episodes, go to RedHat.com/CommandLineHeroes. Once you're there, you can also sign up for our newsletter. And to get new episodes delivered automatically for free, make sure to subscribe to the show. Just search for Command Line Heroes in Apple Podcast, Spotify, Google Play, CastBox, or however you get your podcasts. Then, hit subscribe, so you'll be the first to know when new episodes are available.

I'm Saron Yitbarek, thanks for listening and keep on coding.

### Keep going

### Power, control structures, and open source

Scott McCarty (aka Father Linux) tells the story of how he became a command line hero—going from punk rocker to open source rebel.

### UNIX/Linux and me

William Henry, Red Hat engineer and technology evangelist, details his operating system adventure, from UNIX to Linux and everything in between.

### Featured in this episode



#### Kelsey Hightower

Google developer advocate



#### Laura Frank

Director of engineering at CloudBees



#### Clayton Coleman

Core contributor to Kubernetes and cloud architect at Red Hat