WasmEdge维护者Michael Yuan在CSDN云原生meetup长沙站直播中分享了云原生WebAssembly与K8s。

服务端WebAssembly的崛起

2019年业界便有非常清晰的认知，发源于前端的WebAssembly正在向云原生和服务端转移。这其中最有名的一句话是Dcoker创始人Solomon Hykes所说的：如果Wasm和WASI在2008年就存在了，那也没有必要创建Docker了，服务端WebAssembly是云原生的未来。

在此之后，WebAssembly在服务端有了各种各样的use case，服务端WebAssembly正在崛起。

WebAssembly在服务端可以提供什么价值？真的能取代Docker吗？

• WebAssembly与Docker是一个runtime与沙箱，起到了隔离的作用。WebAssembly（理论上）的安全性远远高于Docker。因为其设计之初就是安全沙箱，在浏览器里运行必须要保证安全性。Docker最初设计的思想是资源隔离，后来优化了安全特征。从这个角度看，WebAssembly与Docker都提供了安全与资源管理。

• WebAssembly与Docker都提供了可移植性，但Docker要好些。Docker是在Linux上进行封装，在操作系统之间提供了可移植性，Arm的Docker镜像与X86的Docker镜像是不一样的。应用要被编译成这两个target。但是WebAssembly做得更彻底，它对下面的硬件也进行了抽象。Arm上生成的wasm字节码，也在X86上也运行。

• 这两种容器的部署都很容易。这是因为过去几年随着云原生的发展，围绕Docker和Linux技术，产生了很多管理和部署的工具，K8s就是一个非常明显的例子。通过WebAssembly社区与WasmEdge项目的努力，在WebAssembly容器化的这条路上，通过现有容器工具对WebAssembly进行无缝管理已经成为可能。

与Linux Container相比，WebAssembly的明显优势有以下几点：WebAssembly比Docker更轻更快，因为WebAssembly是轻量级的runtime，不需要起操作系统，也不需要起application framework。下图展示的是benchmark论文，论文是发在有同行审议的期刊IEEE Software上。最后一行是启动时间，是Docker与WebAssembly的冷启动速度，启动不到1毫秒。

WebAssembly更抽象，这个特点有好有坏，下面会详细解释。对于虚拟化行业，我们经历了几个发展阶段。

• 第一种使用的虚拟机是Hypervisor VM，然后产生的是mircoVM，模拟了计算机，包括计算机上的各种硬件，在上面装操作系统，运行代码。

• 第二种是以Docker为代表的应用容器，比Hypervisor更抽象，模拟了私有的操作系统。

• 第三种是以JVM、WebAssembly为代表的高级语言VM，比Docker更抽象，模拟进程。也因此，Wasm比Docker更快更轻。就像当年的JVM需要自己的SDK和编译器，WebAssembly也需要语言编译器能够编译出Wasm字节码，然后在Wasm VM里面运行。

在这个意义上，WebAssembly的学习路径要比上面两个难一些。对开发者来说，上面两种是没有学习曲线的，Hypervisor VM与应用容器footprint和性能都很难调整，对资源造成了一定的浪费。而WebAssembly是需要把其他语言编译成Wasm字节码，要求开发者必须以节省资源的方式进行开发，在高级VM里运行。

WebAssembly的应用场景在哪里？

WebAssembly和Docker有类似的也有不同的地方，在具体的应用场景里，WebAssembly和Docker肩并肩运行是比较理想的状态，同一个cluster里面有些计算任务由Docker和WebAssembly运行。

为什么要这么做？Serverless函数或者很多无状态的微服务需要频繁的启动。在这种场景里，使用Docker的Linux镜像是非常浪费的用法，用WebAssembly运行workload能把效能提高很多倍。

今天云原生的云计算是在大数据中心里，不过我们也看到越来越多计算被放到了边缘云上，比如在CDN的计算节点上或者企业云以及公有云的边缘节点，比如工厂或者5G网络的MEC，这些都是边缘云节点。与数据中心相比，边缘云节点能够调动的资源比较少，在这个时候对资源的节省就变得很重要，需要WasmEdge这样的轻量级容器。在边缘云上进行函数计算的例子非常多，比如Vercel、Netlify等等。

还有一种是在边缘上进行AI推理，门禁上有照相机，可以做人脸识别，将人脸识别放到数据中心里，每一次都要把图传上去然后再把结果返回，过程很慢，所以放在家里的边缘节点进行图像处理是比较好的选择。

除此之外，Wasm的应用场景还有在边缘设备上使用WebAssembly容器化、通过WebAssembly对SaaS进行自定义扩展。

如何使用K8s管理WebAssembly？

刚才讲了一个愿景：WebAssembly和Docker肩并肩运行，处理不同的workload，那要如何做到呢？

这里先简单介绍一下WasmEdge这个项目。WasmEdge是CNCF的沙箱项目，兼容OCI标准的runtime。在WebAssembly标准之上，对WasmEdge进行了与云原生有关的大量扩展，包括支持SSR、网络socket、AI推理，更重要的是WasmEdge能够兼容OCI，这样WasmEdge就能够被K8s生态的工具管理。

源代码：https://github.com/WasmEdge/WasmEdge

由于crun已经集成了WasmEdge，crun可以识别出WebAssembly镜像，因此WasmEdge可以无缝切入现有的K8s生态。所有K8s相关的工具，OpenYurt、KubeEdge、SuperEdge、CRI-O、containerd都可以管理WebAssembly。

• 构建和安装带有WasmEdge支持的crun binary

• 配置containerd或CRI-O，将Wasm文件分派到crun

• 接下来就可以通过containerd或CRI-O，使用K8s及其周边工具管理Wasm镜像

在此过程中，还可以：

• 使用Docker Hub存储Wasm文件

• 通过cgroupfs和systemd进行资源管理

今天的云原生是K8s+Linux镜像，云原生的下一步是什么呢？是云能走出数据中心，到规模更大的边缘云上。下一步一起探索云原生下一代轻量级容器，将其应用到工厂、边缘上、汽车里。WasmEdge作为开源项目的的组织者，非常希望听到大家的建议，欢迎在评论区留言讨论。

本文转自“CSDN云原生” 公众号。