|
|
|
|
移动端

WOT李健:eleme容器平台的演进

在本次大会上,除了众星云集的主论坛环节,12场分论坛更是各具特色,在19日下午的“DevOps”分论坛上,来自饿了么计算力交付部资深工程师李健先生发表了精彩演讲。

作者:刘妮娜来源:51CTO|2018-06-28 15:18

【新品产上线啦】51CTO播客,随时随地,碎片化学习

【51CTO.com原创稿件】2018年5月18-19日,由51CTO主办的全球软件与运维技术峰会在北京召开。来自全球企业的技术精英汇聚北京,畅谈软件技术前沿,共同探索运维技术的新边界。而在本次大会上,除了众星云集的主论坛环节,12场分论坛更是各具特色,在19日下午的“微服务架构设计”分论坛上,来自饿了么计算力交付部资深工程师李健先生发表了精彩演讲。

作为饿了么企业内部多个基于容器的云计算项目的开发负责人,李健拥有多年丰富的容器系统建设经验,推进了饿了么平台容器化进程。尤其擅长将容器的敏捷性和标准化进行企业级落地。为应对万物互联时代持续计算带来的机遇与挑战,李健致力于打造更加便捷的计算力服务,促进高性能计算、大数据和云计算等多元计算模式的深入融合。


饿了么计算力交付部资深工程师李健演讲

李健此次的演讲主题是“eleme容器平台”,这个平台是基于容器的一个管理系统,谈及管理系统,李健认为,虽然现在公有云比较多,但大家都要面临的一个场景就是混合云。他的演讲主要分为四个部分,即计算力交付、技术选型、算力外卖和基于kubernetes的拓展方案。他坦言,最初在业务快速增长的过程中,资源规模增长非常迅速,导致我们服务器的类型特别多,管理的任务也很重。因为要适应业务,交付的需求也多种多样。

一、计算力交付

李健认为,计算力交付作为一个抽象的概念,实际上是我们把物理资源抽象出来的一种输出,是对于开发人员的一种输出。饿了么的物理资源,讯息资源量很大,人力有限,我们不可能无限的去扩张,于是我们就想实现一种方式,将它标准化,这样可以极大的减少成本,也可以更轻松的去管理更多机器。基于以上,我们计算交付部门出现了。我们认为一切的交付行为都是应用,所以饿了么面临的关键变成了怎么样去交付这个应用,怎么去管理这个应用。

说到这里,就不得不提容器技术。容器技术很早就出现了,Docker为容器做了很大的贡献,它真正面向了应用,可以移植,可以跨平台的特性,特别是它打包方式,使得所有的服务,都变成一种统一的打包方式。这就是应用的一个标准,在这种标准之上,我们可以把这个应用跑在我们想跑的任何一个平台上。只有这样的话,我们才有可能进一步的去做到,不论是自动化运维,还是AIOPS或者是大数据等等,这些更加的降低人力成本,提高资源使用率的目标。

具体看来,我们会交付三个事情,首先是用户数,就是你把应用交给我,我来帮你部署,让服务跑起来。其次是标准服务的一键交付,比如大数据需要一套环境,或者某某部门他需要一套环境,一套环境里面他包含了ABC很多服务,这些服务和其他服务有隔离性,服务之间又必须建立起一种联系,而且具有可复制性。第三是服务器的交付,其实也被划拨进来。开发需要一台服务器,这个时候我们就很好的可以将计算力作为服务器的一种交付。

二、技术选型  

技术选型现在有很多,kubernetes是比较风靡的一种,选择kubernetes即是建立了标准,它带来的利好就是成本下降。当我用跟别人一样的东西,我成本下降了,解决问题时的优势不言而喻。如果我选热度很高的项目,这个项目,首先对于我中小公司来说,我遇到问题至少可以在谷歌上,可以查到这个问题,有据可依。另外还考虑到的一个场景,即你需要的东西和你的选型是否契合,这也是非常值得关注的问题。此外,扩展性、生态发展、大公司的容易建立起生态,亦有前瞻性可循。

三、算力外卖   

谈起算力外卖,李健津津乐道。据他介绍,饿了么做外卖,有好多东西容易要跟吃的结合起来。例如我们会议室可能叫“榴莲酥”。算力外卖我们需要的就是一个场景,例如说我们去饭店吃饭,这就是一个场景。再比如说一个开发环境,在使用完了这套环境之后就可以销毁了,或者我可以点一个套餐,点一套“环境”,好像我们去订外卖,购买一个套餐一样,包含很多内容。

在应用层面,李健把它描述得跟我们的胃口很像,包括各种不同类型的服务。所以会有这样一个box,box实际上可以把它抽象成一桌饭或者是一个外卖盒。在这里面我们可以看到,我们把每一个服务相互之间的调用,都通过domain去调用。而且这个box它有复制性,无论从这个模板里面创建出来box有多少,在每个box内部调不同服务的时候,它的域名是唯一的。

例如,从第一个服务调第二个服务的时候,第二个服务的域名是JOB,第一个服务调第二个服务的时候它从B就可以调用,这样就减少了开发人员复杂度。我们启用个服务的时候,自动给它生成唯一网络标识,可能是IP或者域名。想要更改我的配置,不需要更改它的配置,只需要把这个环境拉起来,这个应用就可以跑起来了。因为我的配置,我所对应那些服务,他们的网络标识是一样的,他们都是叫X。

四、基于kubernetes的拓展方案  

李健演讲的最后一部分是“基于kubernetes的拓展方案”。其具体的实现就是用kubernetes去做底层的容器引擎。在里面可以看到,在一个Internal里面,包括domainl,pod我们可以在这个服务,它有自己的一个副本,做一个副的均衡。这些服务之间可能有依赖关系,例如A服务依赖B服务,如果B服务宕机,A服务要做一些处理。A服务依赖B服务,会有个启动数,我们在box里面也做了同样的事情。

当然从技术发展来讲,很多时候大家认为,新技术里面,不应该有依赖关系。但是我们现在遇到的问题,确实存在依赖。我们的服务业务在这个场景下,要推动标准化就一定要兼容开发的目前的一些项目或者它的习惯。

还有一些服务启停,那就是初始化。比如说有些服务完成之后会调另外一个pod进行初始化。还有一些公共服务,有些数据是需要传递的。我们就可以把外面的服务,通过内部标识转换到外部标识,我们内部标识实际上是永远是不变的,外面关系通过服务发现或者机制关联上来,这样就完全的不用考虑配置变更,或者服务发现等等问题了。

这个是我们的一个最简单的通过外卖的方式对我们服务的一个抽象。当然了我们在这个过程当中会考虑我们服务的规模,规模扩大后会发生什么问题。kubernetes依赖etcd,etcd,我们知道它实际上在kubelet场景下,它支持不了那么大规模,但是我们又对稳定性有一些要求。所以我们就只能说把它进行拆分,尽量的进行拆分。

如果我们人为的通过三个或者四个kubelet机群给它拆分了,如果拆得太细,资源利用率就会降低,有些机群可能饿死了,有些机群可能饱死了。我们就是通过一种方式,我们希望说让这些服务,kubelet是不同的etcd这个机群,有一个方式让服务可以在机群之间进行飘移,可以调度。这样既解决了资源效率的问题,又解决了可靠性的问题。

从上图的结构看来,除了黄色的部分,其他部分就是kubelet原先的一些组件。我们开发了一个类似于kubelet的API Server的服务。按照我们本来的想法,例如我现在调度完成之后,分两级调度,我们以为把资源调到A机群还是调到B机群就可以了,后来发现实际上很难做到。我们在现在使用的docker上加了一个小版本,小版本主要问题是,日志量很频繁的时候(毫秒级别)就会乱序,导致业务部门排查不下去。因此我们在docker里面增加了一个序号。

李健坦言,我们企业的软件环境,实际上是自己生长出来的,我们不可能因为一个开源软件更改现有的内容,我们希望通过某种方式让开源软件来适应现在的软件状态。这就是docker的一些监控,例如我们发现一些问题或者bug,都是通过监控来发现的。

此外,我们在容器管理当中,如果遇到一些问题,比如说将传统的业务进行容器化的时候,我们就进行改进。所有的东西都是在容器里面,internal进程是我们定制的,internal进程是切换技术层管理的一些目录和环境变量,另外一个是基础配置文件的一个宏代换替换。我们服务在跑这个的过程当中,有些服务迁移,以前是配置的,现在改成了容器。在环境变量里面,把这个配置从环境变量里面读,可能会产生一些成本。所以我们提供了一种方式,把变量写在里面,会根据容器这些环境变量自动替换这个配置。特别是在容器环境里面,如果这个容器没起来之前,不清楚它的IP,问题就必须在internal进程里面去解决。

本次WOT峰会讲师演讲稿件由51CTO采编整理,如欲了解更多,敬请登录WWW.51CTO.COM进行查看。

【51CTO原创稿件,合作站点转载请注明原文作者和出处为51CTO.com】

【责任编辑:刘妮娜 TEL:(010)68476606】


点赞 0
分享:
大家都在看
猜你喜欢

热门职位+更多

读 书 +更多

ASP快速建站全程实录

本书从一个网站制作过程入手,详细介绍基于ASP技术建设网站的全过程。全书共10章。第1章,网站制作规划与流程;第2章,IIS安装与调试;第3...

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊