首页 > 资讯 > 正文

UCloud叶理灯谈:Docker、K8S和Serverless

2019-06-14 06:33:07   来源:转载>

前段时间,笔者参加了UCloud 在京举办的 TIC 2019 大会,适逢 UCloud 实验室负责人叶理灯的演讲结束,就容器计算方面和他进行了短暂沟通。叶理灯是国内在云计算方面有深入研究和实践的资深专家,我觉得他的一些观点和看法值得分享给大家了解。
 

 

叶理灯,UCloud实验室负责人
 

叶理灯,UCloud实验室负责人。现负责 UCloud 创新产品研发,专注面向企业的云计算产品的研发及运营。叶理灯拥有 10 年以上丰富的互联网研发经验,先后任职于腾讯、盛大云等互联网公司,从事海量分布式后台系统研发及运营工作。
 

定制违背了K8S初衷,提供原生K8S产品
 

记者:在官方的K8S 发行版之上,各方云厂商提供K8S服务时都有一些自己的定制和调整,今天大会上提及的 UCloud的K8S 发行版 UK8S 主要做了哪些定制,有什么特色呢?
 

叶理灯:如果说定制K8S的话,其实是违背了K8S的初衷。我们并没有定制K8S,我们是基于公有云给用户提供了原生的K8S 产品。在公有云上提供原生的K8S,其实要做很多的工作,例如与公有云的计算、网络和存储的整合,给用户提供一个开箱即用的原生K8S集群等等。
 

我为什么说不应该定制呢?因为大家知道PaaS发展到今天,一直存在的一个问题就是供应商绑定的问题。而K8S之所以那么有生命力,之所以迅速流行,是因为它提供了一个开源的标准,让用户使用 K8S PaaS平台,可以避免厂商绑定。也就是说你的服务在某个服务商的K8S上运行,可以无缝的迁移到另外一个服务商。
 

作为云厂商其实最重要的工作是,基于我们自身云平台的体系,提供原生的K8S给用户使用,帮助他们减少在集群管理和资源整合方面的工作和投入。例如,我们网络能力、存储能力和计算能力的整合,就是让用户享受到原生K8S的好处,同时避免了很多运维的负担。
 

公有云的K8S处在底层IaaS和上层应用之间,一方面向下整合IaaS能力,一方面向上托管客户的应用。在整合IaaS方面,不改变K8S原生特性,因为K8S本身架构足够开放,例如在我们实现的网络插件,是基于我们IaaS的VPC网络,让pod可以和我们托管区和物理云区域打通,这是我们IaaS能力在K8S产品上的体现,算是我们的特色之一,但这是在K8S体系支持下的插件方式实现的,不影响我们提供原生K8S;在应用层面,厂商也可以基于 K8S 提供一些周边的功能以帮助用户提高效率,但它和提供一个一致的K8S环境不矛盾。
 

另外一方面,如果说定制的概念是指基于K8S本身开发体系所提供的插件机制去做二次开发,那每家厂商都要定制,因为K8S本身不是一个产品级就绪的环境,需要使用者去适配网络和存储还有计算,因为每个公有云厂商基于自己的IaaS去提供K8S产品,必然要去开发插件。
 

综上,向用户应该提供原生的、标准的 K8S 产品,但底层应该基于自身 IaaS 平台去定制,本质还是为了提高用户使用 K8S 的效率,让用户开箱即用。
 

K8S落地挑战:改造成本和人才问题
 

记者:你觉得目前国内云厂商提供的K8S集群编排服务在推广方面目前欠缺的是什么?是什么阻碍了客户进一步去使用这些容器集群服务?
 

叶理灯: K8S以容器技术为核心、以容器镜像为打包标准的特点,意味着如果要迁移到这个体系下,客户需要将软件做容器化打包和微服务改造,这个是有成本的。K8S的特点决定它是运维和研发之间的桥梁,这样就要求公司的研发过程需要跟着改造。我们看到很多公司的运维人员有动力去推动,而研发人员则没有动力,因为它改变了研发的习惯和流程,增加了负担;当然也有的公司是研发希望用K8S管理应用,而需要运维跟着变。这样导致迁移到K8S的工作较重,但一旦这个阶段过去了,迁移后的效率和成本优势就体现出来了。
 

因此,这是个新技术落地的问题,涉及到用户教育和习惯的改变,这个需要社区和商业公司一起完成。而且每家公司的技术路线和文化不一样,上K8S的路径也不一样,所以没有一个放之四海皆准的最佳实践,但随着容器和微服务逐渐落地,K8S作为事实标准,会逐步普及。
 

除了改造业务的成本,另外一方面是K8S人才比较缺乏,不同用户的情况不一样,有些用户的运维人员本来就很少,不可能专门抽出一两个人去做K8S,以及用户又担心它出问题谁来帮我解决?其实,应该是云厂商再往前走一步,除了帮用户构建一个K8S平台,还要帮助解决很多技术上的问题。 UCloud现在就是这么做的,一个用户进来,我们会拉一个群,他们所有技术问题我们帮他们解决。在落地方面,在人才和K8S本身对用户架构改造方面,我们可以多做点工作,帮助客户培养K8S的运维人员和为用户制定架构迁移的方案。但我相信随着技术的发展和普及,越来越多人懂K8S。
 

最后,K8S本身也在发展,K8S刚推出的时候是为了让大家重新面向应用来运维,但是大部分用户用K8S同时管理集群里的节点和应用,就会同时有两个负担。我觉得目标应该是用户直接拿一个容器就可以跑起来,而不用知道它的节点在哪里,即Serverless形态。一旦这种技术更加成熟,对容器技术的落地也有很大的推动作用。另一方面,Serverless 形态也给用户节省了大量的成本,按需付费,免去用户的运维成本。我觉得K8S的落地已经是个趋势了,是不可避免的,但是K8S本身是要往前进步,它的革命还没有完成。
 

容器与Serverless:覆盖场景不同,非替换关系
 

记者:你觉得现在目前Serverless的发展对于容器这种创新技术的迭代升级有什么影响?是不是可以让容器更加的轻量化?
 

叶理灯:不完全是这样,其实Serverless刚出现的时候是针对计算的。计算分很多层次,有物理机、虚拟机、容器和Serverless。Serverless刚出来的时候,它等同于FaaS,有一个对标的产品叫Lambda。
 

Serverless出现的动力是,由于云计算的发展,带来了如对象存储等很多丰富的中间件,Serverless概念的提出是希望应用开发者可以不用写后端逻辑,直接把逻辑写在客户端,组合云上的一些服务来完成业务逻辑,这样就没有管理后端资源的负担了。但是后来发现很多时候还是需要后端代码的,所以就演变成如果有后端代码,就拆成函数,托管在FaaS服务中,这样的话,你依然是不用管理服务器的,你用的还是一个个服务,没有服务器管理负担。
 

这个概念在不断进步,2017年的时候 AWS 提出了一个新的概念,重新定义了什么叫Serverless,只要一个服务具备了四方面特性:免运维、按需付费、高可用和自动扩容,这个服务就是个Serverless的服务。所以Serverless这个概念可以对应FaaS,也可以代表一种架构,也可以代表一种服务的形态,例如Aurora Serverless就是把一个数据库的服务变成Serverless的。
 

容器和Serverless的区别在于,Serverless是无容器的,除了不关注服务器,也看不到容器。两者是面向不同场景的,并不是互相替代的关系。FaaS的特点,接收一个请求拉起一个函数执行,函数是无状态的,它的执行地点也不固定,这意味着延时相对于常驻进程要高,对一些延时敏感的地方它是不合适的,但是有些场景是非常合适的。我举个例子,在IoT场景中,有几十万的设备,为了节省电源,它们大部分时候处于睡眠状态,如果用传统的架构去为这几十万设备服务的话,肯定要考虑并发连接的时候,应该有多少计算资源去服务,这很浪费成本。所以最好的方式,来一个请求就拉一个函数服务一下,这就很节省成本。

这是按需的,但它不是完整的替换,相当于说IT领域里面不同的场景其实是使用不同的服务。我们推出这个服务的原因,背后的动力还是成本和效率,在某个场景上用某个解决方案它的成本更低、效率更高,而不是说新的东西会替换老的,因为不同场景需求是不一样的。K8S接受的用户比FaaS的用户更多,因为K8S的面更广,它覆盖的场景更多,但是它不是替换的。
 

记者:目前,国内客户对Serverless和PaaS的接受和普及程度是怎么样的?
 

叶理灯:我觉得在国内还是处于起步和用户教育阶段。2014年Lambda推出的时候,它的渗透率是72%,什么原因呢?有72%的人用的lambda,我们有个Serverless产品叫UGC,腾讯有FaaS,阿里也有PaaS,目前都不算是渗透率很高。
 

原因有几个。第一、国内用户对新技术接受程度是比较低的,可能是习惯问题,国内的IT的发展水平跟国外也有差距,有5、6年差距;其次,对国内用户来说,把一个架构改成Serverless架构,其实成本是很高,而且改造的收益和规模相关;最后,FaaS本身不是一个独立能起作用的产品,你会看到Lambda推出时,不是个独立的产品,它是体系的副产品,例如其他产品要开放事件源,通过事件去触发Lambda函数执行。只有产品体系开放足够多的事件源,FaaS才能渗透到整个平台里面去,才能覆盖更多场景。
 

我们国内的厂商还没有做到这一点。AWS 刚推出FaaS时,它主要是S3上的图片处理,不是每个用户都有这个场景,因此渗透率不高。随着 API 网关方式调用,和体系开放事件源越来越丰富,覆盖场景越来越多,我相信FaaS会逐步落地。
 

在现场的演讲中,提及了一个叫USQL的产品,就是Serverless方式的大数据分析工具,StepFlow用Serverless的方式编排你的程序,这些都是Serverless的服务。
 

未来,虚拟化容器值得关注
 

记者:目前UK8S的主要发展方向有什么路线图吗?UK8S 是否已经开源?
 

叶理灯:有的,例如说我们让K8S管理更多的资源、异构的资源,还有物理机、GPU资源,希望用户可以通过K8S对这些资源进行统一地管理。另外,再往业务层面走会提供一些微服务的基础设施,通过产品化,一方面减轻用户的资源负担,另一方面减轻应用层的架构负担,从而尽量减轻用户迁移到K8S的负担。
 

目前 UK8S插件还属于正在整理开源的阶段,还没有正式的发布,但我们已经小范围的开放了代码,把我们的插件代码分发给到很多用户,但公开的开源,我们希望做的更加规范一点再进行,因为我们的插件还在不断的迭代中,有一天我们觉得达到一定程度的稳定了,我们就会进行公开开源。
 

记者:你认为未来K8S以及容器的技术方向上比较值得重点关注的技术点是什么?
 

叶理灯:虚拟化容器。未来的方向我们相信是Serverless,这个也是云计算应该做的,持续地为了用户提高效率和降低成本。刚才我也说了,现在用户使用K8S还是有资源管理的负担的,不是完全的面向应用来运维,所以需要解决这个问题,让计算节点对用户透明。用户通过Docker镜像和配置文件就可以把一个应用跑起来,而不用去管资源问题。这需要我们去提供一个海量的集群去跑客户的应用,这就存在一个问题,多个客户的应用可能跑在一个节点上,考虑Docker本身的隔离问题,我们需要类似虚拟化容器的计算方式去做隔离,同时又希望拥有Docker本身轻量级快速启动的效率,现在看来,虚拟化容器是比较符合这个需求的。
 

尾声

通过和叶理灯的交谈,梳理了我对云计算、容器技术和 Serverless 等方面的一些认识,作为一个几年来亲自践行云计算发展,并有深入探讨和研究的专家,他的观点和认识或许值得从业云计算行业的技术人员参考。文/Linux中国 老王


相关热词搜索:UCloud

上一篇:家家悦选择IBM 迈开向平台型公司转型第一步
下一篇:建恒信安:“一个中心、三重防护”应用堡垒助力用户拥抱等保2.0