❏ 站外平台:

《代码英雄》第一季(5):容器竞赛

作者: Redhat 译者: LCTT DarkSun

| 2020-08-21 00:02      

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

什么是《代码英雄》

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

本文是《代码英雄》系列播客第一季(5):容器竞赛音频脚本。

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

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

Saron Yitbarek

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

00:00:30

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

00:01:30:

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

第五集,容器竞赛。上一集我们见证了 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

举一个类比的例子希望能够帮助你理解。你有听说过蓝围裙Blue Apron这个服务吗?该服务提供你做饭所需的一切,包括精心按照菜谱卡片搭配好的,所有做饭需要的原料。好的,想象一下如果蓝围裙所能带给你的不仅仅只是还没有处理过的食材,而是一整个厨房,有煤气灶,还有你所需要的全部餐具,一切你需要的都会装到小盒子里,放在门阶上。这就是一个容器。在我提到的那种情况下,容器技术就可以很好地解决 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 。在那里,你还可以注册我们的新闻资讯。想免费获得新剧集的自动推送,请务必订阅该节目。

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

什么是 LCTT SIG 和 LCTT LCRH SIG

LCTT SIG 是 LCTT 特别兴趣小组Special Interest Group,LCTT SIG 是针对特定领域、特定内容的翻译小组,翻译组成员将遵循 LCTT 流程和规范,参与翻译,并获得相应的奖励。LCRH SIG 是 LCTT 联合红帽(Red Hat)发起的 SIG,当前专注任务是《代码英雄》系列播客的脚本汉化,已有数十位贡献者加入。敬请每周三、周五期待经过我们精心翻译、校对和发布的译文。

欢迎加入 LCRH SIG 一同参与贡献,并领取红帽(Red Hat)和我们联合颁发的专属贡献者证书。


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

作者:Red Hat 选题:bestony 译者:lujun9972 校对:acyanbird

本文由 LCRH 原创编译,Linux中国 荣誉推出



最新评论

LCTT 译者
DarkSun 🌟🌟🌟🌟🌟
共计翻译: 117.0 篇 | 共计贡献: 2254
贡献时间:2017-11-28 -> 2024-01-29
访问我的 LCTT 主页 | 在 GitHub 上关注我


返回顶部

分享到微信

打开微信,点击顶部的“╋”,
使用“扫一扫”将网页分享至微信。