转载

谷歌容器管理10年记

【编者的话】本文介绍了过去十年谷歌在容器管理方面的实践，包括了Borg，Omega和Kubernetes的历史和架构方面的比较，谷歌在其内部使用容器的概况，以及谷歌试图通过社区来推动其Kubernetes成为容器管理标准的努力。

@Container容器技术大会将于6月4日在上海光大会展中心国际大酒店举办，来自Rancher、携程、PPTV、蚂蚁金服、京东、浙江移动、海尔电器、唯品会、eBay、道富银行、麻袋理财、土豆网、阿里百川、腾讯游戏、点融网等公司的技术负责人将带来实践经验分享，4月7日之前购票只需338元，欢迎感兴趣的同学抢购。

容器的概念和实现并不是搜索引擎巨头谷歌发明的，但是谷歌却通过在上百万的服务器上编排和运行了数以亿计的容器帮助Linux操作系统的容器技术日趋完善。谷歌有很多经验可以分享，但依然谦虚的认识到也还有很多需要学习的地方。

这或许是其中最重要的一个原因使得谷歌在两年前决定开源其容器管理系统Kubernetes。谷歌过去通过发表论文向业界展示通过它的高精尖技术处理大规模环境下中的分析、存储和计算问题。但是这种方式有时候产生事与愿违的效果，例如谷歌的MapReduce理论被雅虎用来实现Hadoop进而孵化出了一个全新的领域。现在，谷歌如果不将其技术和标准贡献给社区让业界来遵从，谷歌将跟整个业界不兼容。

因此我们认为Kubernetes是谷歌的一次尝试，通过分享技术到社区以此推动该容器管理系统的开发，期望在将来能够替代其在内部使用了多年的集群管理的核心Borg，就像他们的名字暗示的那样其中包含了许多不同的技术（例如几年前产生的Omega调度器）。这次，谷歌希望能够得到社区的帮助，目前已经有超大规模集群以及HPC方面的专家在帮助充实Kubernetes以解决其只能支持单一的工作负载的问题，虽然在谷歌内部已经有5,000到50,000个节点的集群，但是其上运行的负载还是相对单一的。

在谷歌内部创建和扩展Brog的跟创建Kubernetes的核心开发团队是同一组人，他们继续在Kubernetes项目中有很大的影响力。这包含了Kubernetes的共同创立者Brendan Burns；过去8年一直在致力于集群管理系统工作的谷歌主管软件工程师John Wilkes；Borg容器管理系统的技术负责人、Brog的扩展组件Omega的创建者、Kubernetes的设计负责人Brian Grant；Kubernetes技术负责人David Oppenheimer；谷歌负责基础设施的副总以及加州大学伯克利分校的教授Eric Brewer。

谷歌发布了两篇介绍其容器管理系统的技术文章起到了重要的作用，第一篇是2013年10月发表的介绍Omega的文章，在介绍Omega的文章发布之后的2013年11月份在大规模系统管理会议（Large Installation System Administration conference）上Wilkes做了精彩的演讲。这解释了谷歌的Borg系统，同时这些信息的批露是在2014年夏天Kubernetes发布之前。在Kubernetes发布之后，带来了不少关于Omega和Borg之间关系的困扰，在2015年4月份发表的第二篇文章解释了谷歌的对于大规模集群管理的视角，在文章发表后，我们也采访了Wikes得到了更多谷歌关于容器和集群调度的洞察。

从事Borg，Omega和Kubernetes工作的谷歌顶尖工程师们ACM Queue上发表了另外一篇更通俗的文章描述了谷歌过去十年间在容器管理方面的经验和教训，提供了更多关于谷歌认为或者说希望看到Kubernetes社区前进的方向。

事实证明了Borg并不是这个搜索引擎巨头创造的第一个集群和应用管理工具。谷歌跟其它所有的公司一样有批处理工作负载和长期运行工作负载的组合，它在物理上将不同的工作负载运行在不同的集群里。一个叫做Babysitter的项目运行长期运行工作负载（例如Web服务和其它基础设施服务），同时另外一个叫做Global Work Queue的项目运行批处理工作负载例如孵化了Hadoop而谷歌仍然在继续使用的MapReduce大数据分析框架。但是，在不同集群里运行不同的应用会造成经常性的计算资源浪费，这对在过去十年快速成长的谷歌来说是不可接受的。

关于软件容器，即使是在十年前也不能算是一个新概念。我们甚至可以说1989年克隆大型机制造商Amdahl提出的PR/SM逻辑分区就已经是容器，毫无疑问IBM自己System z主机系统上的的虚机操作系统产生的虚机在本质上也是软件容器，直到今天还作为在主机系统上运行Linux实例的后台技术。FreeBSD有Jail partitions，Solaris最终也有了自己的容器技术。但是谷歌作为一个Linux公司不得不进行大量的工作在Linux内核中添加容器相关的功能。现在在每一个Linux发行版中都存在的LXC容器技术是在谷歌的工作的基础上创建的，而Docker是这项工作的另外一个分支。

在某种程度上来讲，Kubernetes借鉴了单一化的Borg系统和更加灵活的Omega系统的技术（使得多种工作负载可以共享资源而不必只是排队等待），最终结果是Kubernetes成为谷歌的第三个容器管理系统。如果Kubernetes的复杂程度和规模持续增加的话它可能会成为另外一个Borg，而我们认为这是谷歌的其中一个目标。从另外一个角度来讲，就像我们前面说的那样，谷歌希望Kubernetes能成为容器管理的事实上的标准，这使得构建企业级私有云的用户更有可能去使用谷歌的基于Kubernetes构建的Google Cloud Platform公有云服务。

从谷歌发布的最新文章中透漏出的关于其容器管理系统从裸机到容器的转变的重要信息是意义深远的，这或许对谋求容器作为更好的方式的人来讲不是显而易见的，我们认为这是相比与抬高服务器利用率的服务器虚拟化来讲更廉价的一种方式。一切都变成了应用为中心而不是服务器为中心，这正是IT公司们梦寐以求的天堂。工作负载调度器、集群管理系统和容器管理器协同工作当应用需要时为应用提供正确的容量，不管应用是延迟敏感的负载或者是对延迟不敏感的批处理负载，工程师和开发人员所需要关注只是应用的运行状态，而他们可以非常容易的获取应用运行的状态因为所有的关于状态的API调用都是在应用层面的而不是服务器层面的。

这意味着容器时代的到来，在谷歌里将不在有裸机，这可以作为给那些HPC厂商和其它超大规模集群厂商以及云服务提供商的一堂课,他们还认为需要运行在裸机模式下（我们听所在AWS上运行的很多大数据服务运行在裸机上而不是用定制版Xen Hypervisor支持下的EC2计算实例）。这不是一个确定的结论，但是在些许性能损失（其实比整机使用KVM或者Xen进行虚拟化的性能损失还是小很多的）和容器带来的管理与部署灵活性之间看上去绝对是一个非常划算的折衷。（如果Intel想解决这个问题，可以在每一个芯片中增加一个容器管理核心就足够了，或者在Xeon服务器芯片中用两个或者三个核来运行Hypervisor）。

“容器的隔离性和最小依赖被证明了在谷歌是非常有效的，容器已经成为了谷歌基础设施上运行的唯一实体”, 文章的作者写道，“一个结果就是现在谷歌在任何时间只有很少数量的操作系统版本部署在所有的服务器上，这就只需要很少的人员去维护和更新操作系统版本”。

使用Kubernetes，容器是一个应用程序的运行时，而作为构成微服务的多个容器被聚合到一个更高层次的被称为pod的概念中。Kubernetes最重要的是一个pod管理系统来使得这些容器集合能够协作和运行。Borg有一个类似的架构，Linux容器作为最细的粒度和Allocation的最底层。Allocation，缩写为alloc，是容器集合的一个上层包装。Borg允许某些容器在alloc之外运行，文章的作者说“这是造成诸多不便的原因”，这或许还是一个非常保守的陈述。Kubernetes则不允许你这么做。然而如果在丢安全或者隔离性有更高要求的场合例如在多租户环境的公有云中你可以在容器内运行容器，或者在一个虚拟机内部运行容器。事实上，谷歌在它的Cloud Platform里就是这么做的。一个服务器上运行了一个巨大的容器，在这个容器之上运行了KVM Hypervisor或者其它容器来向公有云上的用户暴露不同的Google Engine实例类型。

就像Omega通过收集和使用谷歌集群状态信息来更好的分配资源给容器化的批处理应用和在线应用，Kubernetes则实行了严格统一的API来跟集群进行接口 – 不像Brog在过去若干年增加了很多的API类型和风格。

“Kubernetes的设计中微服务和小的控制回路的组合是一个通过编排进行控制的例子 – 通过组合协作中的分散和自治实体来达到期望的效果”，谷歌最近这的篇文章中说，“与集中式的编排系统相比Kubernetes是一种更精巧的设计，集中式的编排系统可能在开始时相对较容易，但是随着时间的推移特别是在出现不可预知的错误或者状态变化时就会变得容易出现问题。”

我们的整体印象是Kubernetes是一个虽然还有那么一点不成熟但是却是一个比Borg更好的工具，仅仅是Kubernetes这一个工具就会给整个IT业界一个很大的影响。

谷歌将它过去十年在容器和集群管理方面的经验回馈给开源社区，甚至在它帮助Berkeley的AMPLab推动Mesos系统的开发之后，Mesos系统目前已经被Mesophere商业化。这或许是谷歌后悔做的事情（译者注：指推动Mesos的发展），但是开源Kubernetes对谷歌来说确实是一个艰难的决定。唯一的另外一个可能选项是让Mesos变成像Hadoop一样的另外一个事实上的标准，我们已经看到这件事情的现状了，这显然不是谷歌想要的。谷歌是唯一一个不能轻易从它自创的MapReduce转到Hadoop的超大集群运营者，这意味着它基础设施软件开发的成本从长期来看将持续上涨。

原文链接： A Decade Of Container Control At Google （翻译：李光成）

=================================

译者介绍

李光成，IBM中国研究院资深研究员，研究方向是云计算基础设施及技术。目前在做的是Docker资源隔离方面的研究项目。