【云原生论文欣赏】Borg, Omega,和 Kubernetes Ⅰ

前言

本文翻译于公开的论文：Borg, Omega, and Kubernetes 。

由于论文篇幅原因，此论文将被分为几篇博文。

该论文总结了谷歌公司在2006年至2016年间，从其内部三个容器管理系统的使用中吸取的经验与教训。

三个容器管理系统分别是Borg, Omega,和 Kubernetes。在 Kubernetes 主页中有这么一句话：Kubernetes 源自Google 15 年生产环境的运维经验。该论文解释了为什么 Kubernetes 能从众多容器编排工具中脱颖而出。

Borg 系统是谷歌公司最初的容器编排系统，随着使用时间的推移，谷歌工程师们为 Borg 增加了很多新功能和补丁，Omega 系统则是 Borg 的升级版本，它集成了Borg 系统的优势，并改善了其劣势，并用统一的完善的代码重新编写了原生的容器编排系统，即 Omega。而 Kubernetes 则是 Borg 和 Omega 的后代，集它们优点的大成者，重新用 Go 语言开源出来的容器编排系统。

简单的理解：Borg是爷爷（第一代谷歌编排系统），Omega是儿子（第二代谷歌编排系统），Kubernetes 是孙子（第三代谷歌编排系统），一代比一代功能完善，性能更优良。Kubernetes 站在谷歌的肩膀上，同时其拥有庞大的开源社区使它的功能和代码不断完善，凝聚了社区的最佳创意和实践。

论文目录

• Abstract 摘要
• Introduction 简介
• Containers 容器
• Things to Avoid
• Some Open, Hard Problems 一些开放的困难问题
• Conclusion 总结
• References 参考文献
• Authors 作者介绍

Abstract 摘要

十年来从三个容器管理系统中吸取的教训。

Introduction 简介

尽管对软件容器的广泛关注是一个相对较新的现象，但在谷歌，我们已经大规模地管理Linux容器超过10年，并在这段时间内建立了三个不同的容器管理系统。每个系统都深受其前辈的影响，尽管它们是出于不同的原因开发的。本文介绍了我们从开发和运营这些系统中获得的经验。

谷歌开发的第一个统一的容器管理系统是我们内部称为Borg的系统[7]。它是为了管理长期运行的服务和批处理作业而建立的，这些作业以前是由两个独立的系统处理的。Babysitter和Global Work Queue。后者的架构对Borg有很大的影响，但主要集中在批处理作业上；两者都早于Linux控制组。Borg在这两类应用之间共享机器，作为提高资源利用率从而降低成本的一种方式。这种共享是可能的，因为Linux内核中的容器支持正在变得可用（事实上，谷歌为Linux内核贡献了许多容器代码），这使得延迟敏感的面向用户的服务和耗费CPU的批处理程序之间的隔离更好。
随着越来越多的应用程序被开发到Borg之上运行，我们的应用程序和基础设施团队为它开发了一个广泛的工具和服务生态系统。这些系统提供了配置和更新工作的机制；预测资源需求；动态推送配置文件给正在运行的工作；服务发现和负载平衡；自动扩展；机器生命周期管理；配额管理；以及更多。这个生态系统的发展是由谷歌内部不同团队的需求驱动的，其结果是一个有点异质的、临时的系统集合，Borg的用户必须使用几种不同的配置语言和流程来进行配置和互动。Borg仍然是谷歌内部主要的容器管理系统，因为它的规模、功能的广度和极强的稳定性。

Omega[6]是Borg的后代，它是由改善Borg生态系统的软件工程的愿望所驱动。它应用了许多在Borg中被证明是成功的模式，但从头开始建立了一个更加一致、有原则的架构。Omega将集群的状态存储在一个集中的基于Paxos的面向事务的存储中，由集群控制平面的不同部分（如调度器）访问，使用乐观的并发控制来处理偶尔的冲突。这种解耦允许Borgmaster的功能被分解成独立的组件，作为同行，而不是通过一个单一的、集中的主控器来输送每个变化。Omega的许多创新（包括多个调度器）后来都被折叠到Borg中。

在谷歌开发的第三个容器管理系统是Kubernetes[4]。它是在外部开发者开始对Linux容器感兴趣的情况下构思和开发的，而谷歌已经发展了一个日益增长的销售公共云基础设施的业务。Kubernetes是开源的–这与Borg和Omega形成鲜明对比，后者是作为纯粹的谷歌内部系统开发的。与Omega一样，Kubernetes的核心是一个共享的持久性存储，由组件监视相关对象的变化。与Omega不同的是，Kubernetes将存储直接暴露给可信的控制面组件，而Kubernetes的状态则完全通过一个特定领域的REST API来访问，该API应用了更高级别的版本、验证、语义和策略，以支持更多不同的客户端。更重要的是，Kubernetes的开发更加注重开发者编写在集群中运行的应用程序的经验：它的主要设计目标是使部署和管理复杂的分布式系统变得容易，同时仍然受益于容器带来的利用率的提高。

本文描述了谷歌在从Borg到Kubernetes的过程中获得的一些知识和教训。

Containers 容器

从历史上看，第一批容器只是提供了对根文件系统的隔离（通过chroot），而FreeBSD jail 则将其扩展到额外的命名空间，如进程ID。Solaris随后开创并探索了许多增强功能。Linux控制组（cgroups）采用了许多这样的想法，并且这一领域的发展一直持续到今天。

FreeBSD jail 是一项操作系统层虚拟化技术

容器所提供的资源隔离使谷歌能够推动利用率大大高于行业规范。例如，Borg使用容器将批处理作业与延迟敏感的、面向用户的作业放在同一台物理机上。面向用户的工作保留了比它们通常需要的更多的资源–使它们能够处理负载高峰和故障转移–这些大部分未使用的资源可以被回收来运行批处理工作。容器提供了使之成为可能的资源管理工具，以及强大的内核级资源隔离，以防止进程之间的相互干扰。我们通过在开发Borg的同时加强Linux容器来实现这一点。但这种隔离并不完美：容器不能防止操作系统内核不管理的资源的干扰，如3级处理器缓存和内存带宽，而且容器需要由额外的安全层（如虚拟机）支持，以防止在云中发现的各种恶意行为。

随着时间的推移，人们发现容器化的好处不仅仅是实现更高水平的利用。

现代容器不仅仅是一种隔离机制：它还包括一个镜像–构成在容器内运行的应用程序的文件。在谷歌内部，MPM（Midas Package Manager）被用来构建和部署容器镜像。隔离机制和MPM包之间的共生关系同样可以在Docker守护程序和【Docker镜像仓库】之间找到。在本文的其余部分，我们用容器这个词来包含这两个方面：运行时隔离和镜像。

以应用为导向的基础设施 随着时间的推移，容器化的好处已经很明显了，不仅仅是能够提高利用率。容器化将数据中心从面向机器的状态转变为面向应用的状态。本节讨论了两个例子。

• 容器封装了应用环境，从应用开发者和部署基础设施中抽象出了许多机器和操作系统的细节。
• 因为精心设计的容器和容器镜像都是针对单个应用的，管理容器意味着管理应用而不是机器。这种管理API从面向机器到面向应用的转变极大地改善了应用的部署和自省。

应用环境 内核中的cgroup、chroot和命名空间设施的最初目的是保护应用程序不受嘈杂、聒噪和混乱的邻居的影响。将这些与容器镜像结合起来创造了一个抽象，该抽象还将应用程序与它们所运行的(异构)操作系统隔离开来。这种镜像和操作系统的解耦使得在开发和生产中提供相同的部署环境成为可能，这反过来又提高了部署的可靠性，并通过减少不一致和摩擦来加快开发速度。

使这种抽象工作的关键是拥有一个封闭的容器镜像，它可以将应用程序的几乎所有依赖项封装到一个可以部署到容器中的包中。如果这样做正确，则唯一的本地外部依赖项将在 Linux 内核系统调用接口上。虽然这个有限的接口极大地提高了镜像的可移植性，但它并不完美：应用程序仍可能暴露在操作系统接口下并受到干扰，特别是在套接字选项、/proc 和 ioctl 调用的参数暴露的广泛表面区域中。我们希望如同 Open Container Initiative (https://www.opencontainers.org/) 这样的组织，持续努力将进一步阐明容器抽象的表面区域。

尽管如此，容器提供的隔离和依赖最小化在 Google 被证明是非常有效的，容器已经成为 Google 基础设施支持的唯一可运行实体。一个结果是，Google在任何时候都只在其整个机器集群中部署了少量的操作系统版本，并且只需要一小部分人来维护它们并推出新版本。

有很多方法可以实现这些密封镜像。在 Borg 中，程序二进制文件在构建时被静态链接到公司范围内存储的已知良好的库版本上[5]。即便如此，Borg容器镜像也不是那么密不透风：应用程序共享一个所谓的基础镜像，在机器上安装一次，而不是在每个容器中打包。这个基础镜像包含了诸如 tar 和 libc 库等实用程序，因此对基础镜像的升级可能会影响到正在运行的应用程序，偶尔也会成为一个重要的题来源。

更现代的容器镜像格式，如 Docker 和 ACI，进一步强化了这种抽象，并通过消除隐含的主机操作系统依赖关系，并要求明确的用户命令在容器之间共享镜像数据。而更接近于密封的理想状态。

未完待续…

博主翻译能力有限，博文内容仅供参考。

翻译论文链接

ACM：Borg, omega, and kubernetes