才云科技CTO邓德源：不可不知的谷歌集群管理经验

摘要：曾为美国谷歌集群管理组核心成员，主要参与开发集群管理系统。保证系统升级软硬件错误等均能及时被发现并处理，谷歌集群能小时不间断工作。关于集群管理经验，首先一定要专注于持久的运维自动化工具开发。

本文仅用于学习和交流目的，不得用于商业目的。非商业转载请注明作译者、出处，并保留本文的原始链接：http://www.ituring.com.cn/art...

邓德源， 才云科技CTO。2011年毕业于电子科技大学机械与自动化专业，2013年获美国顶级计算机学府Carnegie Mellon University大学电子与计算机工程学位，专修操作系统、分布式计算等方向。参与亚太机器人大赛，代表电子科大获全国第一名，后代表中国队在埃及获金牌。

曾为美国谷歌集群管理组核心成员，主要参与开发集群管理系统。负责管理运维工程师提交的生产环境变更请求，自动化风险分析，自动化生产环境准备工作，以及各种集群容错处理。保证系统升级、软硬件错误等均能及时被发现并处理，谷歌集群能24/7小时不间断工作。作为核心成员参加了开发基于容器集群的谷歌开源项目（Kubernetes），一度成为全球前十的贡献者和贡献最高的华人。

邓老师目前在才云科技主要负责什么工作？

我目前在才云科技主要负责公司内部的团队管理，技术管理以及部分对外工作。

团队管理方面主要包括搭建技术团队、组织架构、制度规范的建立、技术文化等，技术管理方面主要是组建中层团队、制定技术路线、建立培训机制。对外方面，更多的是了解企业市场、了解客户需求、反思产品。最终，希望我们的产品能为客户提供更多的价值。

卡耐基梅隆学习和Google工作的经历跟国内学习和工作相比，最大的差别有哪些？

卡耐基梅隆大学更加侧重原理和实践的结合，其中实践性内容的质量非常高，比如基础类的操作系统、编译原理等课程。设置的每一门课程都会把原理解析得非常透彻，学生需要根据原理亲自编写属于自己的操作系统或者编译器。一些较为前沿的类别，比如云计算、人工智能，教学内容大多都与业界接轨，并且学生有更多的自主性，可以根据某次课程的某个论点进行学术研究、参与相关开源项目的研发等。无论学生准备走学术界还是工业界，学校都可以提供非常多的资源。因此，卡耐基梅隆大学培养的学生大多数都能很快地融入到之后的科研或者工作当中。

大家可能认为卡耐基梅隆大学的学习压力非常大，但是根据我个人的体会来看，并非如此。学校的整体氛围实际上是比较宽松的，更重要的还是靠学生的自主意识。

至于工作方面，因为是直接从国外回国创业的，我不敢妄加评论国内的工作环境。

可以分享下在Google工作时，Google内部容器管理的经验和教训吗？

Google内部容器管理平台已经非常成熟，但也是一个持续演进的过程，其最早来源于Google Search的业务运维平台。由三四个人将搜索引擎中的错误处理等逻辑拿出来作为Borg的最初原型，使其他系统也能享受集群服务。由于类似的历史原因，Google的容器管理平台和内部的业务结合非常紧密。

关于集群管理经验，首先一定要专注于持久的运维自动化工具开发。提到Google的容器管理平台，自然会想到Borg。Borg的主要功能是容器的调度和编排，以及容器的生命周期管理。用户不用考虑程序运行在哪里，只需要根据描述文件通知系统运行程序即可。Borg自己会考虑如何分配任务，任务错误重启等众多功能。Borg与外部的系统结合紧密，例如存储系统、安全系统，开发者可以认为程序运行的所有环境都已经被准备好，只需要关心业务逻辑就好。尽管有如此多的功能，Borg依然只是平台的一部分，Google再此之上做了非常多的工具，如机器生命周期管理系统“亚里士多德”，会持续监测物理机信息并与Borg交互；集群生命周期管理系统“PCMS”，负责接收集群变更事件（如机器批量下线），与Borg交互确保业务稳定运行。

其次，监控是整个平台稳定运行的核心。Borg出现不久，也就是2003年，其监控系统Borgmon就已经开始重点开发。Borgmon是基于黑盒的拉模型系统，侧重效率，但也意味着它需要业务应用的配合。监控需要着重于延迟、流量、错误率等指标，针对不同的业务设计不同的粒度。例如，对于提供年SLA 99.9%的业务，需要将监控粒度放得更大。报警层面，Google更加看重“有效报警”，因此开发了Alertmanager来帮助用户管理所有的报警。总而言之，Google的容器管理将监控提升到了“一等公民”的地位。

另外，优先级和资源分配是容器管理的一个重点。几乎所有用户都不太明白如何去分配优先权（我的应用需要什么样的优先级），以及请求多少资源（我的应用需要多少 CPU、内存）。在优先级问题上，Google有一套优先级配额相关的管理，确保高优先级没有被滥用；资源问题上，有类似Resource Weather的系统提供整体的资源分布和使用情况，也有类似Flex、autopilot的系统帮助用户决定、调整资源使用。优先级和资源分配的合理管理，极大提高了系统资源利用率。有人曾经在Borg上做过实验，利用Borg调度 1 万个Hello world任务，总共用时大概2分半。但是，由于分配的优先级很低，大多数时候并没有10000个任务在运行，而是被其他应用抢占（最高优先级200，最低优先级0）。

最后，健壮性测试非常有必要。健壮性测试包括容器管理平台和运行在平台之上的应用。物理设备会出错，例如物理硬盘；设备也会有定期维护，例如Borg使用的机器平均大约每个月重启一次。一个中等规模的Borg集群大约有 1w 台机器，因此可以想象，集群的“动荡“是比较频繁的。但是即便在SLA中明确告诉了用户可能出现的问题，用户也会依赖于平台。因此，Google会进行DiRT(disaster recovery test)，在集群中注入较大规模的错误，帮助用户提高应用的健壮性。

Google运行应用程序和服务的方式是怎样的？

Google的代码都存放在同一个庞大的代码库中，开发完代码后，开发者需要发一个Change List，进行code review。这类似于Github里的Pull Request。在Google，code review必须严格执行，否则代码将无法提交（除了特殊情况）。

大致的流程如下。

1）开发者写好代码后，先在本地进行编译。由于Google的代码库非常庞大，编译代码所需的依赖可能就需要很长时间。Google内部使用一个叫作Blaze的编译和测试工具，Blaze可以运行在Borg容器集群上，通过优化的依赖分析，高级的缓存机制和并行的构建方法，快速地对代码进行构建。而Google也将这一工具进行了开源：http://www.bazel.io/

2）构建完成后，我们需要在本地进行单元测试，而单元测试的运行测试由叫作Forge的内部系统完成，而 Forge也是通过运行在Borg容器集群上实现快速并行测试的。

3）当本地的代码更新以Change List的形式发送出来以后，Google内部的人员通过Critique的UI进行代码审查，同时Change List会触发一个叫作TAP（tap anything protocol）的系统对该Change List进行单元测试，并保证这个局部的代码变化不会影响Google其他的应用和代码。TAP具有智能的依赖监测功能，会在Google内部浩瀚的代码库和产品线中检测到哪些部分可能会被影响到。

4）当代码通过测试和审核提交后，我们会等到下一个Release cycle进行发布。如前所述，Google内部的应用都是以容器的形式运行在Borg上，因此发布的第一步工作就是通过一个叫作Rapid的系统，对代码进行容器打包成镜像（内部称为MPM格式，通过一个叫Midas的系统管理），再通过Rapid发布工具进行发布。

5）在新版本的发布过程中，我们深度采用了不同形式的灰度测试机制。如果是平台软件更新（如容器集群平台，服务器基础镜像升级），按照一定的速度逐渐更新到不同的数据中心，如第一天发布到一个数据中心，第二天发布到五个数据中心，以此类推，并在过程中不断进行A/B测试和对比。如果是面向用户的产品（如广告、购物等），则会采用基于用户流量分流的灰度发布法，先选择5%的用户流量使用新的版本，并自动收集metrics来进行新旧版本的比对。

6）当应用成功运行后，应用可以通过BNS访问其他服务。BNS类似于DNS，不同之处在于，BNS将IP和端口信息都封装在了BNS路径中。除了用户自身应用，Google的技术设施服务也可以通过BNS来访问，例如 Chubby, Colossus。

Kubernetes会商业化么？如何从Docker那里，抢到足够的用户群？

目前来看，Kubernetes一定是会商业化的。不过，个人认为Kubernetes的大规模使用还有两个前提：一是相关生态更加成熟，二是寻找更多企业场景。不同于Borg，Kubernetes需要满足的场景更多；相反，Borg是专门为Google定制的，无需考虑复杂的场景，也无需构建开放的生态。因此，Kubernetes现在极力做到插件化、模块化，以赋予企业更多定制化的能力，而Kubernetes本身仅提供核心功能。作为一款明星开源软件，Kubernetes的重点一定是社区和生态的建设，一旦成功，商业化也是顺其自然的事情，我们还需要给予它一定的耐心。

Docker项目一直在进行重构，拆分组件进行模块化，目标是标准化容器运行时等技术，构建可插拔的组件。在这一点上，其目标与Kubernetes是相同的，即构建完善的容器生态圈，并不存在冲突。但两者所关注的层面并不完全相同，前者在于容器本身，后者在于大规模容器集群的管理。但随着Docker公司的赢利压力，Docker公司开始逐渐在Docker（项目）中加入容器编排的功能。在这方面，Docker起步较晚，使用方式更加贴近开发者，适合于小规模环境；而Kubernetes更为完善，适合于场景复杂、较大规模的环境，也不存在直接的竞争。如果一定要说如何获得更多的用户，个人认为Kubernetes需要降低使用和运维的门槛，去更加贴近用户。最后，即使两者有趋同的情况，也不一定是敌对关系，放在他们面前的，是如何转变企业的思维，如何权衡与虚拟化的关系等问题。

您认为国内企业，尤其是传统企业应该做出哪些转变，去拥抱国外先进的事物？

传统企业的转变，最重要的还是观念上的改变。可喜的是，我们现在接触到了很多的传统企业，他们对新技术都是开放的态度。但转变不是一朝一夕的事情，企业要学会从边缘到核心的方法，从小做起，慢慢渗透到企业内部。另外，行业的推动也是极其重要的，只靠一家的力量是很难完成转变的，企业需要联合同行伙伴建立行业联盟，学习行业标杆以及其他行业的经验，一起推动转型。最后，转型离不开人，离不开新型人才，仅仅靠内部人力也很难完成转变。传统企业要积极寻找并引进人才，很多问题便可迎刃而解。不过，企业一定要注意可能的问题，比如新老融合的问题，这更需要企业决策者对转型的决心和毅力。

——更多访谈