本文仅用于学习和交流目的,不得用于商业目的。非商业转载请注明做译者、出处,并保留本文的原始连接:http://www.ituring.com.cn/art...api
邓德源, 才云科技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须要下降使用和运维的门槛,去更加贴近用户。最后,即便二者有趋同的状况,也不必定是敌对关系,放在他们面前的,是如何转变企业的思惟,如何权衡与虚拟化的关系等问题。
您认为国内企业,尤为是传统企业应该作出哪些转变,去拥抱国外先进的事物?
传统企业的转变,最重要的仍是观念上的改变。可喜的是,咱们如今接触到了不少的传统企业,他们对新技术都是开放的态度。但转变不是一朝一夕的事情,企业要学会从边缘到核心的方法,从小作起,慢慢渗透到企业内部。另外,行业的推进也是极其重要的,只靠一家的力量是很难完成转变的,企业须要联合同行伙伴创建行业联盟,学习行业标杆以及其余行业的经验,一块儿推进转型。最后,转型离不开人,离不开新型人才,仅仅靠内部人力也很难完成转变。传统企业要积极寻找并引进人才,不少问题即可迎刃而解。不过,企业必定要注意可能的问题,好比新老融合的问题,这更须要企业决策者对转型的决心和毅力。