Docker背后的容器集群管理.docVIP

Docker背后的容器集群管理 2015年4月，传闻许久的Borg论文总算出现在了Google Research的页面上。虽然传言Borg作为G家的“老”项目一直是槽点满满，而且本身的知名度和影响力也应该比不上当年的“三大论文”，但是同很多好奇的小伙伴一样，笔者还是饶有兴趣地把这篇“非典型”论文拜读了一番。 注：本文作者张磊将在8月28日~29日的CNUT全球容器技术峰会上分享题为《从0到1：Kubernetes实战》的演讲，演讲中他将重点剖析Kubernetes的核心原理和实践经验，并分享大规模容器集群管理所面临的问题和解决思路。 1. Borg在讲什么故事 其实，如果这篇论文发表在两三年前，Borg的关注度恐怕真没有今天这么高。作为一篇本质上是关于数据中心利用率的半工程、半研究性的成果，这个领域的关注人群来自大厂的运维部以及系统部的技术同僚可能要占很大的比例。而对于绝大多数研究人员，普通开发者，甚至包括平台开发者而言，Borg论文本身的吸引力应该说都是比较有限的。相关厂商内容中国TOP互联网公司的容器应用经验分享京东618大促下的数据驱动个性化推荐如何构建软硬件结合的人工智能产品研发体系中国创新型互联网企业走向海外的技术机遇与挑战LinkedIn成员分类平台大数据应用的最佳实践相关赞助商全球架构师峰会，7月17日-18日，深圳大梅沙京基海湾大酒店。马上报名。不过，一旦我们把Borg放到当前这个时间点上来重新审视，这篇本该平淡的论文就拥有了众多深层意义。当然，这一切绝非偶然，从2013年末以Docker为代表的容器技术的迅速兴起，2014年Google容器管理平台Kubernetes和Container Engine的强势扩张，再到如今由Mesos一手打造的DCOS（数据中心操作系统）概念的炙手可热。容器技术令人咋舌的进化速度很快就将一个曾经并不需要被大多数开发人员关注的问题摆到了台面： 我们应该如何高效地抽象和管理一个颇具规模的服务集群？ 这，正是Borg全力阐述的核心问题。 说得更确切一点，当我们逐步接纳了以容器为单位部署和运行应用之后，运维人员终于可以从无休止的包管理，莫名其妙的环境差异，繁杂重复的批处理和任务作业的中稍微回过一点神来，开始重新审视自己手中的物理资源的组织和调度方式：即我们能不能将容器看作传统操作系统的进程，把所有的服务器集群抽象成为统一的CPU、内存、磁盘和网络资源，然后按需分配给任务使用呢？ 所以，作为《Docker背后的技术解析》系列文章的特别篇，笔者将和读者一起从Borg出发，结合它的同源项目Kubernetes中尝试探索一下这个问题的答案。 2. Borg的核心概念 同大多数PaaS、云平台类项目宣称的口号一样，Borg最基本的出发点还是“希望能让开发者最大可能地把精力集中在业务开发上”，而不需要关心这些代码制品的部署细节。不过，另一方面，Borg非常强调如何对一个大规模的服务器集群做出更合理的抽象，使得开发者可以像对待一台PC一样方便地管理自己的所有任务。这与Mesos现在主推的观点是一致的，同时也是Borg同PaaS类项目比如Flynn、Deis、Cloud Foundry等区别开来的一个主要特征：即Borg，以及Kubernetes和Mesos等，都不是一个面向应用的产物。 什么叫面向应用？ 就是以应用为中心。系统原生为用户提交的制品提供一系列的上传、构建、打包、运行、绑定访问域名等接管运维过程的功能。这类系统一般会区分”应用“和”服务“，并且以平台自己定义的方式为”应用“（比如Java程序）提供具体的”服务“（比如MySQL服务）。面向应用是PaaS的一个很重要的特点。 另一方面，Borg强调的是规模二字。文章通篇多次强调了Google内部跑在Borg上的作业数量、以及被Borg托管的机器数量之庞大。比如我们传统认知上的“生产级别集群”在文章中基本上属于Tiny的范畴，而Borg随便一个Medium的计算单元拿出来都是一家中大型企业数据中心的规模（10K个机器）。这也应证了淘宝毕玄老大曾经说过的：“规模绝对是推动技术发展的最关键因素”。 Borg里服务器的划分如下： Site = 一组数据中心（Cluster）， Cluster = 一组计算单元（Cell）， Cell = 一组机器。 其中计算单元（Cell）是最常用的集群类别。 2.1 Job，Task 既然Borg不关心“应用”和“服务”的区别，也不以应用为中心，那么它需要接管和运行的作业是什么？ 是Job。 Borg文章里对Job的定义很简单，就是多个任务（Task）的集合，而所谓Task就是跑在Linux容器里的应用进程了。这样看起来Job是不是就等同于Kubernetes里的Pod（容器组）呢？ 其实不然。Job映射