UCloud叶理灯谈：Docker、K8S和Serverless

前段时间，笔者参加了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中国 老王