转载

视频访谈：平台是容器服务重点方向，扩展性、健壮性是集群管理难点

邓德源: 谷歌很早就有了这套系统，在我加入的时候就已经在使用了，当然最最开始是怎样的并不是很了解（笑）。最初，这个系统成为babysitter，负责管理常规应用，如web应用、Google Search之类；后来渐渐切换到borg系统，它可以负责大数据应用，batch等做切换。整体的运维人只有几十个人，之前这是个秘密，但是现在公开了，这些人负责全球几百万台机器。这些人宣称的都是他们不负责机器，他们负责的是管理的机器的系统，所以说，对他们而言效率很高。

邓德源: 现在有很多对应的开源项目，Google开源了Kubernetes有他自己的道理。这部分，包括容器技术本身，其实技术门槛不是非常高的，对于我们而言最难的而是，怎样用去帮助开发和运维去衔接这个桥梁；怎么样让这个系统有的放矢，完成一百件甚至一万件事情。但是有的时候要清楚客户需要什么，比如有一个万能工具，但是用户需要的可能只是修门一件事情；另外你的平台怎么样具有扩展性，怎么样去完成之前没有设想的情况。系统的扩展性和健壮性是集群管理中的难点，而非去攻克很大的技术难题。

4. 就是说要配合用户的需求

邓德源: 这是一个难点，其实是不能跟着用户的需求定制化的。你的系统要有足够的扩展性可以满足他们的需求。在开源这个系统的时候，比如borg，只有谷歌在使用吧，没有过关系；Google做这个系统做了十多年，相当于是为自己定制的，对于我们要开源一个类似的系统，我们需要在三五年之内做到成熟可用的系统，因为市场不会等你太久，比如OpenStack也就五六年。但是用户的需求各种各样，我们怎样满足？一一去满足是不可能的，Kubernetes的思想在于做成module模块化，plugable组件可插拔，extensible满足用户的各种需求。

邓德源: 其实刚才提到了K8S的优势和特点，关于别的技术选型，不吹不黑，我也不好评价。K8S本身很好地针对了容器特性，可以用来实现和满足各种需求；Mesos是非常优秀的，但是它的初衷并不是为了解决这种困境，它是为了提高资源利用率，怎么样把资源做动态而非静态的划分。两者的出发点是不同的

邓德源: 其实我们并没有把Kubernetes拿出来，自己fork一个再做。我们做了很多Kubernetes的抽象，和对Kubernetes本身的管理。对Kubernetes管理应用的部分我们是没有做定制化的。我们的观点是要契合上游的应用开发模式。而以前做的二次开发，基于它做的一些工作，这些是我们前半年的重点，在团队扩充之后，就会直接有专门团队来做这件事情，我们做开源的目的也是为了很好地做产品，推动上游的发展，我们的思路不是拿出来以后再做深度的改造。

关于技术上的坑，其实最大的坑是，在磁盘管理上有缺陷，现在管理的多为CPU和内存，而磁盘管理并没有纳入到roadmap里面，这也是我们想去帮助的一个技术点，因为我们线上80%的问题都是源自磁盘问题。

7. 那就是说现在已经在开始着手在研发？

邓德源: 对，在研发，从9月开始在做的。

邓德源: 其实我们想做的关于K8S的，主要在两点：磁盘管理，对外访问。这部分我们是要交给上游的，因为上游这些很感兴趣。而Cu的提出，主要在于我们做了抽象，K8S本身的很多东西比较原生，不易于使用，这不利于客户的真实使用，一些原生的K8S的概念客户是没有办法理解的，但是我们有不能完全屏蔽掉这一层，所以我们会做成一个plugable的infrastructure来支持这种功能。

邓德源: CaaS偏向于把容器做成服务，比如说容器很好，可以做成CI/CD，快速迭代。但是其实容器根本不是一个服务的点，因为在我们看来，容器只是最底层的一个承载而已。我们的理念是要提供一个服务，把整个的集群服务提供出来，做到用户在使用的时候可能根本不知道底层是容器。

10. 那才云提供的服务全是基于容器的吗？

邓德源: 是的，完全基于容器。但是客户在使用是，对容器技术是无感知的，他可以完全不用关心。比如，在一个客户案例里面，比如他所实现了CI/CD是不会感知到下层使用的是容器；他得到的好处是迭代更快了，环境依赖问题解决了。以前发布一个应用，可能会在上线环节发现出错，但是现在发布应用，同样的流程就不会出错，这是因为底层的容器帮他封装好了，但是他不用关心这些细节。

11. 所以Docker这一层相当于是对用户屏蔽掉的？

邓德源: 对，不过用户也可以采用他自己的Docker系统，如果他习惯了自己的话；用户会操作是我们想实现的目标。

12. 那关于有状态应用和无状态应用，您怎样看待？

邓德源: 如果可以做到无状态是最好的了，应用可以做到随启随停，可以动态牵引。而对于有状态应用，有两个方向。一个就是很多人都推崇的要做到应用拆分，怎么做到DevOps，这个方向肯定是有意义的；但是对于我们而言，从这点切入比较难，因为你要了解用户的需求，要深度定制。所以我们采用的是另外一个方向，怎样从平台层面实现，比如应用混跑，满足12-factor的应用和有状态的应用，都可以支持。当有状态应用被迁移之后，存储会跟着应用走，网络身份也会跟着走，不会有错误出现。所以这两个方向一个是基于改造，一个是基于平台做支撑。后者是我们目前主要的努力方向，但是同时也不排斥去做应用拆分。

13. 那谷歌在这个方面是怎么使用的？

邓德源: 可以从泛泛的角度谈一谈。首先谷歌的所有应用都跑在容器中，没有任何非容器的应用；第二点，谷歌从来没有在内部推动过DevOps呀、去状态呀，一方面是因为开发者很厉害，在写应用是会考虑去状态化和容错机制，另外一方面是它的网络和存储都是分离的。比如网络这个部分，会有一个非常复杂的域名解析系统帮助定位应用，然后跟踪应用，即便是一个在中国一个在美国，它都可以trace到并抓住，当用户来的时候，会有一个setter as cluster；存储部分，有一个专门的存储池，我们在谷歌写应用的时候基本上没有写文件的概念（写文件是在写路径），感觉你似乎就是在写本地存储，但是这个似乎的本地存储实际上是一个网络存储，它的网络存储I/O是非常高的。这是他们容器的一个体验吧，就是在做的时候是完全体会不到是容器。

邓德源: 首先看到容器只是载体，我们做出来一个平台，它可以支撑各种应用，不管是SaaS也好，Web服务也好，大数据也好。这个是我们在谷歌工作之后看到的一个脉络，所以我们认为这个部分有必要去研发实现。我们的创始人之一也是一直从事机器学习，对应的团队现在只有三五个人，他们现在做的就是大数据平台和K8S做一个深度的整合。我们的愿景是首先能提供一个大数据的SaaS服务，TrensorFlow和Kubernetes结合就非常好，另一方面如果用户在使用过程中有大数据需求，我们也可以提供出来，这是to B的模式。那关于to C的，我们会寻找一些场景化的showcase，比如图像在公安系统识别罪犯的情况。

邓德源: 对，目前是这样的。大数据不是我负责的部分，我不能展开说。比如有其他的开源大数据Caffe，从最后结果看我们还是选择了TrensorFlow。

邓德源: 首先我认为学习的强度很大，并且都是实践性相关的。比如第二年的选修过OS和嵌入式的课程，OS课程上要求我们直接做一个OS，没有参考的模板，从最基础的汇编语言写起，验收标准是真正地在机器上跑起来，可以使用命令行进行操作，支持一些Linux的系统：这是一个相对而言比较困难的工作，在国内就会偏概念理解一些。那嵌入式系统，在国内的实践可能就是做一个基于单片机监测的小系统，但是在卡内基梅隆则是在Linux内核中进行修改，从而适配一些硬件，然后用安卓进行监控；当时我做的是在Linux内核中添加一个线程级别的监控，在安卓上进行实时监测，在实际验收的时候会在安卓系统上跑很多应用。相比而言，这些要求难很多，但是也能感觉学到很多东西。

在谷歌工作的话，我个人没有在国内很多的工作经验，但是也有所耳闻，包括目前关于996的一些传言。但是谷歌的话，说实话，我在那边工作基本上也是996的，但是我都是自愿的。在那边基本上早上十点去，晚上十点走；你几点走其实没有人管你，但是东西没做完肯定不好走，当然你可以回家做。工作上不仅仅做自己的任务，也会涉猎些内部的其他系统包括K8S这种开源项目。举个例子，就是我当时的team leader去澳大利亚旅游，当时出现了一个线上的问题，然后他就直接上线了和我一起远程解决问题，当时我还是初来乍到，他说他非常担心我不能handle，因为当时我在on call，出现问题需要由我来解决。所以说这种责任感是非常强的，他不会在意他在旅游，也没有人强迫他去做这件事情，他大可以让其他人来帮助我，所以这点让我当时感触蛮深的。环境很宽松，但是宽松的同时大家有无形的责任感在其中。

邓德源: 对。我们会偶尔brainstorm一下，有什么有意思的事情。谷歌虽然可以学到很多东西，也可以做不少事情，但是你毕竟是颗螺丝钉。而且，我们认为这个方向很好，想回国真真正正地做一些事情。有一些最开始没有想到的，比如最初我的目标是成为国内Kubernetes的top committer，但是创业的时候有很多其他的工作，比如你要招团队、与客户交流、了解各种需求等等。所以现在是从团队角度去考虑如何做成这件事情，这是回国的一个原因。

另外一个就是你提到的志同道合，确实我比较佩服CEO，他其实已经在美国成家立业了，可以说是衣食无忧了，回来的时候是举家回来，感觉很有魄力。然后我一个人在外，为什么顾虑不回来呢。

还有一个因素就是国内毕竟是自己故乡，从小长大的地方，回来会更亲切一些。

原文 http://www.infoq.com/cn/interviews/interview-with-dengdeyuan-talk-platform-and-container-services

正文到此结束