能力|优刻得拥抱云原生Serverless技术还能这样用在容器服务中

_原题为 优刻得拥抱云原生Serverless技术还能这样用在容器服务中
UCloud优刻得为了帮助企业降低容器和Kubernetes的使用门槛 , UCloud优刻得在2020年7月份推出一款Serverless容器实例服务Cube , UCloud优刻得用户通过Cube用户只需要提供打包好的Docker镜像 , 即可快速、批量部署容器化应用 , 并且只需为容器实际运行消耗的资源付费 。
随着容器、Kubernetes、Serverless等云原生技术的快速发展 , 越来越多的企业开始拥抱云原生 。 UCloud优刻得使用容器缩短了企业应用从开发、构建到发布、运行的整个生命周期 , 但由于Docker往往难以独立支撑起大规模容器化部署 , 因此诞生了Kubernetes等容器编排工具 。 然而Kubernetes的使用体系非常复杂 , 对于企业的开发运维人员而言 , 需要具备一定的网络、存储、系统等方面的技术能力 。
这样一款Serverless产品 , 究竟是如何在技术上实现的呢?就在10月23日刚结束的UCloud优刻得TIC2020大会的技术分论坛上 , UCloud优刻得容器云研发负责人张苗磊在《UCloud Cube容器技术解析》议题中着重介绍了UCloud优刻得 Cube产品背后的技术架构 , 并且从虚拟化/网络/存储等多方面展示无服务器化容器的技术细节 。 本文是演讲内容整理 , 供大家学习参考 。
【能力|优刻得拥抱云原生Serverless技术还能这样用在容器服务中】能力|优刻得拥抱云原生Serverless技术还能这样用在容器服务中
文章图片

为什么要推出Cube? 说到云原生的概念 , 张苗磊讲到 , 云原生其实对云厂商带来很大的冲击 , 其中一个比较明显的变化就是用户需求和云厂商提供的能力之间的变化 。
能力|优刻得拥抱云原生Serverless技术还能这样用在容器服务中
文章图片

在云原生之前 , 用户从云厂商购买的是比较基础的计算能力和服务器资源 , 用户需要在此基础上一层层封装 , 最终来实现支撑自己应用服务的能力 。 而在云原生之后 , 云厂商则希望提供一种能够更加向应用靠拢的能力 , 用户仅仅需要关心应用 , 而其他所有的业务完全都可以交给云厂商来实现 。
在此基础上 , 就很自然的诞生了所有Serverless产品的概念 , 即用户不需要再购买具体的服务器资源 , 而仅仅需要将它应用封装成一个比较标准的格式传递给云厂商 , 然后调用云厂商的API来直接运行它的程序 , 所需要的资源完全按需并且弹性灵活 。
Serverless的概念在业界有很多具体的实现 , 比如容器和K8S就是一个比较好的例子 , 容器提供了对应用的封装 , 而K8S产品提供了对运行环境的管理 。 因此近年来包括UCloud优刻得在内的云厂商都推出了自己的K8S产品 , 即用户可以一键在云主机内构建一个K8S集群 , K8S所需的其他能力完全由云厂商的插件来提供 。
但是在K8S产品的推广过程中 , 我们发现K8S的概念还是比较复杂 。 用户在关心其应用的同时还要学习K8S知识 , 这是有些背离最初云原生提出的 , 仅以应用为中心的设计目标的 。 因此我们就想着能否进一步包装K8S的产品 , 仅将K8S最小的运行单元pod的概念暴露给用户 , 而其他所有的能力完全交给云厂商来实现 。 在此基础上 , 我们想能否将K8S的最小运行单元pod直接暴露出来 , 而将其他K8S繁琐的概念统统封装起来?
能力|优刻得拥抱云原生Serverless技术还能这样用在容器服务中
文章图片

这样一来 , 我们就推出了一款Serverless容器实例服务Cube , Cube对外仅暴露pod的概念 , 而用户所需要的镜像运行命令和其他资源关联的关系都可以通过标准的K8S yaml提交给UCloud API 。 这样pod就可以轻松直接运行起来 , 用户实际所需要负责的 , 仅仅是pod所需要的资源大小 。
Cube实现背后的技术原理 轻量级运行时
我们知道原生的docker实现 , 由于不能很好的做到资源隔离和租户隔离 , 因此无法在云厂商上直接暴露给用户 。 于是我们的Cube对docker运行时进行了大量的改造 。
能力|优刻得拥抱云原生Serverless技术还能这样用在容器服务中
文章图片

图中可以看到标准的虚拟机内实现的容器是左边所示 , QEMU提供了虚拟机的隔离能力 , 而用户在QEMU虚拟机内会部署一个完整的docker或者containerd , 并在此基础上拉起容器 。 我们在想能否将QEMU和虚拟机的二者能力结合为一起 。 于是在Cube中我们基于虚拟机实现了容器实例即我们的Cube , 对外暴露的是标准的K8S CRI接口 , 但具体的实现是一个轻量级的虚拟机 , 用户实际需要运行的容器是在轻量级的虚拟机内拉起的 。 这样带来的好处是Cube融合了虚拟机资源隔离和容器快速启动的优点 。
当然为了完全的比拟docker , 实现的容器快速启动 , 我们在性能上也做了很多优化 , 比如将QEMU虚拟机换成了Firecracker轻量级虚拟机 , 仅实现了最小设备 , 进一步的降低虚拟化损耗 。 并且拉起速度能够降低到100毫秒 。
当然容器的快速启动时间 , 也不仅包括容器启动的时间 , 还包括了镜像拉取的时间 。 我们在实际的应用推广过程中 , 也发现经常会遇到用户的容器特别大 , 而导致镜像拉取时间很长 , 进而导致启动速度慢 。


推荐阅读