K8s这么香，为什么谷歌还坚持使用Borg？
极客时间编辑部
讲述：初明明大小：5.55M时长：06:04
你好，欢迎收听极客视点。
前不久，在 Kubecon 欧洲在线虚拟大会上，Kubernetes 的两位早期开发者布伦丹·伯恩斯（Brendan Burns）和蒂姆·霍金（Tim Hockin）针对大家的提问“谷歌会不会从 Borg 迁移到 Kubernetes”进行了回复，并提到 Kubernetes 和 Borg 之间的差异。InfoQ 将重点内容整理如下。
作为谷歌开源的容器集群管理系统，Kubernetes 建立在谷歌内部的 Borg 技术之上。发展到今天，Kubernetes 的规模已经变得非常庞大，它被认为是计算基础设施的未来，与虚拟机一脉相承，就像虚拟机取代裸机成为计算部署的最常见单元一样，尤其是在云环境中。
作为业界最主流的容器技术，谷歌会不会考虑迁移到 Kubernetes 呢？
蒂姆·霍金表示，“Kubernetes 和 Borg 在思想上非常相似，但在细节上有很大的不同。Borg 没有像 Kubernetes 那样的网络模型。Borg 应用程序是为了在 Borg 中运行而编写的，因此它可以更具规范性，Borg 应用程序是高度同质化的：同样的库、同样的 RPC 系统、同样的认证……最关键的是 Kubernetes 的设计是为了与现有的开源系统一起工作。虽然它们都专注于自动化、短暂性、动态管理，以及让用户在大多数情况下不必关心与他们无关紧要的细节。”
蒂姆·霍金还称， Kubernetes 太复杂了，因为它有 100 多个不同的 API 协同工作，有很多可动部件和子系统。想要 Kubernetes 变简单也可以，代价就是删减其中的功能，但事实是，每个功能都有人在用。
至于 Kubernetes 和 Borg 有什么区别呢？
Kubernetes “始于 2013 年秋天”，彼时布伦丹·伯恩斯等人受到 Docker 工具和容器标准化潜力的启发，开始着手创建一个 “最小可行的编排器”。谷歌对容器并不陌生，因为它已经运行了一个 “统一容器管理系统……内部称之为 Borg。”
尽管 Kubernetes 在某些方面是 Borg 的进化，但一个关键的区别是，Kubernetes 一直是为外部开发者准备的。布伦丹·伯恩斯介绍称，他们还 “花了很多很多的时间” 来 “说服执行领导层，让他们相信开源这个项目是个好主意”。
2015 年，谷歌发布了 Kubernetes v1.0，同时联合红帽以及微软等公司成立了云原生计算基金会，也就是 CNCF（Cloud Native Computing Foundation），并将 Kubernetes 作为种子项目捐赠给了 CNCF。
虽然 Kubernetes 来源于 Borg，但两者也有一些区别。
Borg 作为谷歌的内部容器管理平台，继承了之前谷歌 WorkQueue（用于批处理作业）和 Babysitter（用于在服务器上管理的连续运行服务）所使用的应用管理项目。当时处于多核时代的早期阶段，谷歌以使用廉价的现成硬件而闻名。所以，谷歌的机器并不是那种拥有无数处理器的巨大盒子，早期的系统相当简单。
WorkQueue 仅仅是基于内存为机器调度工作负载，而机器的所有其他方面都是差不多的。一旦多核错误出现，人们开始意识到，需要一些更强大的东西来进行 Binpack，这就是 Borg 的真正动机。实际上，它被设计成直接滑入工作队列中，并用于调度 Map Reduce，它现在甚至运行在 WorkQueue 运行的同一端口上。它还覆盖了一些 Babysitter 的角色，所以它实际上创建了一个统一的平台，人们可以在这个平台上同时运行服务和批处理负载，以及其他工作负载，所有类型的工作负载——最终，谷歌现在几乎所有的东西都在 Borg 上运行。
从那开始，谷歌前前后后发展出了三个容器系统：Borg、Omega 以及 Kubernetes。
Omega 项目的动机实际上是试图改进 Borg 中的一些底层原语和内部基础设施，Omega 有许多属性同样可以在 Kubernetes 中看到。事实上，Kubernetes 更像是一个开源的 Omega，而不是开源的 Borg。很多参与 Omega 工作的人也参与了 Kubernetes 的开发工作，因此 Omega 的很多想法也进入了 Kubernetes。
另外，Borg 为应用程序动态分配端口，而不是像 Kubernetes 那样分配 IP。这样做的好处是不需要那么多 IP 地址，至于缺点，其中一个就是，在谷歌内部，大多数软件都是从头开始重写的。因此，谷歌的 monorepo 中有数十亿行代码，都是从头开始编写的。如果你能做到这一点，那么就可以与外界的做法大相径庭。如果真的需要能够从外部世界管理，就会变得更难。因此，外部世界中的大多数应用程序都采用静态配置的端口。如果你有一个分布式应用程序，它们通常会假定该应用程序的所有实例都在同一端口上。
大多数代理只处理所有位于同一端口上的目标。因此，在几乎所有以任何一种分布式方式运行在服务器上的软件中，这是一个普遍存在的问题。谷歌决定尝试给这些应用程序的配置和发现以及负载均衡，提供更为实用的模型。这也是造成差异的真正原因。
总结来说，Kubernetes 之所以能发展成现在这个样子，也是因为早期开发者都来自于 Borg，懂得其中的差异。
不过，从目前来看 Kubernetes 已经成为容器领域当之无愧的事实标准。从长远来看，Kubernetes 项目也将会成为企业服务器端技术栈中标准的一环，并连同它所推崇的容器化理念，成为广大后端技术人员和开发者的一门必修课，但想要啃下 Kubernetes 这个“硬骨头”并不那么容易。
《深入剖析 Kubernetes》专栏以浅显易懂的语言，教你从 0 搭建 Kubernetes 集群，掌握 Kubernetes 项目关于编排、调度和作业管理的各项核心特性。以下是这个专栏的目录，供你参考。使用极客视点专属口令，享受立减优惠。
优惠口令：pouxik8s1
适用专栏：《深入剖析 Kubernetes》
适用规则：立减 10 元（满 40 元可用）
有效期：9 月 7 日 - 9 月 14 日
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
该免费文章来自《极客视点》，如需阅读全部文章，
请先领取课程
请先领取课程
免费领取
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
精选留言
由作者筛选后的优质留言将会公开显示，欢迎踊跃留言。
收起评论