搜索
❏ 站外平台:

UCloud 叶理灯谈:Docker、K8S 和 Serverless

作者: Linux中国 老王

| 2019-06-13 11:56      

前段时间,笔者参加了 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 等方面的一些认识,作为一个几年来亲自践行云计算发展,并有深入探讨和研究的专家,他的观点和认识或许值得从业云计算行业的技术人员参考。



最新评论


返回顶部

分享到微信

打开微信,点击顶部的“╋”,
使用“扫一扫”将网页分享至微信。